Re: Linux and FreeBSD

From

Constantin Stefanov (2:5020/400)

To

Slawa Olhovchenkov

Date

2005-06-01T14:29:18Z

Area

RU.UNIX.BSD

From: Constantin Stefanov <cstef@mail.ru>

Slawa Olhovchenkov wrote:
>  >>  >> Погоди, SCI -- это бублик, я правильно помню?
>  >>  >> Воткни гигабитные карточки друг в друга, без свича -- то же самое и
>  >>  >> выйдет.
>  >>  CS> Бублик - есть тор двумерный. SCI может работать еще и в одномерном
>  >>  CS> режиме (кольцо), и в трехмерном. Но это к слову. Во-первых, даже
>  >>  CS> если ты натычешь по четыре гигабитаи все объединишь в тор,
>  >>
>  >> Можно ставить четырехголовые интеловые карты.
>  >>
>  >>  CS> то маршрутизацию сообщений тебе придется делать софтом, что породит
>  >>  CS> некислые задержки,
>  >>
>  >> Булшит.
>  CS> Объясняй, как ты заставишь интеловскую четырехгловую карту перебрасывать
>  CS> пакеты с одного порта на другой без помощи ЦП. По тору надо связываться
>  CS> не только соседям, а все узлы по дороге должны сообщение
>  CS> отмаршрутизировать.
> 
> Осваивай терминологию, а?
> Маршрутизация -- определение того, в каком направлении надо пнуть пакет.
> Форвардинг -- пихание пакета с одного интерфейса на другой.
> А теперь еще раз попробуй сформулировать свое первое утверждение и заодно
> расскажи про торы, а то я кажется не так их понимаю.
Хорошо. При соединениии машины в тор между двумя точками есть несколько 
возможных путей. Соответственно, каждая карточка, получив пакет, должна 
определить, в какой интерфейс его переслать дальше (если он не 
предназначен для данной машины). В торе часто используют простейшний 
алгоритм: сначала выбираем разницу по первой координате, потом по 
второй. Попробую нарисовать.

1 -2 -3 -4 -
|  |  |  |
5 -6 -7 -8 -
|  |  |  |
9 -10-11-12-
|  |  |  |
13-14-15-16-
|  |  |  |

Плюс, поскольку это тор, есть связи 1-4, 5-8, 9-12, 13-16, 1-13, 2-14, 
3-15, 4-16, которые показаны как уходящие вправо или вниз (тор - это 
квадрат, у которого можно выйти вправо от правого ребра и папсть на 
левое, и также с верхом и низом). На рисунке их не показал, чтобы не 
загромождать.
Итак, чтобы пакет переслать от 1 в 11 можно построить несколько путей. 
Например: 1-2-3-7-11, 1-2-6-7-11, 1-5-6-7-11. Предположим, мы люой пакет 
шлем сначала вниз до нужного уровня, потом направо (для сокращения пути 
иногда можно слать в обратную сторону, но это в данном случае 
непринципиально). Итак, мы должны провести пакет по такому пути: 
1-5-9-10-11. Предположим, ты реализуешь тор на интеловских 
четырехголовых картах (в двумерном торе у каждого узла как раз четыре 
связи). Что надо нашептать карте, чтобы пакет, посланный из узла 1 для 
узла 11 без вмешательства драйверов (т.е. без прерываний), сам до него 
долетел? Если угодно, в момент инициализации карты мы можем прописать 
соответствие между номерами узлов и MAC да и любые другие данные. можно 
ли потом карту заставить перепихивать пакеты из порта в порт саму, без ЦП?

> 
>  >>  CS> а тут все на карточке. А во-вторых, я что-то не уверен, что даже
>  >>  CS> если ты воткнешь два гигабита друг в друга, ты получишь латенстность
>  >>  CS> порядка 2 мкс
>  >> А куда ж оно денется.
>  CS> Не знаю, куда денется. Но цифр нигде ни разу не видел, а замерить, с чем
>  CS> ты и согласен, трудно. Или ты видел цифры по латентности гигабиты при
>  CS> включении узлов напрямую? Огласи, пожалуйста.
> 
> Я не вижу где им тормозить. По спецификации гигабита я тебе могу все задержки
> расписать. Дальше задержка старта карты, задержка прерывания по приему и
> накладные расходы на обработку прерываний и в драйверах-стеке. Последним
> пренебрегаем (оно примерно одинаковое для всех, если не использовать кривожопые
> драйвера), картам я не вижу с чего бы быть принципиально медленнее -- все
> примерно на одном техпроцессе делаются и внутренние задержки должны быть
> примерно одинаковы. Спецификация гигабита на full duplex оговаривает
> минимальные задержки между пакетами -- меньше 0.1 мкс.
Так чисто формально задержка всегда определяется скоростью 
распространения сигнала в среде. Однако реально выходит меньше. Поэтому 
я и прошу либо показать результаты тестов, что я сделал с InfiniBand, 
либо характеристики, озвученные производителем оборудования (что я 
сделал для остальных технологий). Тогда эти цифры будут как-то 
подкреплены. А так - ну слабое доверие.
Кстати, насчет задержек. У того же InfiniBand, если его включить без 
свитча напрямую узел в узел, время задержки и скорость передачи слабо 
меняются, что косвенно свидетельствует о том, что там в свитче не 
sore-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