Использование драйвера режима ядра и управляющего приложения для создания системных потоков. Имитация обработки данных и организация задержек. Разработка драйвера на языке C . Конфигурация тестового стенда. Точность изменения задержек и работы таймера.
Аннотация к работе
Сложно найти такой аспект повседневной жизнедеятельности, в которой еще не используется современная вычислительная техника. Так, к нам в руки попало специальное устройство, предназначенное для аналого-цифрового и цифро-аналогого преобразования сигнала на аппаратном уровне. С устройством поставляется специальный драйвер для работы в операционной системе (далее ОС) Windows.Такие потоки имеют приоритеты от 16 до 31 и выполняются в режиме ядра. Это означает, что если такой поток получает процессор (как системный ресурс), то он будет занимать его до тех пор, пока сам добровольно не вернет его системе, т.е. не перейдет в состояние блокировки (например в ожидание на функции WAITFORSINGLEOBJECT).Для создания системных потоков нам необходимо использовать драйвер, которым в нашем случае является драйвер виртуального устройства. Работу реального устройства мы будем эмулировать при помощи еще одного системного потока внутри нашего драйвера. Итак, при начальной инициализации (в функции DRIVERENTRY) драйвер запускает два системных потока. Это позволяет потоку пробуждаться через заранее определенные промежутки времени и будить второй поток, имитируя тем самым приход некоторых данных от внешнего устройства.При помощи специального приложения происходит управление работой драйвера. Внешний вид этого приложения показан на рис.Поскольку в реальных условиях параллельно с нашим драйвером будут выполняться и другие приложения, важно учесть это в ходе нашей исследовательской работы.Для чтения таких строк можно использовать специальные программные средства, в нашем случае будет использовано приложение DEBUGVIEW 4.31 от Марка Руссиновича (Mark Russinovich), внешний вид которого показан на рис.Для разработки настоящего драйвера был выбран язык C , поскольку он сочетает в себе простоту разработки программ с возможностью использования ассемблерных вставок для критических участков кода.Для этого можно использовать вызов специальной функции ядра KESTALLEXECUTIONPROCESSOR, однако в этом случае мы не можем контролировать что на самом деле произойдет с потоком и мы получим меньше информации о том сколько тактов центрального процессора было востребовано. Кроме того, при реальной работе вместо фиктивных задержек будут использованы реальные математические вычисления на центральном процессоре.Управление параметрами работы драйвером производится при помощи следующей структуры: struct CONTROLSTRUCT Поле Priority задает текущий приоритет рабочего потока драйвера (приоритет управляющего потока всегда 31). Поле Frequency задает частоту прихода данных от эмулируемого внешнего устройства.Для того чтобы начать исследование, необходимо определиться, как будет использоваться полученное программное обеспечение в ходе его проведения, и каких результатов мы хотим добиться. Начав с небольших частот мы попытаемся довести частоту до 1 КГЦ и добиться устойчивой работы на ней.Файлы подкачки системы располагались на винчестерах Seagate Barracuda и Western Digital со скоростью вращения шпинделя 7200 об/мин, подключенными по интерфейсу IDE.Начнем наше исследование с запуска драйвера на небольших частотах, а именно ограничимся частотой в 1 Гц и пронаблюдаем какие максимальные задержки мы сможем выставить сохраним стабильную работу драйвера. Для простоты пока будем предполагать что кроме нашего драйвера система больше не загружена никакими ресурсоемкими приложениями. Это дает системе 900 мс на «накладные расходы», что позволило драйверу стабильно выполнить необходимые действия. При такой задержке стабильная работа драйвера сохранилась, однако на прикладном уровне серьезно ощущались «рывки» - система тратила 99% времени на обработку в драйвере.Далее по ходу исследования нам будет необходимо увеличивать частоту запросов и уменьшать длительность задержек. Не лишним будет по логу работы драйвера убедится, что выбранный нами способ организации задержек работает корректно.Вместо внешнего устройства мы использовали ожидающий таймер, поэтому интересно будет проверить, насколько точно он позволит нам выдерживать необходимую частоту срабатывания. 4.5 представлены два момента срабатывания таймера для частоты 1 Гц.Драйвер был запущен для частоты 1 КГЦ. Увеличивая постепенно время задержки было получении предельное значение около 200 мкс.Для проведения исследования этого рода было написано специальное приложение, которое может создавать нагрузку определенного рода.Известно, что подсистема GDI Windows имеет свой системный поток с приоритетом реального времени.Серьезной проблемой могут стать страничные отказы, происходящие в системе. Запуск на частоте 1 КГЦ параллельно с приложением, генерирующем множественные страничные отказы дал очень интересные результаты. Драйвер не смог выдержать временные задержки в 200 мкс.Мы пронаблюдали работу драйвера, предназначенного для реализации системы реального времени, содержащего в себе системный поток, выполняющийся с приоритетом реального времени.
План
Содержание
1. Введение
2. Конструкторская часть
2.1. Общие принципы
2.2. Програмное обеспечение
2.2.1. Драйвер режима ядра
2.2.2. Управляющее приложение
2.2.3. Приложение для создания нагрузки
2.2.4. Обратная связь
3. Технологическая часть
3.1. Выбор средства разработки
3.2. Организация задержек
3.3. Взаимодействие с драйвером
4. Исследовательская часть
4.1. Цели и задачи
4.2. Конфигурация тестового стенда
4.3. Работа на небольших частотах
4.4. Точность изменения задержек
4.5. Точность работы таймера
4.6. Увеличение частоты срабатывания
4.7. Работа параллельно с другими приложениями
4.7.1. Нагрузка на подсистему GDI
4.7.2. Работа со страничными отказами
5. Заключение
Приложение 1. Исходный код управляющего потока
Приложение 2. Исходный код рабочего потока
Введение
В настоящее время компьютеры прочно вошли в нашу жизнь. Сложно найти такой аспект повседневной жизнедеятельности, в которой еще не используется современная вычислительная техника. Не являются исключением и различные научно-исследовательские работы. Так, к нам в руки попало специальное устройство, предназначенное для аналого-цифрового и цифро-аналогого преобразования сигнала на аппаратном уровне. С устройством поставляется специальный драйвер для работы в операционной системе (далее ОС) Windows.
После первых же экспериментов с устройством выяснилось, что работа с ним возможна только на небольших частотах обрабатываемого сигнала. При увеличении частоты наблюдается искажение сигнала связанное с тем, что система не успевает обрабатывать приходящие данные и выдавать данные в ответ. Этот результат можно считать закономерным, учитывая что ОС Windows вообще говоря не является операционной системой реального времени. Однако, сама операционная система содержит в себе набор средств, которые предположительно могут позволить создать систему управления реального времени в ОС Windows.
Вывод
Мы пронаблюдали работу драйвера, предназначенного для реализации системы реального времени, содержащего в себе системный поток, выполняющийся с приоритетом реального времени.
После проведения некоторого количества экспериментов были получены допустимые времена задержек для частоты 1 КГЦ в «холостом» режиме работы системы и в режиме множественных страничных отказов. Для тестовой системы в первом случае время составило 200 мкс, а во втором 100 мкс.
Теоретический предел для частоты 1 КГЦ очевидно 1000 мкс, т.е. для полезной обработки данных внешнего устройства могут быть использованы 10-20% процессорного времени.
При соблюдении этих условий на операционной системе Windows может быть реализована система управления реального времени предложенного типа.