Скорость обмена WIFI

[nikolz]

Всем пламенный привет.
Полагаю, что всех интересует какую же реально скорость обмена по WIFI может обеспечить ESP в системах умных вещей.
В данной теме буду выкладывать информацию по данному вопросу.
Начну с результатов следующего своего эксперимента.
---------------------------
Все делается на LUA.
----------------------------------
Имеем nodemcu D1-mini.
Пишем программу, которая по прерываниям таймера через 1 секунду отсылает на компьютер через роутер пакет длиной 21 байт. WIFI ESP установлен PHYMODE_B.
Расстояние от ESP до роутера 12 метров , две стены и одна дверь.
Роутер за углом.
---------------------------------
На компьютере запускается программа на луа с довеском DLL на Си реализующий сервер UDP и TCP.
Для контроля пакетов используем wireshark.
--------------------------
Результаты:
Все пакеты приходят без ошибок и без потерь.
Время отправки одного пакета UDP =1.9 мс
Время отправки одного пакета TCP=6.7 мс
Длина пакета не влияет на длительность отправки.
==================================
Продолжение эксперимента.UDP
Для измерения потребления ESP, заменил в эксперименте D1mini(4 Mбайта) на ESP-03(512кбайт )
Немного изменил работу скрипта.
Ранее Открытие,передача и закрытие были размещены в колбеке таймера.
Теперь закрытие размещено в колбеке приема ответа.
в результате время исполнения действий в колбеке таймера составило 1.7 мс вместо ранее 1.9.
При отключенном WIFI потребление 15 ма.
===================================
Продолжение эксперимента. UDP
Установил интервал прерывания от таймера 10 секунд и замерил средний ток потребления.
Средний ток изменяется от 70 ма ,при отправке пакета, до 18 ма в оставшееся время
================================
Для полее точного изучения работы WIFI, в цепь земли модуля ESP03 добавлен резистор в 3 ома.
На картинках приведены осциллоргаммы переменной составляющей напряжения на резисторе.
При этом пакеты UDP посылаются с интервалом 100 мс (0.1 сек)

Как видно из рисунка пакеты содержат разное число импульсов
Отдельный импульс имеет вид:

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

 

[nikolz]

Продолжаю эксперимент.
Работа с протоколом TCP оказалась более сложной, чем предполагалось изначально.
Причиной этого стал неправильный пример в интернете, в котором после вызова connect идет send.
Такая конструкция приводит к отсылки пакета до установления соединения.
Пришлось написать все вызовы колбеков.
В результате получился такой код клиента TCP в nodemcu с выводом на печать интервала времени, которое прошло с момента начала соединения с сервером:

T1=tmr.now();
ip=wifi.sta.getip();
=x+1
msg=T0..';'..node.heap()..';'..tostring(ip);
sv = net.createConnection(net.TCP, 0)
sv:on("receive", function(sck, rec)
sck:close();
T2=tmr.now()-T1; print("receive="..T2.."mks");
end );
sv:on("sent", function(ss) --print("sent");
T2=tmr.now()-T1; print("sent="..T2.."mks");
end);
sv:on("connection", function(sck, c)
T2=tmr.now()-T1; print("connection="..T2.."mks");
  sck:send(msg) ;
end)

sv:on("disconnection", function(sck, c)
T2=tmr.now()-T1; print("end disconnection="..T2.."mks");
end)
T2=tmr.now()-T1; print("подгтовка="..T2.."mks");
T1=tmr.now()
sv:connect(port,adr);
T2=tmr.now()-T1; print("connect="..T2.."mks");

а вот результат тестирования:
-----------------------------------
подготовка=17298mks -- время затраиваемое на исполнение приведенного выше кода до connect
connect=1563mks -- время функции connect
connection=12061mks -- время до соединеия с компом
sent=34599mks -- время отправки пакета
receive=40036mks -- время приема эхо-пакета
end disconnection=45278mks -- время разрыва соединения
--------------------------
Таким образом, получается, что время передачи пакета по TCP не 6 мс, как указано ранее, а 17+45=62 мс.
А 6 мс уходит на завершение колбека таймера от момента вызова функции connect
----------------------------
налогичный эксперимент я провел с протоколом UDP. Для этого протокола есть лишь два колбека и их можно вынести за колбек таймера.
а вот результаты тестирования:
Подготовка=6951mks
connect=890mks
sent=5025mks
receive=17562mks
---------------------------------------
Общее время передачи пакета 6.9+17.5=24.4 мс, вместо полученных ранее 2 мс.
Таким образом,
VM Lua затрачивает
на передачу пакета
по UDP примерно 20 мс,
а по TCP примерно 60 мс.
------------------------------------------

 

[nikolz]

Продолжение...
Изучение времени обмена пакетами.
С помощью программы Wireshark получаем на компе пакеты и измеряем интервал их отправки:
Протокол UDP

015602-015484=118 мкс. -задержка ответа компа.

 

[nikolz]

теперь очередь за TCP:

657437-643146=14921 мкс
-----------------------------------------------------------
Выводы:
При обмене ESP c компьютером OC Windows пакетами в 21 байт, задержка ответа (мкс) компа составляет
UDP = 120,
TCP = 14900.
--------------------------------------------------------------------------------------------------------
Рекомендации.
при использовании UDP и NODEMCU.
минимальная задержка для передачи следующего пакета
без приема ответа 2 мс
с приемом ответа 10 мс.

 

[nikolz]

В данном эксперименте я изучал потери пакетов.
постановка задачи следующая
Прием на компе по виндой, на котором есть и другие исполняемые задачи.
Модуль ESP передает с пакеты в 21 байт с указанием номера пакета.
Эти пакеты принимаются на компе и фиксируется пропуск пакета, если номер принятого отличается от номера предыдущего более чем на 1.
-------------------------
Результаты:
------------------------
интервал посылки пакетов 200 мс
---------------------
UDP: пакетов 1000, пропущенных 0. пакетов 4000, пропущенных 6.
----------------------
TCP: пакетов 1000, пропущенных 12. пакетов 4000, пропущенных 138.
=========================
Не правда ли, Вы этого не ожидали?
=================
Но все не так уж и сложно.
Посылается всего один пакет.
Эфир хороший.
Сеть локальная.
TCP никакого преимущества не имеет.
Одни накладные расходы.
И проблема не в ненадежной связи,
а в загрузке компьютера другими приложениями .
Так сказать - имеем "эффект многозадачной ОС".
Пока все.