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

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

Вендовые пайпы имеют режим передачи сообщений (т.е. клиент читает ровно одну запись, а не сколько-там-байт-непрочитано). Аналогичное в линуксе - это сокеты AF_LOCAL с SOCK_SEQPACKET.

сокеты. hard realtime не будет ни там, ни там, но кроссплатформенности добьешся

Особенно вендовые, которые AF_LOCAL не поддерживают. Действительно, пусть его прогоняет через весь TCP/IP стек, нам ведь не жалко? Под виндой лучше пайпы.

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

>>и много ты выиграешь, ifdef-ами обложась? а петля в любом случае практически одинаково работать будет

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

Да уж, «практически». У человека есть требования ко времени, если ты не заметил. И надо достичь максимума. В винде пайпы - родное и самое эффективное средство.

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

Может оттуда и скомуниздь?

>>В винде пайпы - родное и самое эффективное средство.

Я в винде с пайпами не работал, но беглый обзор показывает, что оно сделано на основе smb. Это нормально?

>>Может оттуда и скомуниздь?

Ну, все должно быть на С. Куте туда не впихнуть никак. Только если переработать этот класс на функции.

>Я в винде с пайпами не работал, но беглый обзор показывает, что оно сделано на основе smb.

Сфига б это? Или ты судишь по именованию? Так это ничего не значит, это просто такое пространство имен.

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

нужно решение с минимальными издержками, причем кроссплатформенное (винда + линакс)

Разделяемая память?

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

издержки зависят от сколько и какими порциями

>требования по времени в неrealtime ос - хуйня собачья, и могут вычисляться очень приблизительно.

Да, но это не повод выбирать заведомо более медленный способ.

>>Разделяемая память?

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

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

>>издержки зависят от сколько и какими порциями

Поток будет довольно плотный, порции (сообщения) будут редко больше 1Кб.

> Поток будет довольно плотный, порции (сообщения) будут редко больше 1Кб.

Цифры озвучь.

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

Сначала написать как удобно, потом запустить и воскликнуть «ой, *ля!» и начать переписывать как быстро. И да, у человека есть QLocalSocket как наглядный пример прозрачной работы с обоими интерфейсами, так что проблем с написанием не будет.

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

Затраты на синхронизацию потоков будут при любом механизме IPC. ИМХО в случае разделяемой памяти затраты как раз таки получаются минимальными.

если использовать какие-то готовые обвязки - да, пофиг. но в начальных условиях их озвучено не было

>>Цифры озвучь.

Максимальное время между сообщениями - 10 мсек, но, скорее всего, оно будет меньше (но не чаще, чем 4 мсек). В среднем сообщение весит 1 Кб. Как-то так. За эти 4-10 мсек нужно успеть принять сообщение и обработать его, т.е. быть готовым к обработке следующего.

>Затраты на синхронизацию потоков будут при любом механизме IPC.

Да.

ИМХО в случае разделяемой памяти затраты как раз таки получаются минимальными.

В свое время гонял на WinCE их message queues (аналог вендовых пайпов) и ручной вариант с SHM+семафоры. Получил практически равные скорости.

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

Это очень сложно осуществимо, потому что исходный поток идет не от нас и условия нам диктовать очень сложно. Придется подстраиваться.

В свое время гонял на WinCE их message queues (аналог вендовых пайпов) и ручной вариант с SHM+семафоры. Получил практически равные скорости.

Логично. Ведь по идее, где-то в недрах любого IPC - от fifo||pipe до tcp/ip на localhost - будет участок памяти, доступный и отправителю сообщения и получателю, плюс семафор, чтобы отправитель не подрался с получателем =).

Ну да:)

шлюз, как вариант. со своим кэшем, что добавляет +100 к надежности.

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

Кстати говоря, jack и pulseaudio для IPC (для передачи «звука» между процессами) используют именно разделяемую память.

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

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

тут же, как я понял, поток данных внешний

Хм... Вроде наоборот - автору темы данные нужно гонять между локальными процессами. Иначе бы он на fifo и пайпы не смотрел.

> шареная память хороша для локальных процессов. тут же, как я понял, поток данных внешний

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

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

Вполне возможно, что все это будет крутиться на доблестных Эльбрусах (там порядка 500 МГц). Но вся проблема в том, что после получения данных идет достаточно затратная по ресурсам математическая обработка, тем более процессов будет порядка 5-6 и обработанные данные еще и между ними будут гоняться. Поэтому и нужно снизить издержки при обмене данными.

>>шареная память хороша для локальных процессов. тут же, как я понял, поток данных внешний

Обмен данными локальный.

> Вполне возможно, что все это будет крутиться на доблестных Эльбрусах

Под вендой, да.

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

250Кбайт/сек - это просто не та цифра, которая создает хоть какие-нибудь проблемы.

>>Под вендой, да.

Как один из вариантов - да. Там вообще зоопарк: линакс, древняя солярка (для эльбрусов) и венда. Должна быть возможность пускать на любом из трех вариантов.

250Кбайт/сек - это просто не та цифра, которая создает хоть какие-нибудь проблемы.

То есть, в принципе, пофиг на чем написать IPC и издержки при любом способе будут примерно одинаковы?

если на внешние приблуды ничего особенного не надо выдавать, заплюсую шареную память

>За эти 4-10 мсек нужно успеть принять сообщение и обработать его, т.е. быть готовым к обработке следующего.

Если нужно ГАРАНТИРОВАНО успеть обработать за это время, то ИМХО без ОС реального времени никак не обойтись. Если нужно, чтоб в средне-интегральное укладывалось, то лучше через сокеты/пайпы, так-как решение с shared memory помимо хорошей производительности может дать ещё хорошую головную боль из-за плохой изоляции.

Сколько надо будет места под данные - неизвестно. Поэтому могут быть издержки на переаллокацию.

Надо думать, что пайп у тебя бесконечной длины... Сделай кольцевой буфер.

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

Нафиг они не нужны.

> То есть, в принципе, пофиг на чем написать IPC и издержки при любом способе будут примерно одинаковы?

На таких объемах - да.

>>Если нужно ГАРАНТИРОВАНО успеть обработать за это время, то ИМХО без ОС реального времени никак не обойтись.

Пытаемся выбить под это дело QNX, то у военных с такими вещами трудно, хотя 4.23 вроде как сертифицирована.

>>Нафиг они не нужны.

Почему?

>>Нафиг они не нужны.

Почему?

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

>>Если нужно ГАРАНТИРОВАНО успеть обработать за это время, то ИМХО без ОС реального времени никак не обойтись.

Пытаемся выбить под это дело QNX

Бгг. Если вы на Линуксе не выжмете времена порядка нескольких миллисекунд, QNX вам бесполезен %) Это не говоря о том, что QNX на Эльбрусе вряд ли запустится.

>Если вы на Линуксе не выжмете времена порядка нескольких миллисекунд, QNX вам бесполезен %)

А можно подробнее.

>> Если вы на Линуксе не выжмете времена порядка нескольких миллисекунд, QNX вам бесполезен %)

А можно подробнее.

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

Это не говоря о том, что можно использовать -rt.

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

Тут ты прав - _ядро_, а в остальном - реализация драйверов может покалечить все достижения ядра, без тестов на конкретном железе это все нановоздух :)

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