|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5049/1.118 14 Feb 2001 06:02:28
To : All
Subject : Варантированное время ответа
--------------------------------------------------------------------------------
At 11 Feb 01 23:29:58, Evgeny Kazanov wrote to All:
>> учти что нормальный реалтайм, к сожалению, в системах a-la линух, фря -
>> не получишь.(
EK> ╦ об этом догадываюсь. Hо, для меня коммерческие системы не годятся.
EK> ╗ричины я уже приводил. В случае, если мне надо жесткий риалтайм,
EK> я смотрю в сторону RTLinux. IMHO на нем уже можно вполне делать
EK> то что мне нужно - ╗ростой реал тайм сбор данных. Ш счастью
EK> необходимость жесткого реалтайма для сложных задач
EK> встречается достаточно редко, по крайней мере я не встречал.
Ы более того - от такой необходимости можно чаще всего избавиться посредством
добавления к машине снаружи более или менее сложной электроники(чаще всего -
простой). ╗ростейшая иллюстрация моей мысли - известно, что воспроизведение
звука через covox на принтерный порт съест все ресурсы машины из-за
необходимости выдерживать постоянство потока данных.
Тобавление в систему звуковой карточки, умеющей dma или хотябы собственый буфер
- позволяет слушать музыку вообще не ощущая нагрузки на систему.
>> но никоим образом его не гарантируют (грабли с инверсиями приоритетов,
>> etc.)
EK> Щожно поподробнее? ╦ как-то с трудом могу себе это представить.
Там говоилось очевидно о машине, где загрузка под 70% и при этом хотят
какого-нибудь слишком хорошего времени реакции.
EK> Усли я устрою свою измерительную систему, с эзернетом, в котором
EK> только мои компьютеры, т.е. трафик маленький и заранее известный,
EK> выключу всякие логротейты и т.д. (Руду их проводить как регламентное
EK> обслуживание или вообще отключу запись в лог), все задачи и потребляемые
EK> ими ресурсы будут известны и я не смогу получить гарантированное время
EK> отклика 0.5 - 2с? Ъб[ясни, если не получу, то почему?
╗олучишь. Чтобы не получить - надо хорошо извратиться.
Впрочем - есть одни грабли - первая же ошибка записи на IDE-диск например - и
его драйвер поставит тебе систему раком на значительно большее время. ╗отом
очухается, но время будет потеряно.
EK> Hасчет свопинга - это по-моему просто первая причина возможных
EK> задержек при применении ЪС общего назначения.
╗ервая и главная.
> Вторая - шедулер.
EK> Hо я вообще-то не очень силен в шедулере. Вде можно популярно
EK> про него прочитать?
Вде прочитать - не знаю. Hо если припрет тормознутость стандартного линуксового
планировщика - ищешь в интернете "qnx style scheduler". ╗равда он для ядер
только до 2.0.38 :-( ╦ до сих пор на этом ядре сижу именно по причине
отсутствия задержек реакции на нажатие клавиш при любой нагрузке если стоит
этот планировщик. ╗охоже дело идет к тому, что новое ядро я буду ставить только
на машинах, занимающихся телекоммуникациями(из-за расширенных возможностей
роутинга), а на машине, где сижу сам - оставлю старое ядро с этим планировщиком
пока будет хоть какая-то возможность этим ядром пользоваться, либо пока не
куплю себе гигагерцевый проц от AMD.
Zahar
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Gateway NEWS (http://in.kazan.ru) <=> FidoNet (2:5049/1)
+ of Kazan Physical-Technical Institute
+ ( http://kfti.knc.ru ; http://kazinfo.knc.ru )
+
+ User email address: Zahar.Kiselev@p1.f382.n5030.z2.fidonet.org
+ User FidoNet address: 2:5030/382.1.
--- NewsGate+ v0.8Р3
* Origin: Kazan Physical-Technical Institute, Gateway NEWS (2:5049/1.118)
бЕПМСРЭЯЪ Й ЯОХЯЙС РЕЛ, ЯНПРХПНБЮММШУ ОН: БНГПЮЯРЮМХЕ ДЮРШ СЛЕМЭЬЕМХЕ ДЮРШ РЕЛЮ ЮБРНП
| рЕЛЮ: |
юБРНП: |
дЮРЮ: |
|
Варантированное время ответа |
Zahar Kiselev |
14 Feb 2001 06:02:28 |
|
|
