Ну т.е. такие RTOS в доках на которые чёрным по белому написано, что регламентируется время реакции на событие как и у обычных RTOS (у которых регламентируется время реакции только на "местные" событие), но независимо от того, что событие произошло на одном девайсе сети, а его поток обработчик находится на другом девайсе сети.

А?

Наверное там должно иметь место понятие "приоритет пакета" и "вытеснение пакета". Т.е. когда пакет с бОльшим приоритетом может вытеснить с магистрали пакет с меньшим приоритетом, аналогично тому как поток с бОльшим приоритетом вытесняет поток с меньшим приоритетом.
Я прав?

Если это так, то как это реализуется?

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

Дон:

С точки зрения ОС возможны два варианта сетевого взаимодействия между N узлами: разделяемая
память и распределенная память. В первом случае используется SMP (Symmetric MultiProcessing), во
втором какое-либо подмножество ISO OSI (Open System Interconnection), например (ну кто бы
сомневался!) TCP/IP, и QoS (Quality of Service). Вот ключевые слова для поиска. Может быть, еще
есть что-нибудь полезное в документах по Tiny OS.

Разумеется, что SMP вовсе не обязательно использовать для упрвления в системе с shared mem --
можно (что и делается) использовать вторую модель.

Кроме google, в котором обычно (но не всегда!) полезные ссылки находятся за пределами 3*сигма,
можно искать в citeseer и конечно читать rfc.

http://en.wikipedia.org/wiki/Quality_of_service

Что касается <<черным по белому написано>>, вероятно, к этому ближе всего QoS. Хотя надо всегда
четко отдавать себе отчет в том, что для узла имеют смысл (и обрабатываются, в том числе) только
локальные события.

--
AN

Разделяемая память не годится, потому что у меня не кластер, а сеть с не полносвязной топологией с последовательной передачей инфы по достаточно протяжённым (десятки метров) каналов с достаточно низкой скоростью ( 4800 Бод)

Не мой случай.. Аднозначно



Да в курсе я про эти протоколы. Понятие реалтайма можно как-то связать только с QoS. И то там не слова про механизм вытеснения высокоприоритетными пакетами низкоприоритетных и про динамическую модификацию приоритетов и политику диспетчеризации пакетов (по аналогии с диспетчеризацией потоков)


Не.. ТиниОС однозначно не из той оперы.


Это ещё почему же? Полно задач, когда Event-ы регистрирует один узел, а обрабатываются они на совсем другом узле.

Яж указывал.
Самый популярный распределенный движок - это embedded CORBA
Там есть все: и асинхронные и синхроныые обмены, и приоритеты и маршрутизация и полная независимость от места выполения.
Хоть на этом же проце хоть за тысячу километров синтаксис процедуры вызова не меняется.
Я даже занимался CORBA как раз для медленных каналов по UART-у на базе uCOS.

Время реакции на события не регламентируют ни в каких RTOS. Единственно что гарантируют для некоторых сервисов RTOS это предсказуемость времени.
Это просто означает, что его можно замерить и поверить этим замерам.

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

Даже ZigBee полностью основан на принципе распределенного управления.
Там это описывается в терминах профилей и кластеров
Есть функция включить лампочку.
И без разницы к чему лампочка подключена к этому же процу или за 1000 метров через 10-то хопов к другому дивайсу она включится.

Но в радиосетях типа ZigBee концепция приоритетов и проч. вытеснения уже не годится.
Ушедший пакет может довольно долго гулять по сети пробивая себе маршрут и генерируя волны флуда.
Его жизнь становится не управляемой и остается надеятся только на статистические закономерности.
Также и в проводных сетях с большой вероятностью потерь или конфликтов.

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

В частности, при передаче сообщения от задачи к задаче через сеть приоритет задачи используется при выборе порядка передачи пакетов в сети (если образовалась очередь на передачу, сообщение от более приоритетной задачи пересылается первым).

Однако есть сеть - это Ethernet, то следует отметить, что Ethernet сетью реального времени как известно не является (ввиду того, что использует метод управления доступом CSMA/CD). Поэтому узел, желающий передать пакет, может пытаться сделать это теоретически сколь угодно долго (ожидая освобождения среды).
И само собой, пакет, который уже передается (хоть этим, хоть другим узлом), вытесен быть уже не может.

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

ИМХО, реалтаймовость никак не зависит от аппаратуры и топологии..

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

В вопросе ТопикСтартера, очевидно, потуг одной сколь угодно реалтаймовой ОС недостаточно для достижения сетевой распределенной реалтаймовости. Просто не надо этого забывать и не стоит слишком доверять модному клише "RTOS" - типа если взять RTOS, то реалтаймовость получается сама собой.

Так давайте разберёмся! Во первых есть такая фишка, как вытеснение одного потока с меньшим приоритетом потоком с более высоким приоритетом. Вот блогадоря такой фишке можно как то сказать вот ребята я в своей ОС ГАРАНТИРУЮ что это вытиснение не будет НИ ПРИ КАКИХ ОБСТОЯТЕЛЬСТВАХ например не медленее чем за 20 мкс. И вот если ваша ещё высокоприоритетная задача будет обслуживать пришедшее событие (которое и послужило причиной вытеснения) в течении 40 мкс, то вот вам ребята и гарантия в 40+20=60 мкс.

Так вот теперь о сети. Тут два вопроса
1. Вытеснение обслуживания менее приоритетного пакета в сетевых функциях ОС над другим более приоритетным
2. Вытеснение пакета в самой сети.

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

Во вторых Из всего что известно мне вытеснение пакета одини другим есть только в сети CAN там адрес узла и есть приоритет больше адрес больше приоритет. Если передачу начинают два узла то менее приоритетный прекрашает передачу и без колизий ситуация разрешаеться.

Эт сильно упрощенный взгляд на вещи.

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

Обычно так: есть задача обработки входных сигналов, потом есть задача менеджер-демультиплексор входных данных в задачи приемники, потом собственно есть задачи с "бизнес логикой", те в свою очередь продукты своей жизнедеятельности могут отправлять обратно в некие сетевые стеки через цепочку задач или взаимодействовать с файловыми системами (которые тоже обслуживаются отдельными задачами) или системами HMI (humam-mashine interface).
При такой комплексности говорить об измерении и гарантировании каких-то микросекунд на реакцию на воздействие бессмысленно.
Решающую роль имеет только искусство профайлинга.
Только в RTOS этот профайлинг можно сделать за конечное время, а в неRTOS этим можно заниматься бесконечно. Профайлинг делают опытные спецы высшего пилотажа используя моделирование, для ламеров, конечно, RTOS не повод быть увереным что все получится realtime за отведенное на проект время.

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

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

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

Остается только тема тюнинга логических каналов.
И вот тут-то и приходят решения типа CORBA где этот тюнинг уже выполнен.

Кстати в физ.линии CAN осуществляется не вытеснение пакетов, а только арбитраж пакетов одновременно готовых к передаче. Т.е. в СAN наличествуют те же коллизии что и в Ethernet.
Пакет не самого высокого приоритета непробившийся на передачу вынужден ждать неопределенно долго своей очереди.
А проблема планирования приоритетов в CAN для обеспечения жесткой константы времени реакции в многоузловых сетях практически никакими протоколами прикладного уровня не решена.

На данном конкретном железе.
При идеальных условиях (отсутствие других событий).
И то, не всегда можно найти гарантированную верхнюю оценку.

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

Скажем так, в идеальных условиях без привязки к железу и внешним событиям оценку можно найти. Теоретически. На практике это иногда невозможно из-за очень большой трудоемкости (грубо говоря, много кода).
Если принимать во внимание упомянутые факторы, то, в общем случае, оценку найти нельзя.
На проектирования устройства влияют многие моменты, как то: железо, предметная область, ОС и т.д. И мифические 60мкс - это оценка на уровне устройства. А на уровне так называемых RTOS эти оценки не имеют смысла.
Фактически, RTOS - это OS, которая вносит минимум неопределенности в разработку девайса или системы (по сравнению с другими OS). А вопросы, заданные топикстартером, решаются на более высоком уровне.
Все имхо, конечно.

Конечно не принято. Имелось в виду та часть что отвественна за какие нибудь протоколы, стеки и т. п.

Что ж конечно не всё так просто в этом мире. Теория теория а практика всегда портит идеальную картину.



Ну у кого какие каналы, и у кого какие гига или мегагерцы.


Так то оно так, только заметте, вытеснение пакетов примерно так же как и вытеснение задач. Задача не самого высокго приоритета вынуждена ждать неопределённо долго.