• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Вопрос Куда уходят udp пакеты?

Алексей.

Active member
Пробрасываю из spi в udp пакеты, довольно интенсивно, каждые 2500 микросекунд по 1450 байт отправляю в udp и по непонятным причинам периодически пакеты то по одному то пачками не доходят до получателя.
В среднем из 300000 пакетов отправленных теряются от 1000 до 6000.
Куда деваются не понятно??
Расстояние от модуля работающего в режиме точки доступа до клиента небольшое, пробовал отходить подальше не помогает.
Выполняю на сокете в неблокирующем режиме sendto и ошибок не получаю, думал если исходящая очередь сетевого интерфейса заполнена в errno получу ENOBUFS, так и нет вообще ошибок при отправке.
 

pvvx

Активный участник сообщества
Куда деваются не понятно??
1) Откидываются при заполнении буфера передачи драйвера WiFi, если он заполнен.
2) Теряются в эфире WiFi из-за коллизий и арбитража.
Где хранить 40 пакетов (2.5 мс * 40 = 100 мс), к примеру если потерян один beacon?

В среднем из 300000 пакетов отправленных теряются от 1000 до 6000.
Зависит от потока.
Iperf в помощь...
Без проблем можно выдавить потерю 99% пакетов UDP при трафике с Гб сети через роутер на WiFi...

Пропускная способность канала WiFi зависит от множества факторов. Перечислить все причины потери пакетов UDP в WiFi в одном посту невозможно.
 
Последнее редактирование:

Алексей.

Active member
enjoynering, А есп32 это одно и тоже что 8266?
И клиент sta совсем не esp8266 в режиме sta
Если задержки между отправки более 30 миллисекунд такой беды нет
 

pvvx

Активный участник сообщества
Если задержки между отправки более 30 миллисекунд такой беды нет
Это значит что вам везет с ситуацией шума на этом канале WiFi и кол-ва работающих устройств в его диапазоне...

"если исходящая очередь сетевого интерфейса заполнена в errno получу ENOBUFS" - это в какой программной реализации? Arduino, ESP-IDF, ... ?
После передачи пакета драйверу его привязка к 'сокету' теряется и ответить передан ли пакет драйвер LwIP-у не в состоянии. Обычно может только указать сколько пакетов потеряно в каком-то своем счетчике...
С многоадресными посылками в WiFi всё ещё хуже...
-------
Простой тест типа: соединение модуля с AP, получение IP, отсылка пакета UDP и ожидание в 30 мс до отключения питания (ожидание по времени с ограничением в 20..50 мс) показывал, что при таких условиях теряется достаточно много UDP пакетов, иногда порядок 1 к 10. Зависимость от типа модулей и ПО на это не сказывается.
 
Последнее редактирование:

Алексей.

Active member
если исходящая очередь сетевого интерфейса заполнена в errno получу ENOBUFS
man sendto
RETURN VALUE
On success, these calls return the number of bytes sent. On error, -1 is returned, and errno is set appropriately.
ERRORS
ENOBUFS
The output queue for a network interface was full. This generally indicates that the interface has stopped sending, but may be caused by transient congestion. (Normally, this does not occur in Linux. Packets are just silently dropped when a device queue overflows.)

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

Печалька... а выход какой?
Выбрать канал другой, но завтра и на другом канале будет тоже самое.
Рядом расположены 2-е точки доступа (обычные zyxel-и) с уровнем сигнала близким к есп (смотрю уровень на клиенте), потерь пакетов в таком количестве почему то нет, если передаю udp от этих АП.

отсылка пакета UDP и ожидание в 30 мс до отключения питания
А чему удивляться то? положили в стек не дождавшись выхода выключили питание
 

pvvx

Активный участник сообщества
А чему удивляться то? положили в стек не дождавшись выхода выключили питание
Вы спрашивали куда они деваются при укладке в "стек", которого нет для UDP - то.
А вам уточняю, что паузы в 30 мс не хватает на гарантированную передачу пакета по WiFi сети.
Видимо поведение реализации схоже с линуксом, пакеты дропаются без слов, хотя на линуксе переполнить очередь такой нагрузкой не получалось.
На то там имеются Гбайты памяти и странно что что-то пропадает при этом :)
Встречный вопрос - куда деваются пакеты на свиче соединяющем Гб ethernet c 100Mb?
Как получить в socket информацию, что данные UDP не достигли адресата в запросе их отсылки?
 
Последнее редактирование:

Алексей.

Active member
Осталось только копать в строну определения текущего заполнения стека, если повезет...
 

pvvx

Активный участник сообщества
Осталось только копать в строну определения текущего заполнения стека, если повезет...
Там нету стека. У дров обычно есть буфер, который может быть разбит на части по кол-ву помещаемых пакетов или динамическому распределению. Данной информации по ESP-32 пока не видел. Но на вскидку видно, что используется статический буфер - заранее зарезервированный на этапе компиляции...
Попало к примеру 4 пакета от LwIP в него, дрова WiFi упаковали его в свой формат кадра и пытаются передать, ожидая арбитража... Что делать, если не вышло - дропать по таймауту или остановить все другие передачи?
Для ethernet выкидывают, не задумываясь... вытеснение новыми правильнее...
По этому (наверно) и не получить ошибку ENOBUFS.

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

Не используйте UDP и всё будет хорошо :)
 
Последнее редактирование:

Алексей.

Active member
Попало к примеру 4 пакета от LwIP в него, дрова WiFi упаковали его в свой формат кадра и пытаются передать, ожидая арбитража... Что делать, если не вышло - дропать по таймауту или остановить все другие передачи?
Судя по коду не совсем так, вернее совсем не так, упакованное сообщение в своем формате для помещается в очередь, причем если сокет не в блокирующем режиме выполняется одна попытка поместить сообщение в очередь, в случае неудачи возвращается ошибка. Похоже пакеты пропадают в эфире.
Не использовать UDP можно, только очередной прокси ставить, чтоб завернуть rtp через tcp.
 

pvvx

Активный участник сообщества
Судя по коду не совсем так, вернее совсем не так, упакованное сообщение в своем формате для помещается в очередь, причем если сокет не в блокирующем режиме выполняется одна попытка поместить сообщение в очередь, в случае неудачи возвращается ошибка.
Это на уровне socket LwIP. LwIP, в свою очередь, передает пакеты драйверу WiFi, про что и шел разговор.
Похоже пакеты пропадают в эфире.
Пропадают и на уровне драйвера WiFi, т.к. от него обратной связи к socket нет.
Не использовать UDP можно, только очередной прокси ставить, чтоб завернуть rtp через tcp.
А как бороться с сетью WiFi? Увеличите нагрузку на AP или заработает какое устройство BT и всё - рваный поток?

Вот схожий ответ по теме работы WiFi в ситуации multicasts
https://tools.ietf.org/id/draft-mcbride-mboned-wifi-mcast-problem-statement-00.txt
 
Последнее редактирование:

Алексей.

Active member
А как бороться с сетью WiFi? Увеличите нагрузку на AP и всё - рваный поток?
Нагрузка фиксированная, левых клиентов нет, поток действительно рваный и причина сильно зашумленный диапазон.
На голосе выпадение пакетов практически не заметно, а на видео очень не красиво, картинка начинает разваливаться.
 

Алексей.

Active member
Не используйте UDP и всё будет хорошо :)
Завернул таки я rtp через tcp, лучше не стало, лив-видео даже с разрешением vga с трудом смотреть можно, из за неожиданных лАгов, плеер ругается, что кадры приходят слишком поздно.
Это у espressif норма или у меня руки кривые?
 

pvvx

Активный участник сообщества
Завернул таки я rtp через tcp, лучше не стало, лив-видео даже с разрешением vga с трудом смотреть можно, из за неожиданных лАгов, плеер ругается, что кадры приходят слишком поздно.
Это у espressif норма или у меня руки кривые?
У WiFi, при зашумленной сети?
Уберите из эфира и зоны работы AP древние и неадекватные работающие устройства, типа ESP8266 - лагов будет меньше.

Я пока не делал замеров среднего трафика у ESP-32 при длительной работе.
Недавно запускал iperf на ESP-32 для теста тока потребления при передаче в UDP - колбасит достаточно сильно - в диапазоне 250..450 мА, смена среднего тока происходит каждые несколько секунд, при этом имеются три характерных уровня (~430/~320/~270) Видимо происходит переключение rate или HT20 - HT40 или чего-то прочего - не выяснял.
Температура корпуса чипа при AP уходит за +85С и возможно включается троттлинг на передачу. Пока не уточнено что и как - нет желания разбираться с неперспективным чипом.

Вам же можно включить и самый медленный режим 802.11b. Тут надо экспериментировать под текущие условия...
-------
Я вот не могу понять, чего вы хотите от устройства, цели которого затачиваются для Arduino со стандартом по аналогичным параметрам у ESP8266. Почему в качестве стандарта выбран ESP866 – это спросите у фанатов и Ардуинщиков. ESP-IDF уже привели в соответствие с этими характеристикам путем понижения частот CPU и нашлепок кода. У задач под Arduino ESP8266 нет таких нужд, как получение стабильного трансфера UDP или TCP более 100 килобайт в сек. Там более востребованы другие характеристики, такие как успешное повторение телепузиками копирования “скетчей” с элементарными действиями подключения Arduino платок 2.54 с низкоскоростными датчиками (1 замер в сек) и передачи не более десятка значений на MQTT в 10 сек.

У вас совершенно другая задача и соответственно она требует другое ПО. Стандартное, изготовленное для Arduino, не пойдет. Вам придется писать всё с нуля и своё. Договаривайтесь с Espressif и подписывайте с ними NDA. Или ждите, когда очередь дойдет до совершенствования необходимой вам функциональности, которая возможна только после удовлетворения основного спроса у телепузиков. ESP-IDF ещё находится в стадии создания – в нем не реализовано и не поддерживается и 10% возможностей чипа… Годика через 3 наверняка доведут этот фактор до 30% и откатают основную функциональность. Вот тогда и можно будет проверять итоги, примеру стабильность трансфера в TCP или UDP при использовании ESP-IDF.
 
Последнее редактирование:
Сверху Снизу