Re: Linux and FreeBSD

From

Constantin Stefanov (2:5020/400)

To

Slawa Olhovchenkov

Date

2005-06-01T15:06:46Z

Area

RU.UNIX.BSD

From: Constantin Stefanov <cstef@mail.ru>

Slawa Olhovchenkov wrote:
>  CS> непринципиально). Итак, мы должны провести пакет по такому пути:
>  CS> 1-5-9-10-11. Предположим, ты реализуешь тор на интеловских
>  CS> четырехголовых картах (в двумерном торе у каждого узла как раз четыре
>  CS> связи). Что надо нашептать карте, чтобы пакет, посланный из узла 1 для
>  CS> узла 11 без вмешательства драйверов (т.е. без прерываний), сам до него
>  CS> долетел? Если угодно, в момент инициализации карты мы можем прописать
>  CS> соответствие между номерами узлов и MAC да и любые другие данные. можно
>  CS> ли потом карту заставить перепихивать пакеты из порта в порт саму, без ЦП?
> 
> Понял. Хороший вопрос. Дальше излагаю некотрые соображения за которые зуба не
> дам, поскольку несколько плаваю.
> Значит на интеловых 100мбит платах есть мини-проц, который на самом деле жрет
> микрокод и по нему обрабатывает принимаемые пакеты и генерит прерывания
> центральномы процессору, общается с шиной. Это стопроцентно. Вроде как даже
> есть проект под линух, который реализует на этой карте роутер и микрокод
> занимается роутингом. Вероятно подобная конструкция есть на гиговых интелях, я
> не сумел разобраться, а глубоко не копался.
Вероятно, это можно сделать. Правда, встанет вопрос о производительности 
этого процессора и его памяти при одновременной коммутации двух потоков 
- это ж такой свитч в миниатюре получится. И, кстати, он вполне может не 
уметь перебросить данные с одного порта на другой - обычно-то он данные 
гоняет между шиной и портом.

>  >> Я не вижу где им тормозить. По спецификации гигабита я тебе могу все
>  >> задержки расписать. Дальше задержка старта карты, задержка прерывания по
>  >> приему и накладные расходы на обработку прерываний и в драйверах-стеке.
>  >> Последним пренебрегаем (оно примерно одинаковое для всех, если не
>  >> использовать кривожопые драйвера), картам я не вижу с чего бы быть
>  >> принципиально медленнее -- все примерно на одном техпроцессе делаются и
>  >> внутренние задержки должны быть примерно одинаковы. Спецификация гигабита
>  >> на full duplex оговаривает минимальные задержки между пакетами -- меньше
>  >> 0.1 мкс.
>  CS> Так чисто формально задержка всегда определяется скоростью
>  CS> распространения сигнала в среде. Однако реально выходит меньше. Поэтому
>  CS> я и прошу либо показать результаты тестов, что я сделал с InfiniBand,
>  CS> либо характеристики, озвученные производителем оборудования (что я
>  CS> сделал для остальных технологий). Тогда эти цифры будут как-то
>  CS> подкреплены. А так - ну слабое доверие.
> 
> Я подумаю что тут можно еально и достоверно померять. Потому что верить
> писюковому таймеру на микросекундных задержках я не могу совсем.
Так что пока сойдемся, что мы не знаем, какие будут задержки на Gigabit 
Ethernet при непосредственном подключении двух машин друг к другу.

>  CS> Кстати, насчет задержек. У того же InfiniBand, если его включить без
>  CS> свитча напрямую узел в узел, время задержки и скорость передачи слабо
>  CS> меняются, что косвенно свидетельствует о том, что там в свитче не
>  CS> sore-and-forward.
> 
> Так это ж изначально постулировалось, разве нет?
Вот цитата из моего ответа тебе же:
==========================================================
Сразу насчет соседнего письма. В Myrinet - точно не store-and-forward,
там на каждое сообщение пробивается что-то типа виртуального канала. А
уж свитч устроен так, чтобы это все блокировалось как можно реже (не
уверен, что там используется схема вообще свободная от блокировок, но
такое может быть).
В InfiniBand - точно не знаю. Вероятно, тоже не store-and-forward. Там
внутри свитча fat-tree, т.е. такая схема, которая может коммутировать
одноверменно любые пары портов без блокировок (то есть скорость обмена
пары узлов не зависит от того, какая нагрузка на остальных парах).
==========================================================
Я не был в этом уверен тогда, не уверен и сейчас, хотя думаю, что так и 
есть - не store-and-forward.

-- 
Константин Стефанов
--- ifmail v.2.15dev5.3
 * Origin: Demos online service (2:5020/400)
SEEN-BY: 46/50 50/203 520 400/814 450/159 186 247 1024 451/30 461/43 132 640
SEEN-BY: 469/999 550/196 4616/3 4625/8 4627/10 4635/4 4652/15 5000/76 5000
SEEN-BY: 5006/1 5007/1 5010/70 5011/13 5015/10 5019/31 5020/52 118 154 175 194
SEEN-BY: 5020/400 545 549 604 715 758 830 937 1057 1523 1604 1630 1922 2020
SEEN-BY: 5020/2142 2238 2450 2590 4441 5021/29 5022/128 5025/3 750 5026/45
SEEN-BY: 5027/16 5029/32 5030/49 115 473 500 556 966 1063 1900 5031/70 72
SEEN-BY: 5034/13 5035/3 38 5036/1 34 5042/13 5049/1 50 97 5051/15 5054/1 4 8 9
SEEN-BY: 5054/28 35 36 37 63 66 67 70 75 81 84 85 5055/95 5057/1 5060/88
SEEN-BY: 5061/15 120 5062/1 10 5063/3 5066/18 5067/2 5069/7 5070/1222 5074/9
SEEN-BY: 5075/5 35 5079/23 5080/80 1003 5081/2 5082/6 5083/21 5085/13 5090/108
SEEN-BY: 5095/20 5096/18 6000/12 254 6001/3 10

PATH: 5020/400 4441 545 5054/1 37