Конфигурация тестового стенда

4.2 Конфигурация тестового стенда

Исследования проводились на компьютере со следующей конфигурацией: AMD Duron 1000 MHz, EPoX 8KHA+ (VIA KT266A), 384 Mb DDR SDRAM. Файлы подкачки системы располагались на винчестерах Seagate Barracuda и Western Digital со скоростью вращения шпинделя 7200 об/мин, подключенными по интерфейсу IDE.

Операционная система, установленная на тестовой машине, Microsoft Windows XP Pro SP2. Система недавно переустанавливалась, работает стабильно.

4.3 Работа на небольших частотах

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

Для простоты пока будем предполагать что кроме нашего драйвера система больше не загружена никакими ресурсоемкими приложениями. То есть в диспетчере задач более 95% процессорного времени приходится на псевдо-процесс Idle («Бездействие системы»). Приоритет рабочего потока выставим в значение 16.

Частота 1 Гц дает нам приход запросов от имитируемого устройства каждые 1000 мс. Изначально была выставлена задержка 100 мс. Это дает системе 900 мс на «накладные расходы», что позволило драйверу стабильно выполнить необходимые действия. На прикладном уровне работа драйвера без привлечения специальных средств не ощущалась.

Затем мы стали увеличивать длительность задержки. Значение было доведено до 990 мс (что дает системе 10 мс на обработку «накладных расходов»). При такой задержке стабильная работа драйвера сохранилась, однако на прикладном уровне серьезно ощущались «рывки» — система тратила 99% времени на обработку в драйвере.

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

Еще нужно сказать о том, что если для частоты 1 Гц затраты на накладные расходы системы длиной в 10 мс можно считать нормальными, то на более высоких частотах (выше 100 Гц) это будет недопустимо большой паузой.

4.4 Точность изменения задержек

 

Далее по ходу исследования нам будет необходимо увеличивать частоту запросов и уменьшать длительность задержек. Не лишним будет по логу работы драйвера убедится, что выбранный нами способ организации задержек работает корректно. На рис 4.1 показан один из участков лога.

Рис 4.1. Точность измерения задержек

Начало задержки 990 мс — время 398.11619158, конец — 399.10677251. Расхождение с расчетным временем составило 0.00058093 с. Конечно, при уменьшении задержек и при включении внешней нагрузки погрешность увеличится, однако такой результат все равно можно назвать достаточно хорошим.

 

4.5 Точность работы таймера

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

Рис. 4.5. Точность работы таймера

Как видно, разница составила 0.000195 с, что тоже можно считать хорошим результатом.

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

 

4.6 Увеличение частоты срабатывания

Драйвер был запущен для частоты 1 кГц. Увеличивая постепенно время задержки было получении предельное значение около 200 мкс. Как видно, увеличение частоты в 1000 раз привело к уменьшению длительности задержки более чем в 1000 раз. В принципе даже такого интервала задержки могло бы хватить для реализации системы управления реального времени, однако следует учесть еще один фактор. В реальной системе помимо нашего драйвера выполняются еще и другие приложения, которые тоже требуют процессорного времени и других системных ресурсов. Проверим работу драйвера в присутствии таких приложений.

 

4.7 Работа параллельно с другими приложениями

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

4.7.1 Нагрузка на подсистему GDI

Известно, что подсистема GDI Windows имеет свой системный поток с приоритетом реального времени. Можно ожидать, что при большом количестве запросов к этой подсистеме может вызвать сбой в работе нашего драйвера. Проверим это.

Драйвер был запущен на частоте 1 кГц параллельно с приложением, выполняющим активное рисование средствами GDI. Стабильная работа драйвера сохранилась, однако графический вывод производился с заметными «рывками».

 

4.7.2 Работа со страничными отказами

Серьезной проблемой могут стать страничные отказы, происходящие в системе. Запуск на частоте 1 кГц параллельно с приложением, генерирующем множественные страничные отказы дал очень интересные результаты. Драйвер не смог выдержать временные задержки в 200 мкс. Более того, даже более короткие задержки (до 25 мкс) не давали устойчивой работы драйвера.

Рис 4.6. Остановка при обнаружении сбоя

Ситуация меняется к лучшему при увеличении приоритета потока драйвера. Можно предположить, что обработка страничных отказов выполняется также при помощи системного потока. Если мы устанавливаем свой приоритет выше его, то стабильность работы повышается. На приоритете 30 и частоте 1 кГц удалось добиться стабильной работы при страничных отказах с задержками до 100 мкс.

5. Заключение

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

После проведения некоторого количества экспериментов были получены допустимые времена задержек для частоты 1 кГц в «холостом» режиме работы системы и в режиме множественных страничных отказов. Для тестовой системы в первом случае время составило 200 мкс, а во втором 100 мкс.

Теоретический предел для частоты 1 кГц очевидно 1000 мкс, т.е. для полезной обработки данных внешнего устройства могут быть использованы 10—20% процессорного времени.

При соблюдении этих условий на операционной системе Windows может быть реализована система управления реального времени предложенного типа.

Приложение 1

Исходный код управляющего потока

VOID TimerThreadProc(PVOID startContext)

{TRACE("-> TimerThreadProc, IRQL = %d",

KeGetCurrentIrql());

KeSetPriorityThread((PKTHREAD)pTimerThread,31);

KPRIORITY priority =

KeQueryPriorityThread((PKTHREAD)pTimerThread);

TRACE("TimerThread Priority: %d",priority);

SetTimer();

while(!bExitThread)

{KeWaitForSingleObject(&kTimer,

Executive,KernelMode,FALSE,0);

if (bExitThread) break;

LONG state = KeReadStateEvent(&kEvent);

if (state == 0)

{TRACE("TimerThreadProc: KeSetEvent");

KeSetEvent(&kEvent,FALSE,FALSE);}

else

{TRACE("[!] Event already in signaled "

"state; aborted");

bTimerWorks = false;

break;}}

KillTimer();

TRACE("<- TimerThreadProc, exiting");

PsTerminateSystemThread(STATUS_SUCCESS);}

Приложение 2

Исходный код рабочего потока

VOID ThreadProc(PVOID startContext)

{TRACE("-> ThreadProc, IRQL = %d",KeGetCurrentIrql());

KeSetPriorityThread((PKTHREAD)pThread,curSett.Priority);

for(int i = 0;!bExitThread;i++)

{TRACE("* ThreadProc: loop %d, "

"priority %d",i,

KeQueryPriorityThread((PKTHREAD)pThread));

KeWaitForSingleObject(&kEvent,Executive,KernelMode,

FALSE,0);

if (bExitThread) break;

// имитируем работу

TRACE(">> Start \"working\"");

DELAY(curSett.Delay);

TRACE(">> Stop \"working\"");

// сбрасываем событие чтобы снова начать его ждать

KeResetEvent(&kEvent);}

TRACE("<- ThreadProc, exiting");

PsTerminateSystemThread(STATUS_SUCCESS);}