Точный тайминг

[Thinker]

Задача: из проги надо посылать данные по сериальному порту каждые 20 мс.
Написал драйвер который использует таймер и из ДПС посылает данные в собственно последовательный порт (через его драйвер).
В осциллографе видно что пульс идет каждые 30 мс, не чаще.
Какие нибудь идеи что может дать большую точность ?
Данных 50 байт, скорость передачи 38 кбит.

[????]

А что используешь в качестве таймера?

З.Ы. если прога будет привязана к процессору (к частоте), то можно через rdtsc задержку делать.

[grozny]

способы обсуждались неоднократно, в архиве посмотри. Таймер должен быть никак не в драйвере - зачем он там? Про Win32 таймеры луче забыть, они непригодны для точного времени.

man QueryPerformanceFrequency, QueryPerformanceCounter.

И вызывай IOCTL своего драйвера, либо событие сигналь по прошествии нужного интервала. Вообще-то послед. порт обсуждался с особым пристрастием

[SlavaI]

Какие нибудь идеи что может дать большую точность ?

Что за таймер? Если тот что от системных часов работает(KeSetTimerEx/KeSetTimer)- то у него  разрешающая способность 10 мс на однопроцессорной машине и 15 мс на двухроцессорной, плюс мешающиеся DPC от других драйверов. Похоже ты попал на 15 мс таймет и твои 20 мс были округлены до 30 на два тика таймера. Вот такая у меня мысль возникает. Даже если у тебя 10 мс таймер- учти задержку, между постановкой DPC в очередь процессора и началом ее выполнения. Увеличить реактивность можно увеличив приоритет DPC (KeSetImportanceDpc), заставив систему вставлять твой DPC в начало очереди а не в конец.
 
Вся проблема в том, что разброс всегда будет и обычно в сторону увеличения. Ни Windows ни Linux( стандартном варианте) не являются системами реального времени.
Вот некоторые варианты-
1) Увеличение мощности машины- процессор помощнее, лучше два.
2) Остановка ненужных приложение и сервисов, выгрузка других драйверов.
 То есть увеличение мощности машины с кардинальной чисткой работающих приложений и драйверов.

[SlavaI]

Еще дополнение- 50байт/38кбит в секунду == 10 мс. В итоге 20 мс+10мс=30мс. Как ты реализуешь передачу в порт(синхронно или асинхронно)? Как смотришь результат? Не наблюдаешь ли ты вот эти 30 мс плюс всякие другие задержки. Попробуй передавать один байт и посмотреть на период.

[grozny]

да ну что вы прям - 50 байт на скорости 38 кбит/с передать...  

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

Абсолютно никаких теоретических оправданий невозможно придумать: задумайтесь вот о чём: поток данных на современных ГП есть 2-2.5 Гб/с, время кадра при частоте 120 Гц - 5 мс. И ничё, всё работает - как вы можете видеть на экранах ваших мониторов .  Теперь вспомните о гигабитных сетевых карточках... звуковых, наконец (48 кГц/24 бита). Да и говоря о кондовом последовательном порту - нуль-модем легко работает на скоростях 115200 бод. Хоть стандартный, хоть в том же софтайсе или виндбаге. Мышки, наконец - работают, опрашивают и ничего.

Ясно, что проблема - в реализации. Так что детали реализации - в студию. А то пока непонятно.

[Thinker]

Ну, слушайте, умные люди.
Все написано на DriverWorks. Создается  девайс, который в свою очередь создает LowerDevice - послед. порт.
Все операции DeviceIOControl перенаправляются на порт, и прога через мой девайс конфигурирует порт. (Можно было использовать FilterDevice, но по разным не относящимся к делу причинам это неудобно).
По команде из проги выставляется периодический таймер (KTimedCallback), использующий ДПС. С помощью
 KeSetImportanceDpc (спасибо, Слава) ставится высший уровень приоритета. Из обработчика ДПС асинхронно в LowerDevice посылается один и тот-же буфер (конкретно - "hello"   ).
Никакого взаимодействия с прогой в процессе посылки нет.
Результаты:
Резолюция таймера (Win2000, workstation, 1 процессор), по видимому 15 мс.
При периоде < 15 получаю 15, при периоде от 15 до 30 -> 30 и т.д.
Ко времени срабатывания таймера добавляется задержка (ДПС и проч.) около 2-3 мс. Использование KeSetImportanceDpc ни на что не повлияло (система абсолютно не загружена). Точность (отклонение от 15 мс) весьма приличная и не зависит от того что (в user mode) происходит на машине.
Вопрос: Кто виноват и что делать ? (Windows CE/VxWorks/RTX и т.д.) не предлагать. По моему мнению использование system thread и ожидание на таком-же таймере ничего не изменит (может уменьшить "шум" на 1-2 мс). Использование 2 процессора в busy wait не подходит.
Рассматривается вариант использования RTC (hardware clock card) который и будет давать прерывание, из обработчика оного и посылать данные. Из предыдущего опыта: задержка ISR порядка сотен микросекунд, плюс задержка driver-stack собственно посл. порта - даст всего 1-2 мс "шума".
Что думаете ?
П.З.
Товарищу Грозному   :

да ну что вы прям - 50 байт на скорости 38 кбит/с передать...

Проблема не в количестве данных, а в точности (по времени).
Байты естесственно посылаются, но не тогда когда надо.
А надо каждые 20 мс, с проверкой по осциллографу.
Если точка ползает около риски, еще туда-сюда, но если она стоит около не той риски, то плохо.

Теперь вспомните о гигабитных сетевых карточках... звуковых, наконец (48 кГц/24 бита).

Сетевые карточки и т.д. реагируют на внешние прерывания и сервисы ОС (тайминг) при этом не чаще всего не используют.

man QueryPerformanceFrequency, QueryPerformanceCounter.

Причем здесь QueryPerformanceFrequency, QueryPerformanceCounter я не понял - только если busy wait делать на отдельном CPU.
Все эти много-мегабайтовые данные перекачиваются через DMA, и чаще всего карточка - мастер, так что с точки зрения писюка - все происходит по щучьему велению. Мое последние достижение - 15 Мб/сек (байт, не бит), правда motherboard + memory дымились.

[grozny]

Все написано на DriverWorks. Создается  девайс, который в свою очередь создает LowerDevice - послед. порт.
Все операции DeviceIOControl перенаправляются на порт, и прога через мой девайс конфигурирует порт. (Можно было использовать FilterDevice, но по разным не относящимся к делу причинам это неудобно).
По команде из проги выставляется периодический таймер (KTimedCallback), использующий ДПС.

дааа  . На мой взгляд, неудачный выбор инструментов (не в смысле ДрайверВоркс, а в смысле сочетания ДПС/колбэк). Тебе нужна временная точность посылки и ты тем не менее выбрал самый неточный (по определению - *Deferred* Proc. Call) механизм. Да ещё таймерный коллбэк.

Причем здесь QueryPerformanceFrequency, QueryPerformanceCounter я не понял

Я б сделал так: тупой драйвер, как можно тупее - и наружу торчит какой-нить IOCTL (IOCTL_WRITE, например) чтоб максимально быстро  складывал данные в порт.

Всё, что только можно, надо делать на 3-м кольце. Рабочий трэд в 3-м кольце, в жёстком цикле (видимо, busy wait в вашей терминологии) крутит часы (сделанные на QueryPerformanceCounter/Sleep) и в час Х дёргает этот IOCTL.

По своему опыту могу сказать, что латентность ниже сотни мкс недостижима под виндами. Такая латентность наблюдается на обработке железных прерываний. Если точности в 1 мс (стандартный квант Sleep)  недостаточно, то да, надо вешать обработчик на RTC и из него сигналить событием (самый быстрый способ коммуникации) в драйвер, например. Аппликуха должна набивать буфера. Ну тут возможны варианты.

Да, нынешнее (и даж предыдущее) поколение видеокарточек основной поток данных получает по ДМА. Тем не менее, два поколения назад это было не так. И поток тогда был в десятки Мб/с. Да и вспомогательный поток через ЦПУ (конфигурация и пр.) никак не меньше десяток кбайт/с. Насчёт точности: видео при проигрывании под виндовс не дёргается (как правило, если с кодеками всё нормально  8) ). Значит, система успевает прочитать с диска/разжать МПЕГ/отдать данные в видеокарту за время кадра, которое никак не больше 12 мс (если у нас 60 Гц рефреш). Тупое переписывание буферов там тоже, несомненно, идёт через ДМА, но многие операции выполняются на ЦПУ. Пропуск кадра достаточно заметен - картинка будет дёргаться.

[maaaaaad]

Всё, что только можно, надо делать на 3-м кольце. Рабочий трэд в 3-м кольце, в жёстком цикле (видимо, busy wait в вашей терминологии) крутит часы (сделанные на QueryPerformanceCounter/Sleep) и в час Х дёргает этот IOCTL

Какой ужас


Опять народ начитанае про rt бузить =((

ставь обработчик на irq0 в idt и следи за rdtsc. Nt вроде перепрограммирует таймер в процессе, но прерывания не приходят реже 1мс. Разброс минимальный. Ниже не удасться сделать сохранив стабильность. Хотя...


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

Вобще, такую примитивную работу стыдно давать своему гиперконвееру. Для этого есть контроллеры, а не ПС.

Использование KeSetImportanceDpc ни на что не повлияло (система абсолютно не загружена

Это абсолютно бесполезно. С какой стороны вас не забрасывали бы камнями вам было бы все равно больно.

[maaaaaad]

Хотя и на тракторе можно иногда неплохо разогнаться



----------------------------------------------------------------------------------------
04 - Matrix soundtrack - Rob D (Narcotic Remix).mp3

[maaaaaad]

Блин, была бы точка входа в DPC менеджер (точка входа пререключении с DIRQL на DPC). я бы сделал нармальный DPC, с приоритетами, с rt....Ублюдки из ms никак не догадаются это сами сделать. Сколько крови еще прольется...

[maaaaaad]

 Значит, система успевает прочитать с диска/разжать МПЕГ/отдать данные в видеокарту за время кадра, которое никак не больше 12 мс (если у нас 60 Гц рефреш).

Хм...тама ващета порядка десятков кадров в секудну в зависимости от кодака, и тебе будет все равно если кадр придет на 10мс раньше или позже...

[SlavaI]

При периоде < 15 получаю 15, при периоде от 15 до 30 -> 30 и т.д.

Похоже в своей реализации ты уперся на квант таймера, либо 15, либо 30 мс, 20 можно, но надо извратится с 15 мс таймером.

По моему мнению использование system thread и ожидание на таком-же таймере ничего не изменит (может уменьшить "шум" на 1-2 мс).

Можно попробовать System Thread c real time priority, но все равно будет выходить задержка в большую сторону, плюс накладка от планировщика потоков(около 5мс), опять выйдет +5мс.

Рассматривается вариант использования RTC (hardware clock card) который и будет давать прерывание, из обработчика оного и посылать данные.

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

[Thinker]

Вот только стандартный KeSetTimer - это тоже ISR+DPC от системных часов, плюс твоя DPC.Надо понять, чем твоя реализация будет отличаться от уже имеющейся и какие даст преимущества.

Если я правильно понимаю, то в системном таймере есть квантизация запросов, т.е. хотя прерывание от железки и может прийти когда угодно (в смысле с любым интервалом), запускают его с шагом 15 мс, и на каждое прерывание обслуживают произвольное количество ОС таймеров. Таким образом ОС поддерживает сотни и тысячи таймеров, хотя фактически прерывание есть только одно. Если обрабатывать структуру данных активных таймер-запросов каждую мс, то времени уйдет гораздо больше (квантизация будет 1 мс). Делать без квантизации совсем - бессмысленно,так как два последовательных запроса по созданию таймера с одинаковой задержкой потребуют двух разных обьектов ОС и двойной обработки.
Итого, если я работаю со своей железкой, то могу попросить прерывание каждые 17.654 мс, и оно сгенерируется. Через пару сотен микросекунд вызовется ISR, и оттуда в принципе уже можно асинхронно писать в посл. порт. В крайнем случае - послать ДПС.
Запрос на запись все-равно пройдет через все dispatch механизм и несколько сотен микросекунд потеряются, но проблемы квантизации не будет.

Всё, что только можно, надо делать на 3-м кольце. Рабочий трэд в 3-м кольце, в жёстком цикле (видимо, busy wait в вашей терминологии) крутит часы (сделанные на QueryPerformanceCounter/Sleep) и в час Х дёргает этот IOCTL

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

ставь обработчик на irq0 в idt и следи за rdtsc. Nt вроде перепрограммирует таймер в процессе, но прерывания не приходят реже 1мс. Разброс минимальный. Ниже не удасться сделать сохранив стабильность. Хотя...

А это не больно ? Идейно мне это близко, но сам irq0 никогда не трогал. Примерчик где-нибудь есть ? Все это должно бежать на разных мать. платах и быть HAL - независимо, включая много-процессорные машины. ISR может ведь срабатывать на разных процессорах, rdtsc у них синхронизированы ?

Если точности в 1 мс (стандартный квант Sleep) недостаточно, то да, надо вешать обработчик на RTC и из него сигналить событием (самый быстрый способ коммуникации) в драйвер, например.

Если сделать Sleep на 1 мс, оно разве всегда вернется ровно через 1 мс ? По моему если из очереди запуска планировщик задач (ну и термины, мама моя - спасибо Славе еще раз) его выбросил, то не раньше чем через 10-15 мс вернет, а ?

Тебе нужна временная точность посылки и ты тем не менее выбрал самый неточный (по определению - *Deferred* Proc. Call) механизм

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

[grozny]

[quote="Thinker]
Ментальность - страшная вещь.  
[/quote]
именно. Зачем нам менты с ментолом?

У нас в 96-м на Р200ММХ в жёстком цикле под 98-ми виндами бежала система отображения. И куча чего ещё делалось на ЦП, помимо обсчёта геометрии для каждого кадра. Например, по сети бродкастились координаты объектов, так что несколько (до 6-ти машин) синхронно показывали одно и то же.
С тех пор так вот и работает, железяки уже давно другие, ОС - другая, но отображалка всё также работает. Так что хоть как можно обозвать - от этого работать не перестанет, проверено временем.

жесткий цикл без Sleep не подходит, а со Sleep по моему будет не лучше

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

Если сделать Sleep на 1 мс, оно разве всегда вернется ровно через 1 мс ? По моему если из очереди запуска планировщик задач (ну и термины, мама моя - спасибо Славе еще раз) его выбросил, то не раньше чем через 10-15 мс вернет, а ?

засыпает он на 1 мс с точностью до ближайшего кванта ОС. Никогда не видел, чтобы Sleep(1) давал задержку больше 1.0ХХХ мс (по перформанс-каунтеру судя и на глаз, по картинке с ви-синком).

Если б ОС с такой лёгкостью разбрасывалась 10-15 мс, то любой примерчик ДиректХ/ОпенЖЛ тормозил бы жутко и никто б никогда и нигде не увидел бы фрэйм-рэйтов больше 30 Гц ни в ОпенЖЛ игрушках, ни в ДиректХ.

Т.е. вполне возможно, что когда из очереди кого-то куда-то выкидывают, то такая задержка и происходит, но сколько ни писал render-loop, ни разу не столкнулся.

ну и термины, мама моя...

Писюк на котором все это бежит, вовсе не мечтал всю свою жизнь...

О чём мечтает писюк, по которому все бегают, я естественно, никакого понятия не имею, вам виднее  :twisted:

[SlavaI]

По моему если из очереди запуска планировщик задач (ну и термины, мама моя - спасибо Славе еще раз) его выбросил, то не раньше чем через 10-15 мс вернет, а ?

Так и есть. Причем на варианте Server, может быть еще больше. Последовательность действий- вынуть из очереди потоков, запланированных на выполнение, вернуть в очередь потоков, готовых на вполнение, запустить планировщик потоков, при этом планировщик еще повыбирает- а может ему не захочется сразу этот поток на процессоре запускать, например найдет более приоритетный, для уменьшения этого негативного явления надо задирать приоритет своему потоку, только надо учесть, что при runtime level приоритете скинуть поток с процессора нельзя, пока он сам этого не захочет, перейдя на ожидание какого-то объекта синхронизации. Можно конечно перед Sleep поднимать приоритет, а после- понижать, это позволит быть выбранным планировщиком сразу.
 Связываться с потоком и планировщиком- это всегда негарантированная задержка. Да и вобще- на Passive Level и APC Level гарантировать какую-то задержку нельзя, из-за вмешательства планировщика потоков.

[Thinker]

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

Связываться с потоком и планировщиком- это всегда негарантированная задержка. Да и вобще- на Passive Level и APC Level гарантировать какую-то задержку нельзя, из-за вмешательства планировщика потоков.

Так кто же прав ? То что другие трэды/потоки смогут работать если мой посылающий поток вызовет Sleep - это я понимаю. А почему Sleep вернется ровно через 1 мс - это нет.

В том-же процессе бежит еще 1 поток GUI, 2 - потока вычисления (т.е. они никогда не вызывают ввод/вывод, а 2 их потому что иногда они ждут доступа к общим структурам.) На 2-процесорной машине будет 3 потока, и т.д, плюс (1 + количество CPU)  потока на каждый процессор делают весь I/O через CompletionPort.
То есть всегда есть куда переключится с потока посылающего данные в посл. порт, и новому потоку чаще всего есть что делать.

Слава, рассуди.

[maaaaaad]

Можно конечно перед Sleep поднимать приоритет, а после- понижать, это позволит быть выбранным планировщиком сразу.

Это кто сказал? Это еще спорно, хотя не лишнее сделать. SetThreadPriorityBoost можно еще попробовать. А так же можно пройтись по вражеским потокам и снизить эту величину до нужных пределов...Но все это еще спорно......впрочем.......как и все тут.....

Интересно чем все это закончится....

[SlavaI]

Это кто сказал?

Я сказал.

[Rinat]

Програмно делать 20 мс - это ненужный гемор.
Если нужен определённый сигнал через x мс, можно использовать например звуковую карту. Это не так трудно сделать.

[SlavaI]

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

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

[Anonymous]

Интересно, а есть специализированые генераторы прерываний?

[grozny]

Интересно, а есть специализированые генераторы прерываний?

"Специализированные" - в смысле железные? Есть конешно. Берёшь кварц и формируешь сигнал железного прерывания в соответствие со стандартом для данной шины. Может потребоваться пара регистров и кой-какая рассыпуха.

Более того, все чипсеты имеют отладочные режимы, в которых они выдают прерывания процессору на заданных уровнях с заданными частотами.

[grozny]

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

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

Практически на всех компах есть видео  :!: . А оно всегда генерит прерывание с частотой обновления экрана.

[Anonymous]

grozny,
И имел ввиду уже готовые, ввиде PCI платы например.

"Более того, все чипсеты имеют отладочные режимы, в которых они выдают прерывания процессору на заданных уровнях с заданными частотами."

А где про это можно почитать?

[grozny]

поступай на работу в компанию, проектирующие чипсеты, пишущую БИОС или делающую мамки . И читай с грифом NDA.  

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

имел ввиду уже готовые, ввиде PCI платы например

Готовые - есть конешно. Во первых, на всех платах оцифровки, с которыми доводилось работать, обязательно была опция генерить прерывание на шине по внутреннему таймеру с задаваемой юзером скважностью. Кстати, 5 лет назад оживлял PCI плату (тогда стоила 2 штуки), которая прерывала ЦПУ с частотой 20 кГц - и выдавала 12 каналов по 32 бита (если не соврал - частоту и разрядность АЦПУ точно помню, а кол-во каналов - нет). И ничё, крутилась там же рисовальная задачка (поначалу под LabVIEW, пришлось переписать - через часа 4 начинала глючить) и она же пульт управления, команды слались по сети. Проц был 450 МГц Р2.

Во-вторых, есть класс устройств, называемых watchdog. Таймер с прерывалкой шины и небольшой логикой. Их обычно ставят на сервера - обработчик прерывания (в драйвере вотчдога для данной ОС) чистит регистр на платке. И если регистр непочищен, а пришло следующее прерывание, то вотчдог считает, что ОС повисла и тогда прерывает питание (на шине, на ЦПУ, везде - возможны варианты), чтобы вызвать жёсткий ресет.

Берём вотчдог из общей бочки и вешаем свой обработчик, например...

[dachny]

Жесткие циклы в User Mode признак дельфизма в худшем смысле этого слова
вообще мое мнение для windows nt в user mode надо делать только то что невозможно сделать в kernel например рисование окошек

По сути вопроса: Mое мнение надо изобрести специализированную железяку лучше писай которая не прерывание делает а непосредственно данные посылает

по поводу производительности ПС: Я по производственной необходимости изобретаю всякие железяки сбора данных для компьютера так вот при трафике порядка 500 Гбит в сек НЕ ОПЕЧАТКА работают USER MODE рисовалки данных загрузка ЦП 20% не более и зависимось от крутизны процессора очень слабая то есть ее вообще нет а от частоты памяти и типа чипсета есть.

В 96 году я тоже делал жесткие циклы в user mode но я тогда был еще зеленый и учебные проекты того времени вызавают у меня улыбку умиления  

[dachny]

так вот при трафике порядка 500 Гбит в сек НЕ ОПЕЧАТКА работают

все таки опечатка

500 Мбит

прошу прощения

[grozny]

Жесткие циклы в User Mode признак дельфизма в худшем смысле этого слова
вообще мое мнение для windows nt в user mode надо делать только то что невозможно сделать в kernel например рисование окошек

   :twisted:  :idea: Так вооот куда уходит драгоценный ядерный ресурс... А вы говорите - "опять Майкрософт весь NONPAGED_POOL съел"

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

[grozny]

В 96 году я тоже делал жесткие циклы в user mode но я тогда был еще зеленый и учебные проекты того времени вызавают у меня улыбку умиления  

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

Сейчас от той системы в эксплуатации только софт и остался, ага (самый верх, 3-е кольцо ), причём перенесённый с 98-х как есть под 2к и ХР.
Still doesn't ring any bells?