roboforum.ru

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

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

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

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

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

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

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

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

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

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

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