MQTT

[kharlashkin]

А чипы MPU уже безбожно устарели - жрут много, а толку мало.

В этом чипе самое вкусное - встроенный процессор, но блин чтобы поковырять исходники для них, нужно спец Dev-Board покупать - мня жаба душит. Новая версия - ICM-20948 по даташитам более энергоэффективная и у магнитометра они еще точности добавили.

Там вообще тапотун - датчик шагов. У него совсем другой алго и уже всё адаптировано в самом железе датчика.

MPU тоже могут считать шаги на чипе без обработки.

 

[pvvx]

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

Это глупость. Минимальная единица передачи в сети IP - пакет с MTU. Для низкоскоростных сетей - это 1500 байт.

Мой домашний - Xiaomi Mini Wifi Router на нем тоже попробую, есть так же где-то в кладовке TP-LINK TL-WR741ND его очередь тоже будет. Именно поэтому все тесты делаю пока на Motorola, потому как по логике, эта ТД лучше должна быть.

Оно соединиться то сможет, но будут отваливаться. А если этот роутер используется и для других устройств, то будут "выпадения" когда более продвинутое устройство начнет что-то качать на пределе. Да и общий максимальный трафик упадет от нескольких ESP просто в окружении роутера WiFi. Кому такое надо?

Кстати мое первоначальное желание было пробовать nrf24L01+. Для теста есть Arduino pro mini + nrf24L01+ и аккумуляторы с платами, правда всего в 4-х экземплярах.

nrf24L01 не имеет нормальных протоколов.

 

[pvvx]

В этом чипе самое вкусное - встроенный процессор, но блин чтобы поковырять исходники для них, нужно спец Dev-Board покупать - мня жаба душит. Новая версия - ICM-20948 по даташитам более энергоэффективная и у магнитометра они еще точности добавили.

MPU тоже могут считать шаги на чипе без обработки.

А нафига вам магнитометр? У вас квадракоптер?
В квартире железобетонного дома от него толку мало. Там такие кривые магнитные поля, что ... А на скоростных магнитометрах одна наводка от сети, с уровнем во много раз более чем МПЗ (более нужного диапазона датчика) и даже его уже не выловить. И так до 50 км от большого города, это как геошизик я вам говорю - ловить там нечего, кроме как ориентироваться или строить алго анализа по самой наводке 50 Гц.

Т.е. вам просто вернут ваши устройства, т.к. они не будут работать у многих.

 

[kharlashkin]

Оно соединиться то сможет, но будут отваливаться. А если этот роутер используется и для других устройств, то будут "выпадения" когда более продвинутое устройство начнет что-то качать на пределе. Да и общий максимальный трафик упадет от нескольких ESP просто в окружении роутера WiFi. Кому такое надо?

Ну я точно знаю что на Motorola (ни у нас в продакшн используются) - и 50 одновременных подключений норм отрабатываются. Пробовали с целью удешевление Ubiquity - тоже полет нормальный, 3 ТД держали 200 подключений (мобильники, планшеты, ноутбуки) в одном помещении. Мне почему-то кажется это ограничение на работу одновременно всего 16 девайсов в беспроводной сети имеет корни со старых протоколов bg, где служебный трафик занимал 2/3 всей полосы.

А нафига вам магнитометр? У вас квадракоптер?

Ну другого решения как стабилизировать Z нет в IMU, только оптика дальше.

 

[pvvx]

Вот тупейший пример, более десятка лет назад, на 3-х датчиках от куллера и 24-х битном ADC, вращение указанного на фото магнита в метре от датчиков 2 об в минуту :

 

[pvvx]

Чувствительность у них больше чем у MPU, за счет нормальных ADC, но смысл в том, что вы на эти поля будете ориентироваться?
Вот у меня есть стол с внутренними железными рамками - дык разница длины вектора МП в 20 см от него более чем в 4-ре раза и имеет наклон более 50 градусов от центра комнаты... А рядом с компом - там вообще ужасть...

 

[pvvx]

У вас разъемы на плате Wemos D1 mini из железных штырей. Это уже более десятка градусов искажений от МПЗ в лесу даст. А так-же ещё их перемагничивание на ходу и проводки питания не забудьте

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

 

[pvvx]

В итого от всего MPU остается только гравитометр. Акселерометр прикручивают только из-того, что гравитометр в MEMS имеет низкое разрешение.

 

[pvvx]

И всякие гироскопы - это просто костыли, т.к. сам датчик как 3-D гравитометр - фиговый.

 

[nikolz]

Ну я точно знаю что на Motorola (ни у нас в продакшн используются) - и 50 одновременных подключений норм отрабатываются. Пробовали с целью удешевление Ubiquity - тоже полет нормальный, 3 ТД держали 200 подключений (мобильники, планшеты, ноутбуки) в одном помещении. Мне почему-то кажется это ограничение на работу одновременно всего 16 девайсов в беспроводной сети имеет корни со старых протоколов bg, где служебный трафик занимал 2/3 всей полосы.

Ну другого решения как стабилизировать Z нет в IMU, только оптика дальше.

Информация к размышлению:
делал тест системы сервер-клиент UDP для "системы умный дом" .
Сервер с одним ядром успевает обрабатывать до 40 тысяч пакетов в секунду.
По UDP можете подключать любое количество, так как нет надобности устанавливать соединение и держать его открытым.
Трафик минимум в два раза меньше.
----------------
Но в вашей задаче может быть лучше использовать ESP-NOW. В этом случае роутер не нужен.

 

[pvvx]

Информация к размышлению:
делал тест системы сервер-клиент UDP для "системы умный дом" .
Сервер с одним ядром успевает обрабатывать до 40 тысяч пакетов в секунду.

Это очень мало для современной сетевой карты. У вас старый ноутбук? И где пример? Думается, что как всегда это опять ваши фантазии... Пустые UDP без обработки в 10 мегабитной сети

По UDP можете подключать любое количество, так как нет надобности устанавливать соединение и держать его открытым.

Это как? Без подключения к AP WiFi или без подключения к интрасети и выдачи IP?
Проблемы с клиентами только в AP.

Трафик минимум в два раза меньше.

В сравнении с чем? С MQTT в HTTPS? C нормальным HTTSP - это возможно, но SSL то своё дело делает, а UDP нет.
Во внешний HTTP MQTT итоговый трафик будет меньше, чем ваш выпадающий UDP, неспособный пробиться через NAT.

Но в вашей задаче может быть лучше использовать ESP-NOW. В этом случае роутер не нужен.

Видно что вы не пробовали ESP-NOW и не смотрели ни одно видео с его демкой или не читали блоги...
У ESP-NOW в супер хороших условиях (в лесу) выпадений более 1/5. В городе и работающем роутере сплошные...
И UDP и в интрасети выпадает, а мазахизм с написанием на него подтверждений приема (преобразование в TCP) - это наверно к вам?

 

[pvvx]

nikolz - для всех платформ и ОС существует такая утилита - ipref. Есть поддержка даже в ESP32 в базе. Включите и посмотрите кол-во выпадений UDP на разных соединениях... Писать вам бесполезно.

 

[kharlashkin]

Сервер с одним ядром успевает обрабатывать до 40 тысяч пакетов в секунду.

Интересно ядро какое. Может же быть что-то как Raspberry Pi.
MQTT работает поверх UDP, но в этом случае думаю и брокер и клиенты должны быть в одной сети.

 

[pvvx]

Интересно ядро какое. Может же быть что-то как Raspberry Pi.
MQTT работает поверх UDP, но в этом случае думаю и брокер и клиенты должны быть в одной сети.

WiFi в идеальных условиях на ESP32 прокачивает до 1200 пакетов в секунду, что равно 1.8 мегабайта сырых данных. Это каждый пакет в полный MTU (1500 байт). При этом битовая скорость выходит практически равная кодировке PHY и в RF кадре пакетик IP выглядит как часть кадра. Предельная длительность занятия эфира регламентирована в 10 ms.
Кол-во кадров RF кадров выходит меньше 1000.
А у фантазера @nikolz -> 40 тысяч пакетов IP уровня, что физически не лезет в WiFi из-за заголовков т.е. преамбула + ACK и физические данные MAC уже не лезут по времени передачи в 40 тысяч раз в сек
Это не влезет и наверно в последние будущие стандарты WiFi (ещё не изучал досконально последние).

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

 

[pvvx]

Ещё не забывайте элементарный пример из прошлого – i386 на сотню MHz не мог прокачать UART на 115200 Baud, т.е. не мог обслужить прерывание 11520 раз в секунду, пока в UART не вставили FIFO на 8 байт И память у него была c произвольным доступом в 40..70 ns и ему опустошение кеша не сильно мешало при прыгании через уровни, а не как счас у DIMM - более 90 ns

 

[pvvx]

kharlashkin - вы пишите на питоне, но проверьте сколько он раз в секунду откроет и закроет элементарный socket, да на одном ядре

Вот пример времени исполнения вызова другого приложения в Linux. Это производится через fork() и аналогичные процедуры.

Ещё раз про fork() / vfork()

Omega2, OpenWRT : 758.9 / 733.6 us
NanoPi-R1, H3, FriendlyWrt, 1.008GHz : 540.3 / 472.8 us
NanoPi-NEO-Core, H5, FriendlyWrt, Ubuntu 16.04.6 LTS 4.14.0 : 328.8 / 314.3 us
Ryzen7 1700, docker 4 ядра, Ubuntu 18.04 : 172.5 / 83.5 us
mc200(MIPS 4KEc), очень старый OpenWRT, 200MHz : 2954.9 / 548.6 us
* Замеры зависят от загрузки системы и многих других параметров, но для сравнения достаточно.

По производительности vfork() близко к запуску и простого треда...
и это сказывается на такой параметр как отзывчивость системы в целом, т.е. основной параметр real-time системы.
Это примерно то, что внешний запрос по сети быстрее чем это время не обрабатывается...

Считаем 1/0.0001725 = всего 5797 раз в сек совершенно пустой web-сервер сможет вызвать/запустить сторонний процесс с запросом и получением данных от него для элементарной отработки одного CGI...
Пустой и не имеющий никаких занятых ресурсов! Иначе время у ядра увеличивается на их дублирование для подготовки среды новому потоку....

 

[Алексей.]

Считаем 1/0.0001725 = всего 5797 раз в сек совершенно пустой web-сервер сможет вызвать/запустить сторонний процесс с запросом и получением данных от него для элементарной отработки одного CGI...

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

 

[pvvx]

Вы это расскажите современным писателям, к примеру uci в OpenWRT, а не мне. У меня и так 200 MHz mips обслуживает 10 тысяч запросов в сек в системе автоматизации... А ныне хочу увеличить ещё на один десятичный порядок и пару раз на более новых CPU...
Я думаю, что вы забываете - не все web работают на развлекушки.

 

[pvvx]

И нету у меня там никаких FastCGI - всё интегрированно в один процесс, если это можно так назвать

 

[pvvx]

Я ещё раз перечитал ваше сообщение:

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

и это породило навязчивую мысль - а что делает этот ваш описываемый CGI? Грузит картинки по выбору клиентов? Вроде более ничего другого описываемая вами система не умеет. Ну честно - не вижу смысла в ней - поиграть в рисование HTML страниц? Онлине-магазин и вроде всё, на что годится такое...