• Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

Обсуждение AdHoc бинарный протокол.

cheblin

Member
Вы видели лучше?
естественно, более лучший - это с 2019 офисом о чём и написал.

русском переводе
русском переводе? но зачем? английский - самый лучший целевой язык.

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

pvvx

Активный участник сообщества
Ну раз сам создатель AdHoc не хочет указать среднюю производительность на каком типовом применнии, то прикинул производительность при WebSocket c десереализацией данных AdHoc при рисовании живых графиков на javascript. Выводы и итоги неутешительные.

Сам драйвер графиков уже тормозит и грузит одно среднее ядро современного CPU на 100%, дык ещё прибавляется код AdHoc.

Поток с WebSocket у нас, считая что это устройство на примитивном WiFi, от 200 килобайт в сек. Если точки кодированы AdHoc, то большинство javascript графических либ не справляются с обработкой отображения набранного потока за несколько секунд. Т.е. ещё как-то отрисовывают одновременно несколько динамических графиков, но уже рывками…

Примерные подсчеты показывают, что сериализация на AdHoc роняет производительнось от 10% от простой несжатой передачи данных поканально, мелкими блоками. Так-же увеличивает объем потока, что требует более широкого канала приема/передачи. АЦП данные они такие… и иногда возможно сжатие но совсем другими алгоритмами…

А было заявлено, что это нужно для online игр, где производительность не на последнем месте.

PS: Для примера был взят среднее пром.устройство с 16 каналами аналоговых датчиков и сотней бит состояния .
 

pvvx

Активный участник сообщества
В общем выходит, что и разница в нагрузке каналов и сервера при AdHoc или JSON кодировании сравнима и сильно не разнится. Почему так – а фиг его знает – может из-за особенностей javascript – плохо он ворочается с бинарными данными, да оптимизированы встроенные парсеры Json. Представление данных всё равно типа "текстовое"...
 

pvvx

Активный участник сообщества
В чем разница применения бинарной сериализации данных от Json.

На приемной стороне обычно имеется виртуальный дубль устройства со всеми его данными. Это необходимо для отображения и распознавания всех состояний устройства пользователю.

Сам процесс: поток данных от самого устройства передает изменение состояний от начально переданного полной картины.

Десериализация входного потока нужна для распределения адресов/индексов изменившихся полей состояния устройства.

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

При передаче данных в формате типа JSON имя переменной уже указано и нет таблицы и парсера перекодировки. Размер данных, что бинарный float, что он представлен в текстовом ASCII виде практически не различается.

Т.е. AdHoc для таких задач не годится - малая эффективность. Но можно его туда впихнуть чтобы дополнительно помаяться и половить дополнительные ошибки.
 

pvvx

Активный участник сообщества
В чем разница применения бинарной сериализации AdHoc от Modbus.

Данные Modbus индексированы номером устройства и адресом.

Данные AdHoc – раскиданными битиками в потоке, которые ещё надо собрать.

Вроде это и вся разница :)
 

pvvx

Активный участник сообщества
русский мало кому интересен, даже самим русским.
В чем разница китайского и английского начертания языка.

В английском потоке символов индекс и данные передаются последовательно распределенными битами размазанными по десяткам символов – требуется десериализация.

В китайском потоке – штампом. Полным индексом практически сразу с данными. Десериализация не требуется.

Итог: креативные англоязычные клоуны питаются адаптировать всё под свою непроизводительную последовательную систему мышления.:)
 

pvvx

Активный участник сообщества
По поводу сжатия потока при использовании AdHoc.

На это есть такая наука как математика. Но фиг с ней и её языком. Попробуем на “кухонном”.

Что имеем – чем больше типов, тем больше ко-во бит индексов и не важно как они распределены в потоке.
Если у нас мало типов – это составит пару бит. Пусть они уложатся в байт вместе с длиной последующих данных. Т.е. в потоке перед данными имеем один байт и в коде простой switch или таблицу.
Для AdHoc так не выйдет – там надо разгребать весь принятый блок и выполнить дестки преобразований. Потом тот-же switch или таблица. При этом сжатия потока как такового не будет. Будет дополнительная нагрузка на вычислитель индексов и развертывание самих данных.
Т.е. для мало типов – AdHoc не нужен.
Если много типов – история повторяется, но теперь уже передается больше бит на единицу данных, что в AdHoc, что при обычном индексировании.
По мере увеличения кол-ва типов их представление в виде ASСII имен сравнивается с “сжатием” AdHoc.

Т.е. применимость AdHoc для сжатия потока сомнительна. Для усложнения десиреализации – да.
 

pvvx

Активный участник сообщества
Теперь о внутреннем представлении данных аппаратными средствами.

У CPU индексация данных представляется в виде адреса памяти. Это индекс от 32-х бит для современных систем (хоть малых). Сами обрабатываемые данные для ALU – так-же от 32-х бит. Т.е. единица информации от 32-х бит. При меньшей разрядности имеем издержки в виде увеличенного размера опкода программы и кол-ва тактов на обработку.

AdHoc по неизвестным причинам использует 8 бит. Это уменьшает производительность сразу раза в четыре, а так-же увеличивает размер кода обработки не менее чем в 2 раза… Это при супер оптимизации для конкретного CPU.

Вопли о том, что кол-во индексов ограничено объемом RAM – не встречал CPU без виртуализации адреса… Т.е. нет никакой необходимости в наличии объема истинной RAM для преставления пространства по индексу адреса у CPU. Давно решено аппаратными средствами без понижения производительности.
 

pvvx

Активный участник сообщества
Вот и выясняется, что AdHoc – это игра для деоптимизации, созданная виртуальным программером ради забавы. Скорее всего, это было создано по совету от “креативных клоунов”...
 

cheblin

Member
что это было пух? что за поток сознания? откуда взялись все эти цифры?

давай сделаем так.
предлагаю организовать Skype голосовое общение, и я смогу быстро и подробно поотвечать.
мой скайп china_it_support
 

pvvx

Активный участник сообщества
что это было пух? что за поток сознания? откуда взялись все эти цифры?
Это такие мысли вслух :)

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

cheblin

Member
Это такие мысли вслух
какието домыслы и спекуляции,

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

pvvx

Активный участник сообщества
Я как "обизяка и очки" - пытаюсь приспособить, т.к. кто-то сказал что это нужная весчь...
У самого такие мысли были - нужно было типизировать и принимать от разных источников данные. В итоге просто написал свой язык конфигурации и перекодирования принятого/передаваемого и оставил протоколы связи те, что есть. Связано ещё с чужим оборудованием в котором ничего не изменить, а так-же и выходной поток может быть ориентирован на готовую чужую систему (аля совместимость) :(
А ныне надо новую аналогичную, но в больших масштабах. Есть норка на внутренний сегмент, где протокол может быть своим...
 

pvvx

Активный участник сообщества
Но это всё мелочи. Необходимо полевая возможность включать новые источники (внешние датчики и т.д.) и просто и быстро встраивать в имеющуюся систему. А AdHoc предполагает внешнее стороннее производство кода с последующей компиляцией, т.е. наличие “в поле”* слишком много…
Приходится изучить имеющее у других и сделать своё.

*“в поле” – на выезде на объекте, простому смертному персоналу …
 

cheblin

Member
пытаюсь приспособить, т.к. кто-то сказал что это нужная весчь...
это правильно и максимально приветствуется

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

совершенно не понимаю откуда эти измышлизмы про современные 64 битовые процесссоры и 8 битный AdHoc???
и что от этого парям бида-бида? шо? гондурас/modbus всё никак не отпускает?

а фиг его знает – может из-за особенностей javascript – плохо он ворочается с бинарными данными, .
когда последний раз заглядывали в javascript? там с некоторых пор в этом смысле большие перемены, да нормальных чисел типа 64bit long, как во всех языках там попрежнему нет, но постепенно появляются сурогаты типа BigInt которые пока получили очень ограниченное распространение, и поэтому в AdHoc пока не используются
 

pvvx

Активный участник сообщества
это правильно и максимально приветствуется
Но не указана сфера применения... Нет сравнений с другими.
это отнюдь не норка это целая ниша!
Она мала и закрытая из-за многих мелких частностей и специфики.
И это просто оптимизация для получения меньшей стоимости оборудования в мелкосерийке, а не какой-то новый метод.
совершенно не понимаю откуда эти измышлизмы про современные 64 битовые процесссоры и 8 битный AdHoc???
и что от этого парям бида-бида? шо? гондурас/modbus всё никак не отпускает?
Бида такая - пользуем что есть. Как-то нету у нас компов (да и любого другого оборудования) с 8-ми битными процами. 8-мь бит остались в бескорпусных чипах детских игрушек с ОTP или типа матричной прошивкой.

И где вы видели что-то отличное от modbus в пром.автоматике? Название другое и расстановка бит/байт?
Задаваемая адресация (свой индекс) для оптимизации блока ответа на запросы что-то сильно меняет? На большее там не пошли.
Когда будет что-то другое, тогда тут-же и напишем новое. Делов-то - совт оно мягкое...
когда последний раз заглядывали в javascript? там с некоторых пор в этом смысле большие перемены, да нормальных чисел типа 64bit long, как во всех языках там попрежнему нет, но постепенно появляются сурогаты типа BigInt которые пока получили очень ограниченное распространение, и поэтому в AdHoc пока не используются
Это вы сами себя опровергаете ссылками?
Кроме того, хотя встроенные BigInts намного быстрее, чем эквиваленты пользовательских библиотек, BigInts всегда будут намного медленнее, чем 32-разрядные целые числа в JavaScript, в силу характера их переменного размера.
Уже понял - AdHoc это виртуальный измышлизм, оторванный от реальности... Игра в программирование ради программирования по русски.

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

cheblin

Member
с числами в javascript - реальный трах.
это реальность, которая дана в ощущении и совершенно НЕ зависит от уровня твоего кунгфу.
AdHoc всего лишь максимально эффективно использует то, что есть.

тчк.
 

cheblin

Member
ты, кстати, ценитель дешевых гектаров это читал?

не думаешь, что тебя же, подешОвке, в этих же гектарах и закопают
 

pvvx

Активный участник сообщества
не думаешь, что тебя же, подешОвке, в этих же гектарах и закопают
На это в истории уже есть аналоги и учитывая правило "всё по кругу" давно разработаны новые методики...
Закопают при смене строя? Минимальный ответ находится в понятии "раскулачивание" и изучении опыта того века... Ну что такое "кулак"...
--------
А к нашей теме. Назрел конкретный вопрос...
Во многих ОС есть такая ioctl()... И внимание вопрос :) Почему AdHoc или аналоги не используется в этой фигне?
И побочный - почему и как уходят от ioctl? ...
 
Сверху Снизу