Re: Linux and FreeBSD

From

Constantin Stefanov (2:5020/400)

To

Slawa Olhovchenkov (2:5054/37.63)

Date

2005-05-30T16:15:48Z

Area

RU.UNIX.BSD

From: Constantin Stefanov <cstef@mail.ru>

Slawa Olhovchenkov wrote:
>  CS> Длина   латентность,
>  CS> сооб-   мкс
>  CS> щения,
>  CS> байт
>  CS> 0   5.7
>  CS> 1   5.97
>  CS> 10  6.01
>  CS> 100 6.35
>  CS> 1000    9.82
>  CS> 1500    10.27
>  CS> 1501    10.26
>  CS> 2000    10.88
>  CS> 5000    13.27
>  CS> 10000   19.44
>  CS> 100000  127.48
> 
> Не верю. Сам посмотри, 1500 байт и 2000 байт передаются практически одинаковое
> время (10мкс).
> А минимальная задержка (для 1 байта) -- 5мкс. Какая у тебя скорость в канале?
> 1.25Гб/с? 10000 байт должны передаваться 10000*8/(1.25*10^9)*10^6=64мкс, у тебя
> что там, машина времени?
Скорость, как уже было сказано, 10 Гбит/сек. Это InfiniBand через свитч. 
Тест прогнан прям перед написанием письма на реальной системе.

>  CS> Система не самая лучшая (свитч  не фонтан, да и глюк в матери мешает),
>  CS> поэтому получается больше 5 мкс. 4 мкс, по утверждению разработчика,
>  CS> достигается на PCI Express.
>  CS> Теперь жду от тебя аналогичной таблички  на гигабитный эзернет, и , в
>  CS> идеале, на 10 Gb.
> Я не опущусь до такого позора.
А почему, собственно? Прогнать тест и запостить результаты - сложно? 
Потом сравним и увидим разницу. И вот ее уже можно обсуждать. А так - 
словоблудие какое-то.
>  CS> Сразу насчет соседнего письма. В Myrinet - точно не store-and-forward,
>  CS> там на каждое сообщение пробивается что-то типа виртуального канала. А
>  CS> уж свитч устроен так, чтобы это все блокировалось как можно реже (не
>  CS> уверен, что там используется схема вообще свободная от блокировок, но
>  CS> такое может быть).
> Ну щаз. Начинай лапшу с ушей сматывать -- как это будет без блокировок, если
> одновременно две станции захотят передавать сообщение на третью?
Две на одну - с блокировкой. Но если ты все станции на свитче разобьешь 
на пары, то каждая пара может друг с другом обмениваться с той же 
скоростью, как если бы она была на свитче одна. Покажи мне Ethernet 
свитч с такими характеристиками.

>  CS> В InfiniBand - точно не знаю. Вероятно, тоже не store-and-forward. Там
>  CS> внутри свитча fat-tree, т.е. такая схема, которая может коммутировать
>  CS> одноверменно любые пары портов без блокировок (то есть скорость обмена
>  CS> пары узлов не зависит от того, какая нагрузка на остальных парах).
> Ой, рокет сайнс, тоже мне.
> 
>  CS> А теперь объясни, где там ЖОПА в не store-and-forward.
> Гуляющие задержки.
> Когда идет передача на какую-то станцию все остальные желющие ей что-либо
> сказать сосут лапу и не могут отослать желаемое свичу дабы начать пересылать
> пакеты другим адресатам.
> Если есть желание -- могу поискать более детальные исследования. Это не только
> в коммутаторах езернета различного вида обнаружилось, но и в сетях хранения
> данных.
Ну не вопрос. Но на гуляющие задержки идут, дабы сделать среднюю 
латенстность поменьше. Плюс см. ниже про разделение типа портов на 
уровне карты. Если затык одному адресату - мы пока другому кинем сообщение.

>  CS> Теперь насчет драйверов. Во-первых, в этих технологиях нет такого
>  CS> маленького ограничения на макс. размер пакета. Я не знаю, где он какой,
>  CS> но даже если инкрементировать размер сообщения по единичке, то скачка,
>  CS> как на ethernet от 1500 к 1501 ты не получишь, т.е. меньше прерывания.
> 
> Я про _GigabitEthernet_ говорю. Не про Ethernet, не про FastEthernet. Ты
> разницу видишь? На GigabitEthernet допустимы jumbo frames, это 9000 байт как
> минимум.
Хорошо. Покажи разницу во времени передачи сообщения на длинах 9000 и 
9001 байт.

>  CS> Во-вторых, на InfinBand релизована хитрая технология RDMA (Remote
>  CS> DMA), которая позволяет дать карточке команду "отслать вот эту область
>  CS> данных (ну или принять от того-то туда-то)", после чего весь процесс
>  CS> произойдет без прерываний, т.е. опять имеем уменьшение нагрузки.
> 
> А теперь без булшита -- чем это круче тривиального busmaster в тривиальныйх
> интелях и броадкомах?
> И почему тебе после отсылки прерывание не нужно?
Нужно. Только ты сможешь сказать ителю "отошли мне вот отсюда 2 МБ"? Я 
не знаток устройства PCI, но что-то мне кажется, что все-таки ему нельзя 
сказать отсылать такую большую порцию данных.
Кроме того, там можно настроить все это так, чтобы одна машина дает 
команду своим драйверам "воон тому хосту можно лить мне в память что ему 
надо". А тот уже дает команду драйверу, в какое место адресного 
пространства удаленного процесса запихнуть данные. Это не очень секурно 
вероятно, но там, где это применяется, другие подходы к безопасности, но 
опять-таки позволяет сэкономить.

>  CS> На карте стоит достаточно большая своя память (от 128 МБ), так что
>  CS> опять часто дергать не приходится.
> Типа экзотика? Не смешно.
Отлично. Назови марку карты Gigabit Ethernet, где хотя бы столько.

>  CS> На карте релизована аппаратно что-то вроде схемы портов для TCP, т.е.
>  CS> карта сама может разбираться, какой поток для какой программы и
>  CS> запихивать его в нужную область ОЗУ без участия драйверов.
> 
> Ой сомневаюсь я в практической применимости.
См. выше. Если заблокирован один путь, мы идем по другому.

>  >> 10GE уже год как есть.
>  CS> Вероятно, это будет альтернативой. Оно слишком недавно появилось, чтобы
>  CS> получить широкое распространение. Хотя опять-таки надо смотреть на
>  CS> параметры и цены.
> xEthernet -- это майнстрим. Его будет много и дешево.
Когда будет - будет другая ситуация. Сейчас его мало, и я не знаю, что с 
ценами.

Слав, ты пойми, это не нужно в обычных сетях. Это нужно именно в 
числодробилках, причем не на всех задачах. А там - время счета 
уменьшается в разы при переходе от гигабитаного эзернета к тому же 
InfiniBand. А это в данном случае и есть критерий истины.

-- 
Константин Стефанов
--- 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 639 715 758 830 937 1057 1523 1604 1630 1922
SEEN-BY: 5020/2020 2142 2238 2450 2590 4441 5021/29 5022/128 5025/3 750
SEEN-BY: 5026/45 5027/16 5029/32 5030/49 115 473 500 556 966 1063 1900 5031/70
SEEN-BY: 5031/72 5034/13 5035/3 38 5036/1 34 5042/13 5049/1 50 97 5051/15
SEEN-BY: 5054/1 4 8 9 28 35 36 37 63 66 67 70 75 81 84 85 5055/95 5057/1
SEEN-BY: 5060/88 5061/15 5062/1 10 5063/3 5066/18 5067/2 5069/7 5070/1222
SEEN-BY: 5074/9 5075/5 35 5079/23 5080/80 1003 5081/2 5082/6 5083/21 5085/13
SEEN-BY: 5090/108 5095/20 5096/18 6000/12 254 6001/3 10

PATH: 5020/400 4441 545 5054/1 37