|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Zahar Kiselev 2:5030/382.1 14 Feb 2001 04:02:28
To : Evgeny Kazanov
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
--- QDed alpha v3.57pl9.1e/Linux
* Origin: (Empty...) (2:5030/382.1)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
