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

[cheblin]

Вы видели лучше?

естественно, более лучший - это с 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 – это игра для деоптимизации, созданная виртуальным программером ради забавы. Скорее всего, это было создано по совету от “креативных клоунов”...

 

[pvvx]

@cheblin - наша реальность ->
Индексация и описание типов GATT Characteristics | Bluetooth Technology Website для передаваемого потока...
И описывается в *.xml

 

[cheblin]

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

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

 

[pvvx]

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

Это такие мысли вслух

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

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

 

[cheblin]

Это такие мысли вслух

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

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

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

 

[pvvx]

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

 

[pvvx]

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

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

 

[cheblin]

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

это правильно и максимально приветствуется

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

это отнюдь не норка это целая ниша!

совершенно не понимаю откуда эти измышлизмы про современные 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]

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

тчк.

 

[cheblin]

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

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

 

[pvvx]

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

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