Разработка RoboBrain: - спецификация шины BrainBus

Виктор Казаринов

Попробую начать разработку шины BrainBus. Ее предназначение - высокоскоростное соединение модулей RoboBrain, расчитанное на параллельные массовые асинхронные вычисления.

Уровни:
1.Физический уровень
Физический уровень описывает среду передачи данных (будь то коаксиальный кабель, витая пара, оптоволокно или радиоканал), физические характеристики такой среды и принцип передачи данных (разделение каналов, модуляцию, амплитуду сигналов, частоту сигналов, способ синхронизации передачи, время ожидания ответа и максимальное расстояние).
2.Канальный уровень
Канальный уровень описывает, каким образом передаются пакеты данных через физический уровень, включая кодирование (то есть специальные последовательности бит, определяющих начало и конец пакета данных). Ethernet, например, в полях заголовка пакета содержит указание того, какой машине или машинам в сети предназначен этот пакет.
3.Сетевой уровень
Сетевой уровень изначально разработан для передачи данных из одной (под)сети в другую.
4. Транспортный уровень
Протоколы транспортного уровня могут решать проблему негарантированной доставки сообщений («дошло ли сообщение до адресата?»), а также гарантировать правильную последовательность прихода данных.
5. Прикладной уровень
На прикладном уровне работает большинство сетевых приложений.
Эти программы имеют свои собственные протоколы обмена информацией.

Это - описание TCP/IP протокола. Но шина BrainBus может быть основана и на ином протоколе.
Первый вопрос - какое соединеие на физ. уровне - двухточечное или многоточечное выбрать. Наиболее скоростное - двухточечное. Но и более затратное по оборудованию. Скорее всего придется комбинировать - внутри одного модуля - многоточечное, между модулями - двухточечное.

Michael_K

Чтобы ответить на эти вопросы, нужно представлять структуру сети, архитектуру взаимодействий...
Есть ли в сети "главный", происходит ли передача данных "по запросу",
должны ли одни и те данные быть доступными нескольким клиентам (узлам, модулям).

У меня вообще складывается достаточно жесткое ощущение,
что у вас нет постановки задачи, тем не менее вы упорно
в нескольких ветках "выбираете инструменты" для решения...
Поймите, выбор инструментов зависит от задачи прежде всего!

Angel71

ИМХО начинать нужно с пункта "n" и по нисходящей выбирать решение для всех пунктов в каждом конкретном случае ("межпроцессорные" соединения это одно, "межмодульные" совершенно другие,... как по скорости/топологии/необходимости гарантированной доставки "пакетов"/... так и по многим другим нюансам). если быть еще точнее, то начинать с понимания архитектуры в целом. :pardon:

Виктор Казаринов

2Michael_K: Этот вопрос наиважнейший. Буду рассматривать этот вопрос в отдельной теме.

setar

вот такие слова "параллельные массовые асинхронные вычисления" затрагивают в моем мозгу профессиональные струны.
и реагируют абсолютно точно такими технологиями как RDMA и MPI.
первое - протокол обмена информацией по сути копирующий диапазон памяти одного вычислителя напрямую в память другого, это наиболее современная и быстрая технология интерконнекта на транспортном уровне
второе - прикладной уровень, это практически язык программирования позволяющий строить программы изначально параллельной обработки.

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

если говорить о канальном уровне, то в кластерах вычислительных используется Infiniband это 20-40 Gbps пропускной способности при задержках в канале (латентности) порядка 5-8 микросекунд (обращаю внимание не десятки милисек как в Ethernet)

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

Виктор Казаринов

setar писал(а):

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

Я вас частично понимаю. Частично потому, что сам с параллельными машинами не работал и тем более не проектировал. Но тут несколько другое, чем расчет погоды на планете или ядерный взрыв обсчитать. Тут математики минимум, т.к. задачи другие. Нужны распараллеленные логические выводы. И это не все. Мне не нужны векторные вычисления.

setar писал(а):

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

Я опять о том же - ничего вычислять не придется в традиционном параллельном смысле. У меня по параллельным машинам и процессам есть несколько стареньких книг.

setar писал(а):

если говорить о канальном уровне, то в кластерах вычислительных используется Infiniband это 20-40 Gbps пропускной способности при задержках в канале (латентности) порядка 5-8 микросекунд (обращаю внимание не десятки милисек как в Ethernet)

Тут дело не в скорости, а в динамической структуре сети демонов. Сеть будет перестраиваться на прикладном или около того уровне, образуя социумы демонов. Я немного не в параллельной терминологии пишу. Таковы издержки стыка технологий.

setar писал(а):

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

Рассмотрим объекты ООП в PC. Пока один метод не выполнится, поток не перейдет к работе с др. методом какого-то объекта. Междупоточное взаимодействие также не очень быстро на уровне ядра ОС. Создание треда также небыстрая операция. Поэтому очень трудно будет соотнести производительности заранее.

setar

Виктор, я частично понял, но не уверен что до конца.
Сложность скорее всего в интерпретации терминологии, было бы хорошо на wiki завести страницу с описанием терминов.
например я не понял что значит потоки и соответственно "Междупоточное взаимодействие"

Виктор Казаринов

Потоки - обычные треды http://wasm.ru/article.php?article=1021008
Хорошо, что я пока не говорю о фиберах и пайпах.

setar

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

не понятно как понимать термин - как приведение к уже известным и отработанным вещам или это нужно понимать как описание новых процессов

=DeaD=

2Виктор: По-моему вы ищете решение не объявленной задачи. Сначала должна быть задача, которая очевидно не решается существующими протоколами и интерфейсами, а потом те места, которые не решаются и надо дорабатывать.

Виктор Казаринов

Сейчас я лишь заявил о наличии задачи. Решать конкретно буду позже, сразу при столкновении с необходимостью ее реализации. А пока можно сюда подсобрать аналитические материалы. Не знаю, м.б. реализация потребуется будет нескоро, а м.б. и скоро.

=DeaD=

Какие материалы добавлять то, если нет требований к интерфейсу? Собирать всё из инета по всем интерфейсам в одну кучу?

roboforum.ru

Разработка RoboBrain: - спецификация шины BrainBus

Кто сейчас на конференции