Делюсь опытом Мониторинг и управление. ESP8266 и WebSocket.

[view24]

Мои 20 копеек в тему IOT - интернета вещей. Простой скетч для мигания, он же для отправки и приема числовых данных, он же для сохранения и отображения последних 10 000 точек измерений. На другом конце - ПАНЕЛЬ, т.е. картинка в любом браузере с графиками и кнопками управления.
http://view24.ru

Сам скетч на сайте http://view24.ru

​

Начиналось это на научном предприятии и работает с лабораторным оборудованием до сих пор. Живой пример работы в реальном времени http://view24.ru/test24

​

 

[pvvx]

Почему написано 10000 точек, а отображает меньше?
Виснет что-ли периодически

 

[view24]

Уважаемый pvvx, внизу панели есть кнопочки, которыми устанавливается количество точек для просмотра - от 15 до 10000. Про зависания могу сказать, что используется websocket, (кстати, с частотой передачи 1 точка/сек) и зависания могут быть либо по причине слабого интернета либо скорости компа. Вы бы очень помогли, если бы рассказали о параметрах быстродействия интернета у Вас.

 

[pvvx]

Уважаемый pvvx, внизу панели есть кнопочки, которыми устанавливается количество точек для просмотра - от 15 до 10000. Про зависания могу сказать, что используется websocket, (кстати, с частотой передачи 1 точка/сек) и зависания могут быть либо по причине слабого интернета либо скорости компа. Вы бы очень помогли, если бы рассказали о параметрах быстродействия интернета у Вас.

В низу панели, если двигать указатель "влево", то он упирался в 9400 и происходил отсчет далее (прибавление кол-ва замеров раз в секунду). При следующей загрузке, или если подождать, то он доходил до 10001 и это был максимум. Далее всё циклически сдвигалось.
Т.е. имело место, что в буфере было всего 9400 отсчетов.
Вы сами не знаете что даете? Я дождался ночью, чтобы он дошел до 10001 и заскриншотил:

У меня интернет в предел 100MB/s и фиксированный IP, особенно ночью, т.к. не мешают телеканалы для детей В таком состоянии уже не помню сколько лет, оптику на 1GB/s в Питере не хотят ко мне тащить.

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

 

[view24]

Вот теперь все сделано правильно. Отражаются события между 9341 точкой и последней 10001 точкой. И Вы совершенно правы, что правая последняя точка не будет иметь номера больше 10001. Это потому, что точки начала начала графика с течением времени удаляются из панели. Каждую секунду одна точка поступает в панель, одна - самая ранняя - удаляется. В противном случае - час работы компьютера или смартфона приводил бы к увеличению точек в буфере на 3600 единиц. И вот тут уже реально начались бы замедления. А в действительности график-то ползет себе, напоминая ленту регистратора.

 

[pvvx]

Вот теперь все сделано правильно. Отражаются события между 9341 точкой и последней 10001 точкой. И Вы совершенно правы, что правая последняя точка не будет иметь номера больше 10001. Это потому, что точки начала начала графика с течением времени удаляются из панели. Каждую секунду одна точка поступает в панель, одна - самая ранняя - удаляется. В противном случае - час работы компьютера или смартфона приводил бы к увеличению точек в буфере на 3600 единиц. И вот тут уже реально начались бы замедления. А в действительности график-то ползет себе, напоминая ленту регистратора.

Про то и говорю - по началу было 9400 в пределе - последняя точка (если весь график сжать кнопкой "."). Затем, в течении 600 сек он дорос до 1001 и безусловно закольцевался - начало удалялось, а новое появлялось. Далее, через какое-то время, при следующем заходе, там было 9600 точек всего(!). Ждать не стал, но кол-во их росло.
Исправляйте
Возможная причина:
При работе ESP8266 всегда (!) происходят дыры в передаче более 1 сек, связанные с его софтом WiFi драйвера. При этом он ругается в лог, какими-то цифрами из потрохов драйвера WiFi. Так-же, при появлении короткого импульса сильной помехи, у него сносит АРУ (может что-то другое), но это вызывает длительную паузу в передаче данных с него + идут пакеты реконнекта стека TCP (у вас же web-soscket!). Т.е. имеем дырки, а сервер принимает по часам - ставит принятым точкам метки по времени приема пакетов. Итого, если были пробелы, то пачка точек придет в одну и ту-же единицу времени отсчета сервера и он их поместит в одну точку. Дальше сообразите сами - вы же научное предприятие, которое считает трафик передачи перемножая кол-во бит данных, забывая о маркерах времени для каждой точки и атрибутов пакетов, если они малых размеров, да о арбитраже диктуемом в WiFi AP станцией...

 

[view24]

Я "забыл" не только о маркерах времени, но еще и накладных расходах, связанных с tcp/ip. Но я был первым, кто путем умножения доказал, что пропускная способность канала в 1000 раз превышает потребности, так стоит ли говорить о мелочах?

 

[pvvx]

Я "забыл" не только о маркерах времени, но еще и накладных расходах, связанных с tcp/ip. Но я был первым, кто путем умножения доказал, что пропускная способность канала в 1000 раз превышает потребности, так стоит ли говорить о мелочах?

Считайте заново, с учетом сказанного. Получите почти предел и любой чих или внешний WiFi всё опустит...
Отсылка 1000 шт пакетов (и прием 1000 шт пакетов ACK если TCP) одним устройством в секунду. Прием АСК при TCP можно сократить в 2 раза. Т.е. 1500 пакетов.
С UDP хуже в том случае - будет очень много потерь (почему - вам не укажу - должны сами знать ).
На обработку 1500 пакетов ESP при штатной частоте не тянет, а у вас ещё прием по SPI - жрет процессорное время наверно на 1/5 (пока вы там ковыряетесь в сотне регистров через тормозную шину на 26MHz, чтобы выудить всего 32 бита )
1500*1560 = 2340000 байт при 1500 пакетах на полный MTU. Как видите ему не требуется обрабатывать более 1200 пакетов, чтобы упереться в предел HT20. Ему почти всё равно, есть данные в пакете или нет.
Всё это говорит, что нам, домушникам, далеко до научных предприятий У нас выходит минус, а у вас в 1000 раз. Научите так жить
И в научных предприятиях используют Arduino, где при приеме каждого пакета и других процедурах стоят ожидания в 1 ms для отдачи тиков системе... Тогда, да - действительно в 1000 раз

PS: Блин, напомнили про Разработка параллельного детектора для Open Source CT 2 - совсем некогда заняться и сделать лучше и дешевле... но только 3D спектроскоп на рассеивании, как тама его - Рамана или тоже на Р...

 

[pvvx]

На сайте view24 не расписано полного формата работы websocket.
Надо ковырять какие-то "вимос" "скетчи" от устаревшего модуля, чтобы узнать протокол? (например на посылку "data=1234" какой ответ?)

Получил такой "пинг"

Connect ws://view24.ru ...
>>>>>>>>>>>>>>>Connected to websocket server<<<<<<<<<<<<<<<<<<
ws: connected, state = OPEN
ws: send text msg
ws: rx txtmsg[8]: 'ping=ok;'
ping 47 ms
ws: send text msg
ws: rx txtmsg[8]: 'ping=ok;'
ping 51 ms
ws: send text msg
ws: rx txtmsg[8]: 'ping=ok;'
ping 48 ms
ws: send text msg
ws: rx txtmsg[8]: 'ping=ok;'
ping 47 ms
ws: send text msg
ws: rx txtmsg[8]: 'ping=ok;'
ping 50 ms
>>>>>>>>>>>>>>>Closing the Connection with websocket server<<<<<<<<<<<<<<<<<<

~50 ms на сообщение туда и прием.
Модуль RTL8710AF.
На SSL:

Connect wss://echo.websocket.org ...
>>>>>>>>>>>>>>>Connected to websocket server<<<<<<<<<<<<<<<<<<
ws: connected, state = OPEN
ws: send text msg
ws: rx txtmsg[6]: 'ping='
ping 138 ms
ws: send text msg
ws: rx txtmsg[6]: 'ping='
ping 136 ms
ws: send text msg
ws: rx txtmsg[6]: 'ping='
ping 135 ms
ws: send text msg
ws: rx txtmsg[6]: 'ping='
ping 135 ms
ws: send text msg
ws: rx txtmsg[6]: 'ping='
ping 138 ms
ws: send binary
>>>>>>>>>>>>>>>Closing the Connection with websocket server<<<<<<<<<<<<<<<<<<

Но wss://echo.websocket.org по жизни тормоз...

 

[view24]

Модуль RTL8710AF

Спасибо за эксперимент, 50ms - это я думаю неплохо для недорогого VPS.

 

[pvvx]

Спасибо за эксперимент, 50ms - это я думаю неплохо для недорогого VPS.

Ужасно, но даже не в этом дело.
Как и писалось, ваш сервер имеет ошибки. Если передавать чаще 1 сек, то показывает последнюю точку. График смешно прыгает при получении новых значений пока не истекла секунда, но выставляет при переходе на следующую секунду прямую, соединяющую предпоследнюю стробированную точку данного отрезка с прошлым.
Но и это не всё - если передавать точки с паузой менее 120 ms, то ваш websocket глючит и вдобавок не воспринимает ни какие точки, пока пауза передачи между ними не будет больше.
Всё это говорит о том, что его использовать, кроме как посмеяться - нельзя.
Дельта "пинга" (передача соо - ответ) за пару тысяч точек достигла 500 ms. Часто выпадает при нажатии кнопки передачи чего устройству (помигать LED) на графике. Говорит о том, что сервак уже перегружен.
50 ms - это пинг сервака на другой стороне шарика... имея в виду расстояние
Приучаете народ к задержкам на "пинг" с серверами на Марсе?
В общем всё, что писалось, что ночью он терял точки с вашего тестового устройства - подтвердилось на 100 %. Любой сбой (тормоз) в сети до вашего сервака и точка с графика выпала - передать её повторно нельзя, не выждав паузы после прием ответа на прием прошлой точки от сервера ...
Нет смысла в таком websocket, если за его время приема точки можно открыть и закрыть десяток HTTP соединений на ESP8266 - Кол-во и скорость открытия множественных Web соединений (JMeter) (это является доказательством, что проблема не в оборудовании, а в сотрудниках "научного предприятия" - британские учёные... )
Но заодно нашел ущербности websocket входящего в либу Realtek к SDK RTL871xAx... Надо переписывать...

 

[view24]

Спасибо большое за Ваше внимание к моей работе. Наверное, столько постов к моей работе по WebSocket для ESP8266 от выдающегося метра IT дорогого стоят. Кстати, не против продолжения экспериментов по исследованию надежности нашего WebSocket сервера на предмет живучести. В связи с чем, разрешаю испытать наш сервер на максимальной нагрузке. Мы сами делали это много раз, но последняя версия работает надежно даже при наличии тысячи клиентов. Просьба сообщить, когда 'положите WebSocket сервер View24 ' по email - view24.ru@mail.ru Спасибо. А пока все работает, в чем можно убедиться, зайдя на http://view24.ru/test24

 

[pvvx]

Спасибо большое за Ваше внимание к моей работе. Наверное, столько постов к моей работе по WebSocket для ESP8266 от выдающегося метра IT дорогого стоят. Кстати, не против продолжения экспериментов по исследованию надежности нашего WebSocket сервера на предмет живучести. В связи с чем, разрешаю испытать наш сервер на максимальной нагрузке. Мы сами делали это много раз, но последняя версия работает надежно даже при наличии тысячи клиентов. Просьба сообщить, когда 'положите WebSocket сервер View24 ' по email - view24.ru@mail.ru Спасибо.

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

 

[view24]

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

'глючковый сервак' - это что-то новое, не ожидал от 'корифеяIT'.

 

[Сергей_Ф]

@view24 политкорректность никогда не была сильной стороной @pvvx. Вы суть смотрите. Обидно? Возможно. Но он дал Вам шанс и направление сделать лучше. Разве не так?

 

[view24]

@view24 политкорректность никогда не была сильной стороной @pvvx. Вы суть смотрите. Обидно? Возможно. Но он дал Вам шанс и направление сделать лучше. Разве не так?

Сергей, абсолютно согласен. Если у читателей возникают вопросы, то не надо парировать эти вопросы, надо сделать так, чтобы вопросов не возникало. Это мне объяснили давно. Поэтому я благодарен @pvvx.

 

[pvvx]

'глючковый сервак' - это что-то новое, не ожидал от 'корифеяIT'.

Вы с потерей точек разобрались? Или нет? Они же будут теряться, даже если передавать реже 1-го раза в секунду. В сети пакеты приходят как попало и имеют разные задержки, а ваш сервак не ест точки, если между ними нет его любимой паузы. Самое интересное в этом - как умудрились сделать это(?). Если писать в лоб, то так не получиться.
Посылаем сообщение новой точки на графике, предположим оно где-то застряло по пути и пришло через 1.01 секунд на ваш сервер. Он его съел, поместил в график и отправил подтверждение. Мы приняли подтверждение, а по счетчику времени у нас пора передавать следующую точку. Мы её и передаем... она приходт на глюк-сервер, пусть через 10 ms. Тут глюк-сервер обиделся - не прошла его специально программно вставленная любимая пауза, и кушать точку не хочет и занимается неизвестно чем. Усё - протокол нарушен, точка пропала...
Если серверу не сожрать несколько точек из-за проблем в графиках, то самое простое решение - отказаться от протокола запрос-ответ. Посылаем хоть 100 сообщений точек, не дожидаясь ответа. У нас вроде не UDP Сервер их съест и выведет на график среднее за свой любимый промежуток. При этом ему не обязательно передавать ответы на прием каждой точки.
Но это тоже решение глупой проблемы, связанной с невозможностью подписи времени точки точнее 1 сек для данных графика. Более нормальное решение для отображения(!) - выводить мин и мах за промежуток. Но оно не позволяет рассчитывать среднее значение за период.
"Глючковатый" сервер и назван, по причине невозможности обработки данных с него ни для каких расчетов. И нафига для таких данных какая-то стабильность сервера? Ну рисует картинки - может и падать - картинки будут веселее...
Так-же очень сильно перегружен интерфейс ответов. Зачем тупому IoT устройству знать куда и как сервер поместил отосланную точку? Он его посылку с временем в его формате в жизнь не разберет - ресурсов не хватит, а вот время и память для приема этой длинющей аброкадабры необходимо на устройстве выделить, чтобы понять в вашем запросно-ответном протоколе, что точка дошла, и только после этого, выждав паузу, можно передавать другую. Вот зачем это всё? Писал любитель-фрик? Мало гарантированной доставки в TCP, надо обязательно ввести поверх свой протокол подтверждения доставки? Наверно сеть мало нагружена и надо было её забить отсылкой простыней о самочувствии сервера с его дня рождения А почему он не отсылает dmesg на любое сообщение в websocket? Программист-фрик постеснялся?

 

[view24]

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