Энергосбережение в устройствах с WIFI

[nikolz]

Добрый день Всем!
В данной теме выкладываю информацию по вопросу энергосбережения в автономных устройствах при использовании сетевого обмена.
просьба к читателям и писателям по возможности не только зубоскалить, но и излагать свои результаты вычислений и экспериментов.
и так начинаю.
Сравнение времени связи на протоколах TCP и UDP .
Вот такие экспериментальные исследования я нашел.
конфигурация тестируемой сети. Посылалось 20 сообщений по 4 полезных байта каждое.

результаты:
В условиях качественного обеспечения передачи UDP протокол показал себя с хорошей стороны, так как все дейтаграммы дошли до адресатов. По времени было затрачено 32ms.

При плохом качестве линий не все пакеты дошли до пунктов назначения.
Использование UDP на плохих линиях может быть если информация за время задержки или потери станет неактуальна, и ее можно не передавать.
К примеру, датчики умного дома.

Результаты по протоколу TCP говорят о неэффективном использовании данным протоколом качественных линий, так как дополнительное время тратится на подтверждение пакетов, а также на установление и разрыв связи.

Передача по TCP заняла 344ms, что в 10.75 раза больше, чем по UDP.

 

[Vladimir555]

Передача по TCP заняла 344ms, что в 10.75 раза больше, чем по UDP.

Передача по TCP заняла 344ms, что в 10.75 раза больше, чем по UDP.

Это сразу было заметно и при передачи потоковых данных, жаль что в проекте TCP2UART от Pvvx нет галочки UDP .
Режим с UDP2UART без контроля ответа и переполнения присутствует в разных серийных переходниках типа TIBBO и т.д.
Несколько раз пытался уговорить Pvvx на добавление режима UDP в переходник TCP2UART.
Жаль ...

 

[pvvx]

Потребление модулем зависит всего на пару процентов от протокола в режимах энергосбережения.
Главное потребление у ESP8266 происходит при загрузке и соединении с внешней AP. Тут худшая прошивка по скорости инициализации = NodeMCU.
Далее зависит от фиксирован IP адрес или нет на роутере и какой роутер. Это дело занимает от 0.7 секунд на ESP8266 + dhcp ещё от 0.7 сек. И тут худшая прошивка по скорости инициализации = NodeMCU, т.к. использует прерывание защиты (много-много тактов CPU) для побайтного чтения данных из flash.
И далее идет передача - прием. На TCP, как описано в примере, 20 пакетов на ближний источник/сервер (нормальный пинг 1 ms) - это от 20 до 50 ms, опять-же если это не Lua на NodeMCU! В случае соединения к удаленному серверу на TCP прибавляйте около 10 времен пингов.
Итого: загрузка и соединение используя китайский SDK на ESP8266 - от 2 сек со средним потреблением за 100 mA и передача информации в 40 ms
На RTL8710 - минимум всё в два раза меньше, т.к. при соединении с AP используется аппаратная часть шифрации eas...

 

[nikolz]

Выкладываю результаты исследований китайских товарищей:
Постановка задачи такая:
ESP подключается к точке доступа передает данные и потом спит.
Общее время 16 секунд. передача данных 5 секунд, спит 10 секунд.
Два протокола
UDP:


ESP-NOW( аля Ethernet):


На картинках наглядно видно время работы передатчика при UDP и при ESP-now
В результате
средний ток потребления UDP -30ма
средний ток потребления ESP-now - 6.8 ma

 

[DarkByte]

Забавное "исследование", но неплохо было бы привести тестовый код, с использованием которого производился замер.

В локальной сети "умного дома" использовать UDP смысл имеет, но нужно понимать, что протокол не гарантирует ни доставку, ни очерёдность пакетов.

Если устраивает то, что дом превращается в тыкву во время загрузки торрентов, то конечно стоит сэкономить 10мс времени (при 1мс пинге в локалке дома) на установке TCP сессии.

 

[DarkByte]

Я понимаю,что вы читали про UDP и TCP теперь повторяете прочитанное.
Но ...
Причем тут торенты?
-------------------------------
Вы хотя бы понимаете отличие локальной сети от интернета?
------------------------------------------------------
Вы хотя бы представляете,
когда, почему и где возникает нарушение очередности поставки пакетов?
----------------------------------------------------
Вы хотя бы понимаете механизм потери пакетов в локальной сети и в глобальной?
--------------------------------------------
Полагаю, что нет.
Иначе бы не повторяли азбучные фразы про ТСР применительно к локальной сети.

Не правильно понимаете. Нарушение очерёдности пакетов можно увидеть даже при отправке пакетов на локалхост, но об этом в азбуке наверное не пишут.

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

 

[nikolz]

Не правильно понимаете. Нарушение очерёдности пакетов можно увидеть даже при отправке пакетов на локалхост, но об этом в азбуке наверное не пишут.

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

почитайте хотя бы это:
Реализация Reliable Udp протокола для .Net

 

[pvvx]

почитайте хотя бы это:
Реализация Reliable Udp протокола для .Net

Играются. Пытаются повторить TCP на UDP пакетах с другой расстановкой битиков в пакете Дело перспективное - в одном пакете UDP несколько тысяч битиков...

 

[DarkByte]

почитайте хотя бы это:
Реализация Reliable Udp протокола для .Net

Отличная статья для изучения .NET, но я ведь попросил привести тот код, которым вы замеряли скорость отправки пакетов по tcp и udp.

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

 

[pvvx]

Отличная статья для изучения .NET, но я ведь попросил привести тот код, которым вы замеряли скорость отправки пакетов по tcp и udp.

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

Nikolz не знает где он взял эти скрины с осциллографа. Писать программы он умеет в совершенстве только на Lua, но ESP8266 имеет кривую реализацию данного языка. Тут ему ничем не помочь.
В связи с перечисленным, ему не создать нормального рабочего замера. Выкручивается, путем подтасовки неизвестных ему замеров, с целями, чтобы вы ему всё объяснили и разложили по полочкам. Такая вот метода обучения у него...

 

[DarkByte]

Nikolz не знает где он взял эти скрины с осциллографа. Писать программы он умеет в совершенстве только на Lua, но ESP8266 имеет кривую реализацию данного языка. Тут ему ничем не помочь.
В связи с перечисленным, ему не создать нормального рабочего замера. Выкручивается, путем подтасовки неизвестных ему замеров, с целями, чтобы вы ему всё объяснили и разложили по полочкам. Такая вот метода обучения у него...

Ну видимо как то так. Скрины используются в статьях メモ： ESP8266 での実測電流 | tech - 氾濫原 и ESP8266 の低消費電力の限界をさぐる (ESP-NOWを使ってみる) | tech - 氾濫原 и не совсем понятно зачем тут приведены, ведь на них показывается не сравнение tcp и udp, а сравнение традиционного способа отправки данных (соединение с вифи точкой, отправка данных на сервер) и альтернативного, в котором два esp модуля общаются между собой без установки wifi соединения, просто по эфиру, примерно как модули на 433мгц, со всеми вытекающими из этого особенностями.

Ну а касательно проблемы с tcp стоит отметить, что для отправки 20 пакетов на один сервер требуется установить 1 коннект, а не 20, как это делают некоторые. Кроме того, данные можно отправлять не сразу, как это например сделано в примере, показанном на скриншоте, 4 чтения датчиков и 1 отправка данных в сеть. Ну а если прям совсем жалко тратить драгоценную энергию на отправку SYN пакетов, то после отправки данных коннект можно не рвать, и после выхода из сна использовать его повторно.

 

[nikolz]

Nikolz не знает где он взял эти скрины с осциллографа. Писать программы он умеет в совершенстве только на Lua, но ESP8266 имеет кривую реализацию данного языка. Тут ему ничем не помочь.
В связи с перечисленным, ему не создать нормального рабочего замера. Выкручивается, путем подтасовки неизвестных ему замеров, с целями, чтобы вы ему всё объяснили и разложили по полочкам. Такая вот метода обучения у него...

Вы все в телепатию играете...
Судя по тому, что Вас зациклило на моем знании LUA и не только, у Вас очевидно душевная травма из-за этого.
Вы всем пытаетесь рассказать о том, что я знаю.
Я конечно признателен Вам за разъяснения любопытствующим знаний обо мне.
Раньше, когда за глаза судачили о других, это называлось сплетнями.
Сейчас, судя по Вашим разъяснениям другим о моих способностях, это очевидно в моде.

 

[DarkByte]

Никто Вам не запрещает делать как Вы хотите.
И обращать внимание на неправильные тесты.
Тем более, что в скринах речь идет не о TCP и UDP, а об UDP и ESP-now.
Но Вам с pvvx все по ... лишь бы зубоскалить ..
А ту его..

К сожалению, ни ссылку на китайских товарищей, ни ссылку на исследование, результаты которого описаны в первом посте выложить вы не удосужились.

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

Увы, но личности обсуждать у меня нет совершено никакого желания, меня интересовала техническая сторона вопроса, а вы по теме ну никак не хотите отвечать.

 

[nikolz]

К сожалению, ни ссылку на китайских товарищей, ни ссылку на исследование, результаты которого описаны в первом посте выложить вы не удосужились.

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

Увы, но личности обсуждать у меня нет совершено никакого желания, меня интересовала техническая сторона вопроса, а вы по теме ну никак не хотите отвечать.

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

 

[nikolz]

и тему я эту завел для изложения информации по данному вопросу и обсуждения.

 

[pvvx]

Вы все в телепатию играете...

Никак нет.

Раньше, когда за глаза судачили о других, это называлось сплетнями.

Уже указали, что ссылок на скопипастенные картинки нет. Оно и получается - разводите сплетни.

WiFiплохо приспособлен для “низкого энергопотребления”. На обсуждаемых модулях, ESP8266 и ESP32, на соединение ST->AP c получением IP уходит от 2 секунд активной работы приемника/передатчика WiFi с полной загрузкой CPU.

Вам остается выбрать из двух вариантов:

“Без разрыва соединения” - после включения модуля и установления соединения “засыпать” на короткое время, до пары “беаконов” и постепенно, через короткие промежутки передавать/принимать данные с довесками над протоколом UDP или по TCP… (данный вариант жрет много)

“С разрывом соединения” – после включения модуля и установления соединения быстро всё передать/принять и усыпить модуль на длительный срок. Тип передачи UDP или TCPв данном случае безразличен – результат потребления не меняется.

Использовать WiFi как простой приемник-передатчик RAW данных без стандартов, выдумав свой протокол. Для этого всё равно требуется какой-то протокол, который будет выжирать питание за его счет обработки CPUи глючить, т.к. протокол не отлажен и многое в нем не учтено.

Ожидаем от вас демонстрации такого протокола на Lua для ESP.

 

[nikolz]

Так как от зубоскалов ожидать что-либо конкретное по данной теме не приходится,
выкладываю результаты собственного эксперимента и замера:

это картинка динамики потребления ESP (сигнал инверсный)
Режим работы ESP
протокол UDP пакет 21 байт. Период посылок 100 мс.
На картинке видим импульсы включения передатчика.
В первом включении есть коллизии в эфире, поэтому передатчик запускается несколько раз.
Потерь пакетов нет.
Длительность включения передатчика 200 мкс
Измерения амплитуды импульсов и постоянной составляющей
показали следующее:
ток в паузах 60 ма
ток в импульсе 195 ма.
Энерго потребление можно посчитать.

 

[pvvx]

Так как от зубоскалов ожидать что-либо конкретное по данной теме не приходится,
выкладываю результаты собственного эксперимента и замера:

Зубоскалы давно выложили графики замеров во всех режимах для ESP8266 более года назад, для RTL8710AF - месяц назад.

Энерго потребление можно посчитать.

Такими методами, при использовании Lua в NodeMCU, авто-аккум 60 А/ч полностью (безвозвратно) умрет через месяц.
А теперь расскажите подробнее - это посылки или beacon?

 

[nikolz]

Зубоскалы давно выложили графики замеров во всех режимах для ESP8266 более года назад, для RTL8710AF - месяц назад.
Такими методами, при использовании Lua в NodeMCU, авто-аккум 60 А/ч полностью (безвозвратно) умрет через месяц.
А теперь расскажите подробнее - это посылки или beacon?

Зубоскалы - это не Вы. К Вам я привык. но есть разные моски, которые вообще ничего, кроме испражнений не выкладывают на форум. Им все подай да выложи.
--------------------------------
Но более года назад не было режима ESP-now, да и SDK имели ляпы.
Поэтому полагаю, что Ваш анализ не полный. Да и в nodemcu Вы ничего не измеряли. Поэтому мои измерения будут первыми.
--------------------------------
Относительно времени работы. Я не включал режим сна. Это еще впереди.
Моя задача была выяснить особенности обмена пакетами с использованием на ESP lua и различие UDP и TCP.

 

[pvvx]

Поэтому полагаю, что Ваш анализ не полный. Да и в nodemcu Вы ничего не измеряли. Поэтому мои измерения будут первыми.

На Lau это не актуально - можете забыть и забить.
С режимом сна она не работает как надо. По времени соединения к внешней AP RTL87xx (с условием использования SDK) на два шага впереди (по времени и по потреблению за это время). Скорости передачи данных у них примерно одинаковы (1 мегабайт в сек).