Мягкий Real-Time в Windows XP

Мягкий Real-Time в Windows XP

Решил задать этот вопрос и сдесь.

Задача:
Есть 8 канальная PCI карта ввода-вывода L-CARD(модель потом скажу) интерефейс реализован через WDM драйвер.

необходимо раз в 1мс производить чтение с карты. выполнять расчетные процедуры и собственно выдавать результат в виде ряда параметров(обычный виндозный GUI) и в OPC сервер (погуглите че это если кто незнает) причем задержка выдачи резалта некритична.

Критичной секцией является набор подзадач (чтение с карты+расчетные задачи). один цикл влезает в 0.2 мс на Intel Atom 2.2.
Но как организовать гарантированную отдачу приложению управления каждую милисекунду?

и вообще может у когото будут соображения. QNX, RT модули под win2000,WinCE непредлагать)))))) нужна именно WinXP т.к подвязуются OPC сервер и SCADA система.

пока получается такая картина--все ок пока процесс работает в своем кванте времени 40мс допустим. вычитывает считает как надо. но тут ВНЕЗАПНО планировщик на 1-2-3 и т.д. мс отдает упправлени какомуто еще процессу. в это время я теряю несколько циклов считывания что недопустимо как с этим бороться хз. режим "реального времени" мало помогает.

может кто знает как с подобным бороться средствами самой винды.
пока думаю побалываться с многоядерностью Атома. выделить 2е ядро чито под мой процесс.
в общем ХЕЛП!!

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

нефигасебе.....

Neurox сказав(ла):

Критичной секцией является набор подзадач (чтение с карты+расчетные задачи). один цикл влезает в 0.2 мс на Intel Atom 2.2.
Но как организовать гарантированную отдачу приложению управления каждую милисекунду?

Натисніть, щоб розгорнути...

никак, Windows это НЕ RTOS, то что в Windows называют REALTIME, является таковым условно
Насколько я помню в Win при любом раскладе планировщик перенастроить на квант времени менее 1 мс не получится, поэтому гарантированно захватывать проц каждую миллисекунду врядли получится - ядро рано или поздно отдаст очередную миллисекунду кому-то другому. С другой стороны, то что Win НЕ RTOS говорит о том что в любой момент может произойти задержка на несколько секунд к примеру... Поэтому гарантировать в Win ничего нельзя.

Вообще 1 мс - это очень маленькое время реакции, такое лучше реализовывать аппаратно, а не на базе PC платформы. Кстати в обычном режиме под Win поток обычно ожидает 20-100 мс. Глупо при этом ожидать от Win реакцию в 1 мс...

!!!! Глупо при этом ожидать от Win реакцию в 1 мс... !!!!!!
да знаю что глупо но нудно как-тореализовать....
по поводу 2х ядерности- можно ли програмно(ненастраивая вручную) заставить работать все процессы винхп на одном ядре--а второе выделить под отдельно взятый процесс?

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

а как насчет Посилання видалено?

хм. невидел раньше подобного.
небесплатная наверное же...

ну дык. попробуй поискать аналоги. зато realtime можно в винде устроить.

не люблю костыли....
и так в проекте много сущностей уже.)
еще одну заводить....
буду пробовать в общем)

еще как вариант, можно написать драйвер, который будет выпиливать виндовый планировщик и и будет сам планировать.

если брать квант менее 1 мс, львиная доля производительности будет уходить на переключение контекстов...
аппаратно нужно делать

ASokol сказав(ла):

еще как вариант, можно написать драйвер, который будет выпиливать виндовый планировщик и и будет сам планировать.

Натисніть, щоб розгорнути...

та не--это перебор для меня.и навскидку--через драйвер нереализуемо это....

Почему нереализуемо? Благодаря драйверу, ты ворвешься в ядро, а там твори что угодно.

Klez сказав(ла):

если брать квант менее 1 мс, львиная доля производительности будет уходить на переключение контекстов...
аппаратно нужно делать

Натисніть, щоб розгорнути...

аппаратно пусть на заводе на ARMе делают.

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

ASokol сказав(ла):

Почему нереализуемо? Благодаря драйверу, ты ворвешься в ядро, а там твори что угодно.

Натисніть, щоб розгорнути...

надо матчасть курить-токда точно скажу) яж не проффесиональный програмист-системщик.

ASokol сказав(ла):

Почему нереализуемо? Благодаря драйверу, ты ворвешься в ядро, а там твори что угодно.

Натисніть, щоб розгорнути...

точно, на нулевое кольцо вышел и можно свою ось запускать

Neurox сказав(ла):

аппаратно пусть на заводе на ARMе делают.
у мну задача алгоритмы обкатать запатентованные))

Натисніть, щоб розгорнути...

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

имхо из винды менее 10 мс не выжмешь - будет тупо захлебываться...

[OFF]Народ спасибо за диалог) у нас нафоруме тема без ответов(((
я спать.[/OFF]

попробуй Ashampoo Core Tuner для распределения процессов по ядрам.

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

а что за скада если не секрет? в свое время имел дело с генезис32 (вроде так называется, давно это было).

!генезис32!
да есть такая. но мне неподходит.

юзаю КАСКАД-САУ росийской разработки. в бесплатной версии можно 1024 точки использовать и 95% возможностей от платной открыты.

на терминале стоит Soft-контроллер,приложение для архивирования данный, Firebird.
(элементы КАСКАД-САУ)
Очень легко реализовать удаленный АРМ-оператора. данные в скаду буду передавать через UniOPC со своей библиотекой. связь с "расчетным" процессом через PIPE.

!!!а что мешает свой opc сервер написать под qnx?!!

время и знания.
все с нуля надо начинать.

вроде уже определился что данные буду пакетами читать--задержка обработки в 200-300 мс.карта если на автомате стоит--сама читает с нужным интервалом и в буфер выкидывает данные. забираю пакетом и потом на обработку. пропуска тактов уже нет.
просто вначале делал чтение данных с карты вручную. так-просто,но только под ДОСомб удет работать нормально

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

Теперь прога. Винда поддерживает планирование потока только на определённых ядрах. По-моему, функция zwCreateThread в контекст потока принимает 32-битную переменную, где единица в каждом разряде разрешает планирование даного потока на соответствующем процессоре (такое точно есть, не факт, что именно в этой функции).
Главная проблема будет в том, что в созданном таким образом потоке нельзя будет использовать WinAPI. Т.е. 99% функций будет недоступно. Чтобы до них добраться - придётся вручную информировать csrss об этом потоке. А формат этого процесса информирования разный в каждой ОС начиная с NT и не документирован.

Выход из ситуации. Предполагаю, что есть возможность изменить атрибуты планирования для существующего потока. Причём, возможно, не так брутально (имеется в виду недокументированные функции нижнего уровня API, которые начинаются на zw). Но в этом направлении надо погуглить.

Вобщем, допустим, такой поток создан. Теперь процессу с этим потоком ставится реал-тайм приоритет. Занимай его на полностью и крути в цикле nop'ы и считай время. Когда пройдёт нужное время (1мс) - выполняй что нужно.
Тут 1мс, думаю, с вероятностью 99,99% будешь отсчитывать правильно. Реал-тайм приоритета больше ни у кого не будет, поэтому вытеснить твой поток с ядра никто не сможет. Следовательно, весьма умный виндовый планировщик не будет переключать контекст.
(Методом тыка установлено, что при незагруженном процессоре поток с функцией Sleep(0) в бесконечном цикле получает управление больше 40000 раз в секунду (Core 2Duo 1.67 MHz), следовательно, контекст потока как минимум переключается не каждый раз)

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

Neurox сказав(ла):

заставить работать все процессы винхп на одном ядре--а второе выделить под отдельно взятый процесс?

Натисніть, щоб розгорнути...

Легко (см для примера Affinity в Таск манагере). Но это в общем случае тебя не спасет.[/QUOTE]

Klez сказав(ла):

если брать квант менее 1 мс, львиная доля производительности будет уходить на переключение контекстов...
аппаратно нужно делать

Натисніть, щоб розгорнути...

+1. Приходи, спаяем так, шо даже винда не понадобится

Neurox сказав(ла):

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

Натисніть, щоб розгорнути...

О!!!! Ты собсно скажи, сколько колес планируется в твоем велосипеде
Хочу заметить, что ты мелко плаваешь с 1мс - в свое время я участвовал в разработке релейной защиты и автоматики с тактированием 500мкс. И железо было не чета нынешнему - 133-й пенек с 8-мибитной шиной. Зато 10 лет на отказ нарабатывал
Кстати изначально под нашу систему городили ТрейсМоуд - и догородились, что плюнули и написали свое, с участием меня, нынешнего главного в "Мурано" и еще 3-х человек. На момент моего ухода система стояла в практической эксплуатации на Запорожской атомной и на 3-х подстанциях в Одесской области.
Замечу, что мы не использовали никакие специализированные платы с ДСП на борту по причине запредельного по тем временам ценника в 2К зелени. И о многоядерности мы тоже ничего не слышали Железка реализовывала путем исключительно алгоритмизации полтора десятка защит от простейшей земли до диффазной с расчетом расстояния до места аварии. Полноценно рулила ВВ. Писала развитие аварии, отдавала записанное через КОМ-порт и вообще делала много чего интересного и полезного за эти 500 микросекунд
Вобщем если интересно - расскажу подробнее, стучись.