Linux and FreeBSD

From

Slawa Olhovchenkov (2:5030/500)

To

Constantin Stefanov

Date

2005-06-01T14:35:02Z

Area

RU.UNIX.BSD

Hello Constantin!

01 Jun 05, Constantin Stefanov writes to Slawa Olhovchenkov:

 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> подкреплены. А так - ну слабое доверие.

Я подумаю что тут можно еально и достоверно померять. Потому что верить писюковому таймеру на микросекундных задержках я не могу совсем.

 CS> Кстати, насчет задержек. У того же InfiniBand, если его включить без
 CS> свитча напрямую узел в узел, время задержки и скорость передачи слабо
 CS> меняются, что косвенно свидетельствует о том, что там в свитче не
 CS> sore-and-forward.

Так это ж изначально постулировалось, разве нет?

... Window's performance is now measured in BogoGPF's.
--- GoldED+/BSD 1.1.5
 * Origin:  (2:5030/500)
SEEN-BY: 46/50 50/203 400/814 450/186 247 1024 451/30 550/196 4635/4 4652/15
SEEN-BY: 5000/5000 5011/13 5015/10 5019/31 5020/52 154 175 400 545 549 715 758
SEEN-BY: 5020/830 937 1523 1604 1630 2020 2142 2238 2450 2590 4441 5021/29
SEEN-BY: 5022/128 5025/3 750 5027/16 5029/32 5030/49 115 473 500 556 966 1063
SEEN-BY: 5030/1900 5031/70 72 5035/38 5036/34 5042/13 5049/50 97 5054/1 4 8 9
SEEN-BY: 5054/28 35 36 37 63 66 67 70 75 81 84 85 5055/95 5061/120 5062/1 10
SEEN-BY: 5063/3 5067/2 5069/7 5070/1222 5079/23 5080/80 1003 5082/6 5083/21
SEEN-BY: 5085/13 5090/108 5095/20 5096/18 6000/12 254 6001/10

PATH: 5030/500 5020/4441 545 5054/1 37