Перейти к содержанию
    

Нужна утилита для измерения производительности сети

1 minute ago, kolobok0 said:

стандартным прожкам не верят(iperf, ping), но верят Вашим попугаям????

простите, вы о чём? iperf я собираюсь использовать. Но в понедельник, не раньше. Это мой рабочий проект. А сейчас у меня выходные.

2 minutes ago, kolobok0 said:

т.е. проверяют Вас или устройство????

Ответ здесь, в самом низу. Но поясню ещё раз: проверяют меня, вернее качество моего софта. Ну а я заодно проверяю себя, lwIP, и получаю дополнительный опыт. Стал приходить к выводу: если начальника не удаётся переубедить, то сделай, как прсоит. Тебе деньги за это платят, а опыт дополнительный ты получишь.

4 minutes ago, kolobok0 said:

железки не верят(100Mbit)

А я и не говорил, что порт 100 Мбит. Откуда вообще эта информация.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 minutes ago, haker_fox said:

...порт 100 Мбит. Откуда вообще эта информация.

выше прозвучало не от Вас. (думаю не принципиально в контексте)

т.е. разница лишь реализация ответной части от iperf либо свой огород (в профиль то же самое). и на писюке iperf или то же самое но самопальное...

выбор(лично для мну очевиден). да и для Вас как я понял...

ЗЫ

С Вами завязалась беседа в струе ответа AlexandrY 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4 minutes ago, kolobok0 said:

С Вами завязалась беседа в струе ответа AlexandrY 

Признаюсь, мне эти цифры сильно не важны. Только для профессионального роста, попытаюсь, возможно, что-то улучшить в коде. Тем более железяка не будет передавать траффик размером сильно большим) Откровенных лагов главное что бы не было, и этого достаточно. просто в сетях я начинающий, нет большого опыта, вот и спрашиваю, что можно сделать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

4 minutes ago, haker_fox said:

... что-то улучшить в коде. ...Откровенных лагов главное что бы не было..я начинающий,... что можно сделать.

улучшить:
чисто из опыта, - как минимум все опен библиотеки ( это относится и к lwip) надо проверять глазками. Хотя-бы схемотоз. А лучше перерыть. Звучит как минимум странно но увы, без контроля халявы можно нарваться совсем на костыли. В своё время приходилось править и lwip стэк, к сожалению. некоторые вещи пошустрее сделал, где то явный ляп подправил... на таком уровне. но это уже наверное устаревшая инфа - было не вчера...

все мы родились не с клавами под мышками.

сделать можно - диагностику добавить. Например сбор ключевых сетевых счётчиков и ответ собранной статистикой по запросу. рекомендую так-же сделать контроль стэков (глубину их использования. можно поставить на переключении, если многозадачная ось есть) и сбор как можно побольше инфы при падеже (пошёл по такому пути - запись во флэш и при рестарте проверка наличия свежего падежа и перенос уже на микро-сд в лог...).

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 minutes ago, kolobok0 said:

Звучит как минимум странно

И вовсе не странно:blum: Полностью с вами согласен. В том же lwIP анализатор cppcheck находил какие-то погрешности. Но некритичные. А вот в поделках CMISIS-драйвера... ну это уже другая тема.

3 minutes ago, kolobok0 said:

рекомендую так-же сделать контроль стэков

Я использую встроенный контроль во FreeRTOS. Он не всегда срабатывает. Но это что-то.

4 minutes ago, kolobok0 said:

и сбор как можно побольше инфы при падеже

Да, подробный отчёт при вылете в hardfault (значения регистров, содержимое обоих стеков, куда после хардфолта возвращаемся (process или thread), использование fpu и многое другое), исключения операционки и стандартной либы (exit(), abort() и т.п.). Всё это действительно помогает при отладке.

5 minutes ago, kolobok0 said:

пошёл по такому пути - запись во флэш и при рестарте проверка наличия свежего падежа и перенос уже на микро-сд в лог..

Я пока во встроенную EEPROM микроконтроллера сохраняю инфу.

Благо её там 16 кБ.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

6 hours ago, kolobok0 said:

сделать можно - диагностику добавить. 

Довольно непрактичный совет. Любая такая доморощенная диагностика значительно замедлит работу TCP стека. И тогда не видать 98 Mbit как собственных ушей. 
Если людям действительно нужно знать качество работы сети и они беспокоятся по поводу производительности, то выбирают предназначенные для этого микроконтроллеры. 
В частности микроконтроллеры от бывшей Freescale имеют аппаратный движок статистики RMON.
Вот с такой статистикой вы уже смело можете  диагностировать сеть.
А iperf - баловство. Никто серьезно его не применяет для диагностики.  
Он нужен только для констатации факта - удалось вам справится с драйвером Ethernet или нет. 

Лучше конечно взять Renesas Synergy, там хоть и нет RMON, но зато есть счетчики всех основных траблов с пакетами и полный протокол SNMP со всеми фичами.
А диагностика сети как раз делается с помощью SNMP протокола. 
В  корпоративную сеть дивайс не дадут подключить  если у него на борту нет SNMP.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 4/5/2019 at 3:53 AM, jcxz said:

"некий сокет на сервере" - понятие бессмысленное, так как сокет - это уже установленное соединение между двумя TCP-портами. Пока не подключились к порту на сервере, никакого сокета нет.

Вы не правы.

UDP сокеты вообще без соединения работают.

Сокет это IP адрес и номер порта. О соединении речи нет.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...