реклама на сайте
подробности

 
 
> теор. вопрос по коммутации пакетов, (Layer2 switching)
romez777
сообщение Jan 3 2006, 09:53
Сообщение #1


Местный
***

Группа: Свой
Сообщений: 292
Регистрация: 9-11-04
Пользователь №: 1 077



Приветствую.
Часто в литературе попадаются термины, объяснения которым даются не совсем внятные и понятные для меня.

Например:
1) line-rate switching (wire speed switching, то же самое? )
2) L2 aging of entries (как я понял, это применяется к механизму управления таблицей соответствия <МАC-адрес>-порт)

И еще несколько других, но о них позже, сейчас хотелось бы разобраться с этими.

Заранее благодарю.
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов
klogg
сообщение Jan 9 2006, 09:50
Сообщение #2


Участник
*

Группа: Свой
Сообщений: 65
Регистрация: 13-07-04
Пользователь №: 320



Насчёт первого - не скажу, т.к. определения "line-rate switching" не встречал, в отличие от "wire speed switching"... По смыслу вроде то же самое.
А "L2 aging of entries" - время устаревания MAC адресов в таблице коммутатора.


--------------------
NO! - I mean, no, Klogg. This crown is the only thing that you cannot have.
-- Hoborg
Go to the top of the page
 
+Quote Post
romez777
сообщение Jan 11 2006, 05:45
Сообщение #3


Местный
***

Группа: Свой
Сообщений: 292
Регистрация: 9-11-04
Пользователь №: 1 077



Цитата(klogg @ Jan 9 2006, 12:50) *
Насчёт первого - не скажу, т.к. определения "line-rate switching" не встречал, в отличие от "wire speed switching"... По смыслу вроде то же самое.
А "L2 aging of entries" - время устаревания MAC адресов в таблице коммутатора.


Приветствую.

Спасибо, погуглил и разобрался с терминами. Вот еще вопрос, возможна такая ситуация в свитчах, когда пакет сидит в очереди и не может быть отфрварден на др. порт по той причине, что порт назначние занят обработкой другого пакета. И пакеты постепенно копятся в буфере. Это называется head-of-line blocking (HOL blocking), но вот нигде не нашел способов борьбы/предотвращения таких ситуаций. Очевидно, что простое увеличение размера буфера проблемы не решит.

Есть каие-то идеи на этот счет?
Go to the top of the page
 
+Quote Post
xyzzy
сообщение Jan 11 2006, 07:48
Сообщение #4


Частый гость
**

Группа: Свой
Сообщений: 95
Регистрация: 10-04-05
Пользователь №: 4 003



Цитата(romez777 @ Jan 10 2006, 21:45) *
Спасибо, погуглил и разобрался с терминами. Вот еще вопрос, возможна такая ситуация в свитчах, когда пакет сидит в очереди и не может быть отфрварден на др. порт по той причине, что порт назначние занят обработкой другого пакета. И пакеты постепенно копятся в буфере. Это называется head-of-line blocking (HOL blocking), но вот нигде не нашел способов борьбы/предотвращения таких ситуаций. Очевидно, что простое увеличение размера буфера проблемы не решит.

Есть каие-то идеи на этот счет?


Способов борьбы не сильно много. Буферизовать до бесконечности не получится. В итоге варианта ровно три - увеличить скорость выходного канала (не очень реально, ибо она какая есть, такая есть), либо слать поменьше, либо ронять пакеты. Последние два подхода и рассмотрим.

Первый подход. Из практических вариантов, как мне кажется, тут только flow control. По прилету пакета, который кладется в почти полный буфер, источнику пакета отсылается flow control пакет, что, мол, погоди маленько и больше не шли в течение какого-то времени. Проблема в том, что посылающий может либо проигнорировать это дело, и продолжить слать. Вторая проблема, если он таки откладывает посылку пакетов, то это также задержит пакеты предназначеные для других, потенциально доступных портов.

Второй класс - выкидываем пакеты. Вопрос - какие именно?

Вариант А: Просто выкидывать последний прилетевший пакет (tail-drop). Если буфер маленький - убивает производительность TCP - просто жуть. Все из-за того, что уронили именно последние пакеты и принимающая сторона просто не знает, потерялись ли пакеты в дороге или их вообще не посылали.Зато в железе tail-drop реализуется относительно просто. В итоге - частое явление в дешевых устройствах.

Вариант Б: выкидываем произвольные пакеты из буфера (на ум приходит RED - random early detection). Чуть лучше, чем вариант А. На TCP влияет существенно меньше. Производительность падает, но не сильно смертельно. Принимающая сторона замечает пропажу пакетов и сообщает другому концу, что неплохо бы отослать потерявшееся еще раз.
Проблема - все равно роняем без разбора. Не все протоколы это хорошо переживают.

Вариант В - QoS (Quality of Service): разбиваем буффер на несколько и сортируем входящий траффик. Очень важные, но относительно редкие пакеты кладем в один буффер, частые, но не очень важные - в другой. Полностью проблему решает не всегда, но дает хоть какой-то контроль, что же именно мы предпочитаем терять.


--------------------
--xyzzy
Go to the top of the page
 
+Quote Post
romez777
сообщение Jan 13 2006, 07:28
Сообщение #5


Местный
***

Группа: Свой
Сообщений: 292
Регистрация: 9-11-04
Пользователь №: 1 077



Большое спасибо комментарии.

Как я понимаю, нет статических методов предупреждения/избжания HOL-blocking, то есть меры должны приниматься на всех уровнях, и на низком (MAC layer) и на более высоком (IP, вот еще вычитал про ECN-Explicit congestion notification).

И еще по терминам. Часто в описаниях L2/3 коммутирующих чипов встречаются два понятия:

1) integrated (например 5-port 10/100 integrated switch)
2) multi-layer ( например Broadcom BCM5645 ...)

Что они обозначают?
Go to the top of the page
 
+Quote Post



Reply to this topicStart new topic
2 чел. читают эту тему (гостей: 2, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 27th July 2025 - 04:47
Рейтинг@Mail.ru


Страница сгенерированна за 0.0139 секунд с 7
ELECTRONIX ©2004-2016