информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
За кого нас держат?Где водятся OGRыВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Линуксовый ботнет, распространяющийся... 
 Конец поддержки Internet Explorer 
 Рекордное число уязвимостей в 2021 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / theory
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
Всё что описано здесь до боли напоминает управляемые коммутаторы с QOS 02.07.08 11:18  Число просмотров: 4044
Автор: Ustin <Ustin> Статус: Elderman
Отредактировано 02.07.08 11:20  Количество правок: 1
<"чистая" ссылка>
> А?
подмывает Б написать на весь вопрос
>
> Наверное там должно иметь место понятие "приоритет пакета"
> и "вытеснение пакета". Т.е. когда пакет с бОльшим
> приоритетом может вытеснить с магистрали пакет с меньшим
> приоритетом, аналогично тому как поток с бОльшим
> приоритетом вытесняет поток с меньшим приоритетом.
> Я прав?
Это и есть QOS

> Вообще где можно о них чё-нить почитать?
Для начала ознакомиться с http://book.itep.ru/4/4/mpls17.htm, а потом определиться что нужно
<theory>
А существуют ли в продаже сетевые вытесняющие RTOS ? 02.07.08 00:17   [Ustin]
Автор: Дон Амброзио Статус: Незарегистрированный пользователь
<"чистая" ссылка>
Ну т.е. такие RTOS в доках на которые чёрным по белому написано, что регламентируется время реакции на событие как и у обычных RTOS (у которых регламентируется время реакции только на "местные" событие), но независимо от того, что событие произошло на одном девайсе сети, а его поток обработчик находится на другом девайсе сети.

А?

Наверное там должно иметь место понятие "приоритет пакета" и "вытеснение пакета". Т.е. когда пакет с бОльшим приоритетом может вытеснить с магистрали пакет с меньшим приоритетом, аналогично тому как поток с бОльшим приоритетом вытесняет поток с меньшим приоритетом.

Я прав?

Вообще где можно о них чё-нить почитать? О том как они устроены. Как обеспечивается в них регламентируемое время обработки события не смотря на то, что в системе могут быть события, требующие разного времени реакции и не смотря на то, что устройство, которое сигналит о осбытие и устройство получатель инфы о событии могут находится друг от друга на "расстоянии" нескольких хопов
Почему в продаже, Линукс бесплатно распространяется... 03.07.08 10:14  
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman
Отредактировано 03.07.08 10:16  Количество правок: 1
<"чистая" ссылка>
> Ну т.е. такие RTOS в доках на которые чёрным по белому
> написано, что регламентируется время реакции на событие как
> и у обычных RTOS (у которых регламентируется время реакции
> только на "местные" событие), но независимо от того, что
> событие произошло на одном девайсе сети, а его поток
> обработчик находится на другом девайсе сети.

Почему в продаже, Линукс бесплатно распространяется (RTLinux). Касаемо времени реакции нужно в нем смотреть. Там не будет одного числа. Поскольку реакция измеряется в инструкциях, ее время будет зависеть от скорости/частоты процессора. Разумеется время нельзя будет получить умножив время выполнения одной инструкции на их количество. Мало того, даже время выполнения любой инструкции может быть разным в зависимости от того, в каком кеше она находится, да и вообще, находится ли она в кеше или только в ОЗУ.
Из непродающихся точно помню как это описывалось для RT/RSX(ОСРВ/РАФОС/ФОБОС). Указывалось максимальное количество инструкций, которые выполнялись на каждом уровне (на непрерываемом, на уровне приоритета устройства, на низшем уровне приоритета, а на уровне отложенного прерывания их количество естественно не лимитировалось). Максимальное/типичное время посчитать можно было достаточно точно.

> Наверное там должно иметь место понятие "приоритет пакета"
> и "вытеснение пакета". Т.е. когда пакет с бОльшим
> приоритетом может вытеснить с магистрали пакет с меньшим
> приоритетом, аналогично тому как поток с бОльшим
> приоритетом вытесняет поток с меньшим приоритетом.

Если очереди на передачу нет, то приоритет бессмысленен. Если возникают коллизии, то время никто не гарантирует. При "общей шине" ни один передатчик не знает какого приоритета пакеты стоят в очереди у другого передатчика.

> Я прав?

Частично.

> Вообще где можно о них чё-нить почитать? О том как они
> устроены. Как обеспечивается в них регламентируемое время
> обработки события не смотря на то, что в системе могут быть
> события, требующие разного времени реакции и не смотря на
> то, что устройство, которое сигналит о осбытие и устройство
> получатель инфы о событии могут находится друг от друга на
> "расстоянии" нескольких хопов

Нигде и ничего, потому что за это уже отвечает не операционка, а информационный канал.
Время реакции будет складываться из времени передачи сигнала о событии, за которое операционка не отвечает и времени реакции на асинхронное прерывание от сетевого адаптера, которое уже операционка может регламентировать.
Всё что описано здесь до боли напоминает управляемые коммутаторы с QOS 02.07.08 11:18  
Автор: Ustin <Ustin> Статус: Elderman
Отредактировано 02.07.08 11:20  Количество правок: 1
<"чистая" ссылка>
> А?
подмывает Б написать на весь вопрос
>
> Наверное там должно иметь место понятие "приоритет пакета"
> и "вытеснение пакета". Т.е. когда пакет с бОльшим
> приоритетом может вытеснить с магистрали пакет с меньшим
> приоритетом, аналогично тому как поток с бОльшим
> приоритетом вытесняет поток с меньшим приоритетом.
> Я прав?
Это и есть QOS

> Вообще где можно о них чё-нить почитать?
Для начала ознакомиться с http://book.itep.ru/4/4/mpls17.htm, а потом определиться что нужно
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2022 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach