Вопрос Проверка скорости передачи UDP

[aazavid]

Я пока серьезно не погружался в общение ESP между собой, так как у меня умные измерительные приборы и они общаются с главным компом.
Но есть две идеи в плане создания внутренних сетей.
1) Реализация на ESP ethrnet обмена . т.е это то, что идет до UDP и TCP, так как на внутренних сетях eSP UDP и тем более TCP это излишество.
2) Использовать для создания внутренней сети NRF
Если кто-то это уже делал интересно было бы послушать о результатах.

Есть какие то сподвиги в этой теме? сейчас тоже очень интресен вопрос связи двух модулей между собой, без лишней обвязки. Хотелось бы добиться максимальной скорострельности при минимум помех

 

[pvvx]

Тест с помощью iperf.exe
Передача UDP на модуль (RTL00):

Передача TCP на модуль (RTL00):

Передача TCP c модуля (RTL00):


Далее UDP и наблюдаем кучу потерь... (при приеме на модуль не вписал показ потерь, по тому показывает потери только в сторону компа.)
Передача UDP c модуля (RTL00) на 10Mbits/s:

Передача UDP c модуля (RTL00) на 1Mbits/s:


Итого: нафиг сдалось это UDP на WiFi - толку от него никакого. Кучи потерь и скорость не выше. Jitter так-же одинаков -> WiFi.

 

[nikolz]

Тест с помощью iperf.exe
Передача UDP на модуль (RTL00):
Посмотреть вложение 2969
Передача TCP на модуль (RTL00):
Посмотреть вложение 2971
Передача TCP c модуля (RTL00):
Посмотреть вложение 2972

Далее UDP и наблюдаем кучу потерь... (при приеме на модуль не вписал показ потерь, по тому показывает потери только в сторону компа.)
Передача UDP c модуля (RTL00) на 10Mbits/s:
Посмотреть вложение 2973
Передача UDP c модуля (RTL00) на 1Mbits/s:
Посмотреть вложение 2974

Итого: нафиг сдалось это UDP на WiFi - толку от него никакого. Кучи потерь и скорость не выше. Jitter так-же одинаков -> WiFi.

Почему Вы не объясните читателям, что tCP не имеет никакого преимущества при отсутсвии множественного пути и коротких пакетах. Именно этот режим и используется в домашних сетях c датчиками.
Т е в сетях с датчиками нет никакой выгоды от tcp, кроме дополнительной задержки.

 

[pvvx]

Почему Вы не объясните читателям, что tCP не имеет никакого преимущества при отсутсвии множественного пути и коротких пакетах. Именно этот режим и используется в домашних сетях c датчиками.
Т е в сетях с датчиками нет никакой выгоды от tcp, кроме дополнительной задержки.

По тому, что использующим датчики нужны данные с них. Так вот всё просто.

 

[nikolz]

По тому, что использующим датчики нужны данные с них. Так вот всё просто.

И эти данные умещаются в несколько байт и тем более умещаются в один блок, что исключает достоинства tCP.
И это особенно важно при автономном питании.

 

[pvvx]

И эти данные умещаются в несколько байт и тем более умещаются в один блок, что исключает достоинства tCP.
И это особенно важно при автономном питании.

Безусловно. Для приема по UDP данных с датчиков необходимо описать свой протокол передачи с перезапросами и проверками. Это очень хорошо сажает батарейку, т.к. требует долгого сеанса активности - на передачу одного байта с датчика контроллеру необходимо обменяться не менее 3- мя пакетами по UDP, с ожиданиями их обработки и подтверждения приема на верхнем уровне принимающего оборудования, что дополнительно требует применение специальной скоростной системы реального времени на приемнике. Из имеющихся систем на сегодня и скоростей обработки на верхнем уровне системы, с ухищрениями по оптимизацией по скорости, а не размеру кода, получаем, что требования к системе приемника выражаются в использовании CPU на ГГц-ы и наличия нескольких Гегабайт памяти. Но при увеличении датчиков до дцати, и такая система не справляется в десятки ms... А итоге просыпающийся контролер вынужден ждать подтверждения передачи своего байта от датчика сотни ms, жрать батарейку и иметь громадную программу для обслуживания собственного выдуманного протокола передачи 1 байта по UDP с доставкой и кучу ресурсов для её поддержки.
В случае с TCP - имеющиеся реализации для обслуживания полного трафика WiFi умещаются в десятку килобайт и требуют производительности МСU с частотами на не более 20 Mhz. Пример - TCP/IP стек LwIP. Он уже отлажен за десятки лет, в отличии от вашего ещё не написанного протокола. И даже ваш протокол с UDP не обходится без него - кто будет обрабатывать уровень IP ?
Есть хороший пример - протокол RTP, базирующийся на UDP до сих пор не реализован на ESP8266.

 

[nikolz]

Безусловно. Для приема по UDP данных с датчиков необходимо описать свой протокол передачи с перезапросами и проверками. Это очень хорошо сажает батарейку, т.к. требует долгого сеанса активности - на передачу одного байта с датчика контроллеру необходимо обменяться не менее 3- мя пакетами по UDP, с ожиданиями их обработки и подтверждения приема на верхнем уровне принимающего оборудования, что дополнительно требует применение специальной скоростной системы реального времени на приемнике. Из имеющихся систем на сегодня и скоростей обработки на верхнем уровне системы, с ухищрениями по оптимизацией по скорости, а не размеру кода, получаем, что требования к системе приемника выражаются в использовании CPU на ГГц-ы и наличия нескольких Гегабайт памяти. Но при увеличении датчиков до дцати, и такая система не справляется в десятки ms... А итоге просыпающийся контролер вынужден ждать подтверждения передачи своего байта от датчика сотни ms, жрать батарейку и иметь громадную программу для обслуживания собственного выдуманного протокола передачи 1 байта по UDP с доставкой и кучу ресурсов для её поддержки.
В случае с TCP - имеющиеся реализации для обслуживания полного трафика WiFi умещаются в десятку килобайт и требуют производительности МСU с частотами на не более 20 Mhz. Пример - TCP/IP стек LwIP. Он уже отлажен за десятки лет, в отличии от вашего ещё не написанного протокола. И даже ваш протокол с UDP не обходится без него - кто будет обрабатывать уровень IP ?
Есть хороший пример - протокол RTP, базирующийся на UDP до сих пор не реализован на ESP8266.

Странная у вас логика.
Когда вам выгодно, Вы ESP считаете велосипедом, а когда не выгодно, начинаете рассуждать будто ESP - это главный компьютер атомной станции.
Вы уж определитесь как-то. Для каких задач ESP.
И надо ли городить огород по среди пляжа.
-----------------
Я делаю очень просто. Приняли UDP - отдали эхо.
Послали UDP - есть эхо -ушли спать, нет эхо , подождали заданный тайм не боле 100 мс и ушли спать или повторили (кому как нравится).
--------------------
что же касается TCP,то при единственном пакете, если Вы его не получите, то значить соединения нет и будете снова соединяться. Оно чем лучше?
------------------
Проверял на компе по tCP коротких пакетов теряется больше чем по UDP.

 

[pvvx]

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

Определился и давно. Ни для каких на современном уровне. Есть более достойные замены.

Я делаю очень просто. Приняли UDP - отдали эхо.
Послали UDP - есть эхо -ушли спать, нет эхо , подождали заданный тайм не боле 100 мс и ушли спать или повторили (кому как нравится).
--------------------
что же касается TCP,то при единственном пакете, если Вы его не получите, то значить соединения нет и будете снова соединяться. Оно чем лучше?
------------------
Проверял на компе по tCP коротких пакетов теряется больше чем по UDP.

Что такое tCP?
То, что вы проверяли и приводили, не вписывается в стандарт WiFi. В "глушилку" вписывается.
При просыпании надо соединиться с AP, получить/подтвердить IP, передать ваш пакет UDP, дождаться отработки его приема на внешнем приемнике, принять подтверждение, послать сигнал разрыва связи к AP, уснуть опят на несколько минут.

В чем различия с TCP?
Оно заключается в том, что не надо ждать подтверждения от высокого уровня ПО на приемнике. Это отрабатывает оптимизированный низкоуровневый драйвер TCP стека в приемнике. Он в системе имеет более высокий приоритет и не стробируется системными тиками для прикладного ПО. Т.е. его реакция в сотни раз быстрее. Верхнему уровню не требуется обрабатывать прием в реальном времени. Пришедший байт находится в очереди приема и может быть считан верхним уровнем спустя годы.
Как итого - TCP в сотни раз быстрее обрабатывается в местной интрасети, чем сложные UDP протоколы, требующие скоростной реакции верхнего уровня ПО.

 

[pvvx]

Гуру Nicolz- Вопрос темы читали?
Куда вас всё тянет cидиотскими предложениями?
Сравнение, замеры и прочее по UDP предоставлено. Сделано стандартными методами, а не хулиганскими - по типу вашей "глушилки WiFi".

 

[nikolz]

Определился и давно. Ни для каких на современном уровне. Есть более достойные замены.
Что такое tCP?
То, что вы проверяли и приводили, не вписывается в стандарт WiFi. В "глушилку" вписывается.
При просыпании надо соединиться с AP, получить/подтвердить IP, передать ваш пакет UDP, дождаться отработки его приема на внешнем приемнике, принять подтверждение, послать сигнал разрыва связи к AP, уснуть опят на несколько минут.

В чем различия с TCP?
Оно заключается в том, что не надо ждать подтверждения от высокого уровня ПО на приемнике. Это отрабатывает оптимизированный низкоуровневый драйвер TCP стека в приемнике. Он в системе имеет более высокий приоритет и не стробируется системными тиками для прикладного ПО. Т.е. его реакция в сотни раз быстрее. Верхнему уровню не требуется обрабатывать прием в реальном времени. Пришедший байт находится в очереди приема и может быть считан верхним уровнем спустя годы.
Как итого - TCP в сотни раз быстрее обрабатывается в местной интрасети, чем сложные UDP протоколы, требующие скоростной реакции верхнего уровня ПО.

Все, что вы написали может быть или не быть. В литературе написано иное. В своих устройствах (называйте их как хотите, можете даже горшками) я наблюдаю иное. При этом устройство просыпается отсылает uDP принимает эхо и засыпает. И все это за 370 мс и не мешает другим устройствам.
Допускаю, что у Вас все сложнее и круче, но меня устраивает то, что работает без проблем и работает в соответствии с документацией.
-------------------
Можете доказать что ТСР в 100 раз быстрее UDP на ESP? Нет
Ну хотя бы на 1 процент быстрее ? Можете доказать?

 

[pvvx]

Зачем пользователю писать в “собственной прошивке” какие-то нагромождения?
Чтобы достоверно передать 1 байт пользователю надо вписать: открыть socket c атрибутом TCP, передать байт в socket, закрыть socket.
Т.е. 3 строчки кода и по желанию обработку ошибок открытия со стандартными сообщениями и известной реакцией.
Для UDP требуется написать целый драйвер протокола с теми-же функциями, но другим атрибутом открытия socket.
А итог уже описан:
Для TCP: полная совместимость со всеми, время исполнения меньше, ошибок ноль.
Для UDP: никакой совместимости, неизвестное время исполнения, толпа возможных ошибок.

 

[pvvx]

Можете доказать что ТСР в 100 раз быстрее UDP на ESP? Нет

Уже доказано. Годы назад. Пару сообщений ранее даны ещё результаты. Глазки разуйте.
Данных от вас нет - сравнивать не с чем

 

[nikolz]

Зачем пользователю писать в “собственной прошивке” какие-то нагромождения?
Чтобы достоверно передать 1 байт пользователю надо вписать: открыть socket c атрибутом TCP, передать байт в socket, закрыть socket.
Т.е. 3 строчки кода и по желанию обработку ошибок открытия со стандартными сообщениями и известной реакцией.
Для UDP требуется написать целый драйвер протокола с теми-же функциями, но другим атрибутом открытия socket.
А итог уже описан:
Для TCP: полная совместимость со всеми, время исполнения меньше, ошибок ноль.
Для UDP: никакой совместимости, неизвестное время исполнения, толпа возможных ошибок.

Я Выше привел код колбека отправки.
В нем две строки.В колбеке прием четыре.
Поэтому не надо ля-ля.
TCP сделали для передачи по сетям с альтернативными путями и как следствие асинхронности доставки пакетов либо большое число пакетов и плохая сеть.
Иэ этого и надо исходить.
Если этого нет, то TCP избыточно.
Вот и вся логика выбора. Но у вас полагаю все гораздо сложнее.

 

[pvvx]

Я Выше привел код колбека отправки.
В нем две строки.В колбеке прием четыре.
Поэтому не надо ля-ля.
TCP сделали для передачи по сетям с альтернативными путями и как следствие асинхронности доставки пакетов либо большое число пакетов и плохая сеть.
Иэ этого и надо исходить.
Если этого нет, то TCP избыточно.
Вот и вся логика выбора. Но у вас полагаю все гораздо сложнее.

Даже TI (С3200) вам привело графики для специального режима IoT, который мы не очень-то может использовать в ESP. Вы даже его сами копипастили на форум Этот режим работы без разрыва связи с AP, в котором устройство отключается на один период или пару периодов beacon (DTIM= N). Но ESP с SDK от Espressif не успевает перезагружаться за стандарт периода beacon– от 60 ms и попадать точно в окно приема beaconдля возможности считывания арбитража WiFi от AP для передачи своего пакета и анализа готовых данных для приема у AP.

Он так-же не годится при большом кол-ве устройств. Только дорогостоящие AP могут держать множество клиентов.

И в таком режиме потребление ESP больше, чем в WiFisleep = LIGHT.

По этому не "ля-ля", а "тру-ля-ля" - в который раз вам это напоминать ?

PS: Фричество и синдром не восприятия чужого опыта вас доведет до нервных срывов, что уже и наблюдаем.
Информацию вы уже не можете воспринимать. Для осознания полной картины работы устройств с WiFi вам очень далеко. От этого каждое ваше предложение неверно. А если индивидуум всегда ошибается, то это - печалька и грозит дурными последствиями для него
Так што садитесь “на попу” и изучайте стандарты WiFi, делайте эксперименты и сравнения на разных устройствах. Потом, возможно найдете какие решения, подходящие для представленного на рынке оборудования и сможете сравнить их качество…