Почему в продаже, Линукс бесплатно распространяется...03.07.08 10:14 Число просмотров: 4472 Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman Отредактировано 03.07.08 10:16 Количество правок: 1
> Ну т.е. такие RTOS в доках на которые чёрным по белому > написано, что регламентируется время реакции на событие как > и у обычных RTOS (у которых регламентируется время реакции > только на "местные" событие), но независимо от того, что > событие произошло на одном девайсе сети, а его поток > обработчик находится на другом девайсе сети.
Почему в продаже, Линукс бесплатно распространяется (RTLinux). Касаемо времени реакции нужно в нем смотреть. Там не будет одного числа. Поскольку реакция измеряется в инструкциях, ее время будет зависеть от скорости/частоты процессора. Разумеется время нельзя будет получить умножив время выполнения одной инструкции на их количество. Мало того, даже время выполнения любой инструкции может быть разным в зависимости от того, в каком кеше она находится, да и вообще, находится ли она в кеше или только в ОЗУ.
Из непродающихся точно помню как это описывалось для RT/RSX(ОСРВ/РАФОС/ФОБОС). Указывалось максимальное количество инструкций, которые выполнялись на каждом уровне (на непрерываемом, на уровне приоритета устройства, на низшем уровне приоритета, а на уровне отложенного прерывания их количество естественно не лимитировалось). Максимальное/типичное время посчитать можно было достаточно точно.
> Наверное там должно иметь место понятие "приоритет пакета" > и "вытеснение пакета". Т.е. когда пакет с бОльшим > приоритетом может вытеснить с магистрали пакет с меньшим > приоритетом, аналогично тому как поток с бОльшим > приоритетом вытесняет поток с меньшим приоритетом.
Если очереди на передачу нет, то приоритет бессмысленен. Если возникают коллизии, то время никто не гарантирует. При "общей шине" ни один передатчик не знает какого приоритета пакеты стоят в очереди у другого передатчика.
> Я прав?
Частично.
> Вообще где можно о них чё-нить почитать? О том как они > устроены. Как обеспечивается в них регламентируемое время > обработки события не смотря на то, что в системе могут быть > события, требующие разного времени реакции и не смотря на > то, что устройство, которое сигналит о осбытие и устройство > получатель инфы о событии могут находится друг от друга на > "расстоянии" нескольких хопов
Нигде и ничего, потому что за это уже отвечает не операционка, а информационный канал.
Время реакции будет складываться из времени передачи сигнала о событии, за которое операционка не отвечает и времени реакции на асинхронное прерывание от сетевого адаптера, которое уже операционка может регламентировать.
Ну т.е. такие RTOS в доках на которые чёрным по белому написано, что регламентируется время реакции на событие как и у обычных RTOS (у которых регламентируется время реакции только на "местные" событие), но независимо от того, что событие произошло на одном девайсе сети, а его поток обработчик находится на другом девайсе сети.
А?
Наверное там должно иметь место понятие "приоритет пакета" и "вытеснение пакета". Т.е. когда пакет с бОльшим приоритетом может вытеснить с магистрали пакет с меньшим приоритетом, аналогично тому как поток с бОльшим приоритетом вытесняет поток с меньшим приоритетом.
Я прав?
Вообще где можно о них чё-нить почитать? О том как они устроены. Как обеспечивается в них регламентируемое время обработки события не смотря на то, что в системе могут быть события, требующие разного времени реакции и не смотря на то, что устройство, которое сигналит о осбытие и устройство получатель инфы о событии могут находится друг от друга на "расстоянии" нескольких хопов
Почему в продаже, Линукс бесплатно распространяется...03.07.08 10:14 Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman Отредактировано 03.07.08 10:16 Количество правок: 1
> Ну т.е. такие RTOS в доках на которые чёрным по белому > написано, что регламентируется время реакции на событие как > и у обычных RTOS (у которых регламентируется время реакции > только на "местные" событие), но независимо от того, что > событие произошло на одном девайсе сети, а его поток > обработчик находится на другом девайсе сети.
Почему в продаже, Линукс бесплатно распространяется (RTLinux). Касаемо времени реакции нужно в нем смотреть. Там не будет одного числа. Поскольку реакция измеряется в инструкциях, ее время будет зависеть от скорости/частоты процессора. Разумеется время нельзя будет получить умножив время выполнения одной инструкции на их количество. Мало того, даже время выполнения любой инструкции может быть разным в зависимости от того, в каком кеше она находится, да и вообще, находится ли она в кеше или только в ОЗУ.
Из непродающихся точно помню как это описывалось для RT/RSX(ОСРВ/РАФОС/ФОБОС). Указывалось максимальное количество инструкций, которые выполнялись на каждом уровне (на непрерываемом, на уровне приоритета устройства, на низшем уровне приоритета, а на уровне отложенного прерывания их количество естественно не лимитировалось). Максимальное/типичное время посчитать можно было достаточно точно.
> Наверное там должно иметь место понятие "приоритет пакета" > и "вытеснение пакета". Т.е. когда пакет с бОльшим > приоритетом может вытеснить с магистрали пакет с меньшим > приоритетом, аналогично тому как поток с бОльшим > приоритетом вытесняет поток с меньшим приоритетом.
Если очереди на передачу нет, то приоритет бессмысленен. Если возникают коллизии, то время никто не гарантирует. При "общей шине" ни один передатчик не знает какого приоритета пакеты стоят в очереди у другого передатчика.
> Я прав?
Частично.
> Вообще где можно о них чё-нить почитать? О том как они > устроены. Как обеспечивается в них регламентируемое время > обработки события не смотря на то, что в системе могут быть > события, требующие разного времени реакции и не смотря на > то, что устройство, которое сигналит о осбытие и устройство > получатель инфы о событии могут находится друг от друга на > "расстоянии" нескольких хопов
Нигде и ничего, потому что за это уже отвечает не операционка, а информационный канал.
Время реакции будет складываться из времени передачи сигнала о событии, за которое операционка не отвечает и времени реакции на асинхронное прерывание от сетевого адаптера, которое уже операционка может регламентировать.
Всё что описано здесь до боли напоминает управляемые коммутаторы с QOS02.07.08 11:18 Автор: Ustin <Ustin> Статус: Elderman Отредактировано 02.07.08 11:20 Количество правок: 1
> А? подмывает Б написать на весь вопрос
>
> Наверное там должно иметь место понятие "приоритет пакета" > и "вытеснение пакета". Т.е. когда пакет с бОльшим > приоритетом может вытеснить с магистрали пакет с меньшим > приоритетом, аналогично тому как поток с бОльшим > приоритетом вытесняет поток с меньшим приоритетом. > Я прав? Это и есть QOS
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
