Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | | | | |
На той ОСРВ, на которой мне довелось поработать,... 17.03.04 15:45 Число просмотров: 1628
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 17.03.04 16:04 Количество правок: 3
|
> чем меньше этот интервал тем быстрее шедулер сможет
> получить управление и переключить выполнение задачи с одной
> на другую (страдает производительность, но увеличивается
> реалтаймость системы)
На той ОСРВ, на которой мне довелось поработать, переключение контекстов происходило не только по таймеру. По таймеру оно тоже, конечно когда-то происходило, если приложение долго (в зависимости от его приоритета) занимало процессорное время. Основное перекоючение контекстов происходило по внешним событиям, хотя, может оно и не происходило. Система находилась либо в состоянии останова ( выполнив инструкцию HATL), либо в состоянии ожидания вызова системной функции задачей, которая была активна. Чаще в состоянии останова - при набирании текста в редакторе задача (редактор) обращался к системе "жду нажатия клавиши". Как только клавиша была нажата выполнялся обработчик системы (драйвер) и иногда обработчик редактора не в зависимости от требований процессора другой задачей.
В том, что Вы описываете никакой реалтаймовости не видно или я что-то не понял. По вашему получается что пользователь, работая в редакторе нажал кнопку. Драйвер, обрабатывая прерывание, поставил символ в очередь ввода (буфер). Прошло 100 милисекунд, произошло прерывание от таймера, система посмотрела, что есть задача, которая ждет ввода и в буфере что-то есть, прекючила контекст на редактор, редактор вытащил символ из очереди и обработал его. Мне думается, что реалтаймовость, это когда любая активная задача отрабатывает события, которые к ней относятся сразу же, как они происходят в не зависимости от загруженности ЦПУ другими процессами, так, что создается иллюзия, что програма работает только сама одна.
На ПиДиПишках таймер тикает с фиксированным интервалом = 50Гц. Медленновато задачки при таком таймере переключаться будут, однако.
И еще в системе должны быть предусмотрены процессы ввода/вывода без ожидания, с вызовом обработчиков (функций в задачах) асинхронных системных прерываний, установкой / снятием флагов событий (семафоров). Т.е. в функции read() должны быть предусмотрены еще следующие параметры "производится ли чтение с ожиданием завершения или нет", "адрес функции-обработчика завершения ввода", "номер семафора" и прочие.
|
|
<operating systems>
|
Кто ползовал RTLinux... 15.03.04 16:26
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
Как впечатления?
Это понятно, что многим приложениям нужна реалтаймовость, а вот не помешает ли она какому-либо другому приложению? Все ли под ним пойдет, что не расчитано под реалтаймовость? Короче преимущества и недостатки, отличия и сходства...
|
|
не о RTLinux 15.03.04 17:29
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
|
к сожалению с системами где режим реального временидействительнопросто необходим не сталкивался
но с потребительской точки зрения скажу что ядро 2.6.х в плане отклика на действия пользователя намного приятнее чем 2.4.х. В чем это конкретно проявляется: при полной загрузке проца (при компиляции к примеру, интенсивных дисковых операциях) переключение между окнами в ядре 2.4 очень медленное - сначала рисуется окно, потом его содержимое. В аналогичной ситуации под 2.6 переключение начинается быстрее (меньше время реакции) и окно с содержимым появляется почти одновременно. Если же процессор загружен не полностью то разница не сильно чувствуется
|
| |
не о RTLinuх 16.03.04 18:59
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
> к сожалению с системами где режим реального времени
>действительнопросто необходим не сталкивался
Крылатые ракеты. К стати слышал, что американцы таким образом физически "уничтожали" ПиДиПишки под ЭрЭсИксом. Станки с ЧПУ тому еще примером могут послужить. Надежность - как побочный эффект.
> но с потребительской точки зрения скажу что ядро 2.6.х в
> плане отклика на действия пользователя намного приятнее чем
> 2.4.х. В чем это конкретно проявляется: при полной загрузке
> проца (при компиляции к примеру, интенсивных дисковых
> операциях) переключение между окнами в ядре 2.4 очень
> медленное - сначала рисуется окно, потом его содержимое. В
> аналогичной ситуации под 2.6 переключение начинается
Разница только в ядре получается? Т.е. достаточно ядро махнуть и при сборке указать, что хочу РТ?
> быстрее (меньше время реакции) и окно с содержимым
> появляется почти одновременно. Если же процессор загружен
> не полностью то разница не сильно чувствуется
Прелесть РТ мне знакома, когда после ЭрЭсИкс-11 ДОС "пощупал" - плевался, но не сильно. Потом Систем5 посмотрел - плевался чуть посильнее. Как только столкнулся с первыми Виндовсами - отплеваться слюны не хватает.
И суть вовсе не в скорости прорисовывания окошек, там все может утыкаться в акселератор, может в метод хранения и обработки содержимого окна. Грубо говоря если есть битмап содержимого окна, то через акселератор все и так за микросекуны выведется.
Наверное все-таки буду доставать РТЛинукс, чтоб посмотреть и оценить. А может и пока под ДОСом накатаю програмку управления автомобильным двигателем, поскольку желательное время реакции - микросекунды.
|
| | |
именно
17.03.04 10:44
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
|
> Разница только в ядре получается? Т.е. достаточно ядро
> махнуть и при сборке указать, что хочу РТ?
именно
тот же RTLinux (вернее ее бесплатный вариант http://www.fsmlabs.com/products/openrtlinux/), это патч к ядру
кроме того в 2.6 реализован новый, более эффективный чем в 2.4 алгоритм шедулера задач O2
> Прелесть РТ мне знакома, когда после ЭрЭсИкс-11 ДОС
> "пощупал" - плевался, но не сильно. Потом Систем5 посмотрел
> - плевался чуть посильнее. Как только столкнулся с первыми
> Виндовсами - отплеваться слюны не хватает.
форточки восем не попадают - особенно с их тормозами в explorer когда вставляешь плохо читаемый СД ;-))
> И суть вовсе не в скорости прорисовывания окошек, там все
> может утыкаться в акселератор, может в метод хранения и
> обработки содержимого окна. Грубо говоря если есть битмап
> содержимого окна, то через акселератор все и так за
> микросекуны выведется.
привел то первое в голову пришло, но главное действительно не в скорости прорисовки, а в скорости отклика на дествия пользователя (переключение окон)
> Наверное все-таки буду доставать РТЛинукс, чтоб посмотреть
> и оценить. А может и пока под ДОСом накатаю програмку
> управления автомобильным двигателем, поскольку желательное
> время реакции - микросекунды.
на 2.6.4 есть хороший патч WOLK2 (http://sourceforge.net/project/showfiles.php?group_id=49048&package_id=59777&release_id=111888). В нем к примеру есть опция Kernel internal timer frequency: 100,500,1000 микросекунды
|
| | | |
А при чем там внутренняя частота таймера? 17.03.04 13:54
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
|
|
|
| | | | |
насколько я понимаю 17.03.04 15:04
Автор: ZaDNiCa <indeed ZaDNiCa> Статус: Elderman
|
чем меньше этот интервал тем быстрее шедулер сможет получить управление и переключить выполнение задачи с одной на другую (страдает производительность, но увеличивается реалтаймость системы)
эту опцию нужно использовать совместно с Preemptible Kernel, которая позволяет переключать выполнение задачи прерывая системные вызовы
|
| | | | | |
На той ОСРВ, на которой мне довелось поработать,... 17.03.04 15:45
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 17.03.04 16:04 Количество правок: 3
|
> чем меньше этот интервал тем быстрее шедулер сможет
> получить управление и переключить выполнение задачи с одной
> на другую (страдает производительность, но увеличивается
> реалтаймость системы)
На той ОСРВ, на которой мне довелось поработать, переключение контекстов происходило не только по таймеру. По таймеру оно тоже, конечно когда-то происходило, если приложение долго (в зависимости от его приоритета) занимало процессорное время. Основное перекоючение контекстов происходило по внешним событиям, хотя, может оно и не происходило. Система находилась либо в состоянии останова ( выполнив инструкцию HATL), либо в состоянии ожидания вызова системной функции задачей, которая была активна. Чаще в состоянии останова - при набирании текста в редакторе задача (редактор) обращался к системе "жду нажатия клавиши". Как только клавиша была нажата выполнялся обработчик системы (драйвер) и иногда обработчик редактора не в зависимости от требований процессора другой задачей.
В том, что Вы описываете никакой реалтаймовости не видно или я что-то не понял. По вашему получается что пользователь, работая в редакторе нажал кнопку. Драйвер, обрабатывая прерывание, поставил символ в очередь ввода (буфер). Прошло 100 милисекунд, произошло прерывание от таймера, система посмотрела, что есть задача, которая ждет ввода и в буфере что-то есть, прекючила контекст на редактор, редактор вытащил символ из очереди и обработал его. Мне думается, что реалтаймовость, это когда любая активная задача отрабатывает события, которые к ней относятся сразу же, как они происходят в не зависимости от загруженности ЦПУ другими процессами, так, что создается иллюзия, что програма работает только сама одна.
На ПиДиПишках таймер тикает с фиксированным интервалом = 50Гц. Медленновато задачки при таком таймере переключаться будут, однако.
И еще в системе должны быть предусмотрены процессы ввода/вывода без ожидания, с вызовом обработчиков (функций в задачах) асинхронных системных прерываний, установкой / снятием флагов событий (семафоров). Т.е. в функции read() должны быть предусмотрены еще следующие параметры "производится ли чтение с ожиданием завершения или нет", "адрес функции-обработчика завершения ввода", "номер семафора" и прочие.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
