=?iso-8859-1?q?=EE=C1=3A_=5Bmdk-re=5D_Re=3A_=5Bmdk-re=5D_Re=3A_=5Bmdk-re?= =?iso-8859-1?q?=5D_=EB=D4=CF-=CE=C9=C2=D5=C4=D8_=C9=D3=D0=CF=CC=D8=DA=CF?= =?iso-8859-1?q?=D7=C1=CC_Linux_=C4=CC=D1_=DA=C1=C4=C1=DE_=D2=C5=C1=CC=D8?= =?iso-8859-1?q?=CE=CF=C7=CF_=D7=D2=C5=CD=C5=CE=C9=3F?=

[Andrey Zolotnicky]

Эхх.. давненько не брал я в руки шашек :-))

> По опыту администрирования сервера-шлюза-прокси-сервера(чем не задача
> реального времени - обработка, фильтрация и раскидывание проходящих
пакетов
> +squid + почта с 1.5 Мбитным каналом и 70-тью активными пользователями
> инета) в NT и Linux.

Это НЕ задача реального времени. Основное отличие задачи (ОС) реального
времени от всех других - обеспечение ГАРАНТИРОВАННОГО времени отклика на
внешнее событие.

> Linux легко справляется с нагрузками на пентиуме с 64 Мб озу даже "не
> тормозясь при этом в КДЕ-шке, в то вр. как NT(sp5) на 128 Мб озу при этом
> ощутимо внешне тормозит(перерисовка экранов в оконной среде до минуты
> доходит) и иногда ругалась на "нехватку памяти" - выводы ....?

Выводы очень простые: "не тормозясь в КДЕ" - это НЕ объективная
характеристика.
Это вообще не характеристика :-))
Основной критерий ОС реального времени - на ЛЮБОЕ внешнее событие система
гарантированно отреагирует НЕ БОЛЕЕ чем через NN секунд (млилисекунд,
микросекунд).  Согласись, что даже небольшое превышение времени реакции
(заложенного разработчиком в алгоритм) на сигнал датчика на прокатном
стане может привести к серьезной аварии...

Cheers,
    Andrey

 mailto:andrey на kost.kz
 ICQ UIN:5526471
 nic-hdl:AZ774-RIPE