[IPC] Ограничения по времени

> <метан>вроде d-bus был на «венду» портирован, хотя - хезе, сам не пользовался </метан>

fixed

[quote] 250Кбайт/с. О чем ты вообще, мужик? Это даже не детская цифра. [/quote]

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

>> [quote] 250Кбайт/с. О чем ты вообще, мужик? Это даже не детская цифра. [/quote]

Если

Если придумывать кошмары, то мне больше нравится такой: несколько устройств начинают бомбить машину прерываниями, и ядро занимается только их обслуживание. Или запустится процесс с realtime-приоритетом выше, чем у сабжевых.

И еще можно придумать десяток причин, по которым даже суперкомьютер не потянет передачу 250Кбайт/с.

память занята например пдп который при арбитраже имеет наивысший приоритет - все остальные будут стоять и ждать

Если через ПДП прокачиваются мегабайты единой транзакцией - да, будут. И что?

>И еще можно придумать десяток причин

И что?

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

> Если тебе этого недостаточно и ты до сих пор уверен что в linux отклик будет меньше 1 мс всегда - то в общем ничего

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

я драйверописатели которые в обработчиках прерываний sleep или cpurelax используют :)

[um]delay же. Да, это ахтунг... но, по крайней мере в -rt есть нити для обработчиков прерываний.

>[um]delay же.

Если уж придираться то и cpu_relax же, но сути это не меняет - как нити в данном случае помогут если прерван например обработчик с меньшим приоритетом ?

>> [um]delay же.

Если уж придираться то и cpu_relax же

Придирка была в том, что, в отличие от sleep, [um]delay - это занятое ожидание.

как нити в данном случае помогут если прерван например обработчик с меньшим приоритетом ?

Если в обработчике прерывания, который обязан иметь наивысший приоритет, используется [um]delay - сливайте воду^W^Wправьте драйвер. Но, если он не обязан иметь наивысший приоритет, то проблема решается настройкой приоритетов.

> Ядро 2.6 + PREEMPT обеспечивает время реакции в пределах 1мс при использовании планировщика реального времени.

А на винде возможно добиться времени реакции меньше 10мс?

>> Ядро 2.6 + PREEMPT обеспечивает время реакции в пределах 1мс при использовании планировщика реального времени.

А на винде возможно добиться времени реакции меньше 10мс?

С вендой не работал. Читал, что Windows CE 5.0 (вроде именно эта версия) - сертифицирована ОС РВ (причем жесткого РВ).

>С вендой не работал. Читал, что Windows CE 5.0 (вроде именно эта версия) - сертифицирована ОС РВ (причем жесткого РВ).

CE - да. Только по своему опыту - на одном и том же железе оно В РАЗЫ просрет линуксу по IPC.

GLib::GIOChannel

А кем сертифицирована? Если каким-нибудь ростестом, то это не говорит ни о чем.

> А кем сертифицирована?

Какими-то американскими буржуями.

>Я уверен в том, что он у меня дает такой отклик (хотя на самом деле отклик обычно меньше на порядок).

Это пока ты с железом не работаешь. Дрова в ядре к сожалению на RT совершенно не заточены и получить отклик даже в 5-10мс очень большая проблема.

>> Я уверен в том, что он у меня дает такой отклик (хотя на самом деле отклик обычно меньше на порядок).

Это пока ты с железом не работаешь

Я с ним работаю.

Дрова в ядре к сожалению на RT совершенно не заточены и получить отклик даже в 5-10мс очень большая проблема.

Походу, у нас с тобой разные ядра.

> без тестов на конкретном железе это все нановоздух :)

В общем, да.

>>А для чего ты их там хочешь использовать?

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

>>Это не говоря о том, что QNX на Эльбрусе вряд ли запустится.

Там работает только древняя солярка, насколько мне известно.

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

Если проблемы с порчей данных нет, то и синхронизации не требуется.

Сообщений много накидали, не осилил. Если тема еще актуальна, то направления два:

1) Разделяемая память - обертку написать легко, можно просто взять boost (включая offset_ptr);

2) Трансфер через FIFO/PIPE;

От первого варианта отказываться стоит только если нельзя рассчитывать что софт отлажен, т.е. есть вероятность «росписи» shared mem. При правильном подходе часто все разруливается без блокировок (rcu, seqlock/repread, circle buffer);

Второй вариант «рожает» массу ньюансов и ВСЕГДА добавляет латентности и её «дивиации». Не углубляясь, например не стоит пересылать порцию данных больше размера страницы. Нельзя забывать про splice() и sendfile(). Но чтобы вы не делали выше «головы» не прыгните.

RT-ядра/патчи спасут вас только если вы полностью поймете как и что там работает (scheduler, tasklets в Linux, DIRQL в mustdie). Просто «тупо» заюзать RT не выйдет и нет смысла, если ваш код где-то взаимодействует не с RT (например работает с файлами).

Юзать RT есть смысл только в масштабе enterprise, включая оплату поддержки RT-надстройки над Linux или Windows. QNX не спасет, любой «чих» и вы вываливаетесь из RT-домена.

ИТОГО: либо отлаживаете обмен через shared memory, либо миритесь с накладными расходами на FIFO/pipe. При этом нет смысла бороться с «мельницами» - любой драйвер (irq, tasklet/DPC или сервис в QNX) все равно отберет у вас процессор. Если кардинально бороться с этим, то IMHO нет большой разницы что писать - приложение режима ядра в Linux, mustdie, или в QNX с соблюдением политик.

Удачи.

P.S. Фьютексы в Linux допускают инверсию приоритетов.

> 4мсек - это 250Гц. 1Кб*250Гц == 250Кбайт/с. О чем ты вообще, мужик? Это даже не детская цифра. Или у тебя встраиваемая железка с 20МГц процессором?

Поддерживаю, обмен через shared-mem на современном железе - это порядка гигабайтов(с большим двойным буфером - десятков гигабайт) в секунду, 250K тебе тут не сильно повлияют. С латентностью imho тоже вы где-то на порядок завышаете ожидаемые проблемы, т.к. системные вызовы обычно весьма хорошо различимы в 10e-5 а не в миллисекундах(10e-3). Так что imho лучше сначала писать, а потом оптимизировать, если работает медленно. Imho у тебя хоть те же локальные сокеты будут работать без всяких проблем.

Спасибо за советы. Всем вообще. Решил остановиться на варианте с shared memory.

>Решил остановиться на варианте с shared memory.

Сладких тебе часов дебага.

>Я с ним работаю.

Ну ладно берёшь пару АЦП + пару сетевух и пытаешься обеспечит отклик в 3мс. Задача собирать данные с обоих АЦП обрабатывать и отсылать по двум сетевухам. Хрен там выйтед даже 5мс. Эсли тебе конечно не критично, что несколько раз в сутки у тебя будут приличные задержки, то всё ОК :)))