Linux and FreeBSD

From

Slawa Olhovchenkov (2:5030/500)

To

Constantin Stefanov (2:5054/37.63)

Date

2005-05-30T18:57:08Z

Area

RU.UNIX.BSD

Hello Constantin!

30 May 05, Constantin Stefanov writes to Slawa Olhovchenkov:

 >>  >>  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мкс, у тебя что там, машина
 >>  >> времени?
 >>  CS> Скорость, как уже было сказано, 10 Гбит/сек.
 >> Извини, но это у тебя нигде не было сказанно.
 >>
 >>  CS> Это InfiniBand через свитч. Тест прогнан прям перед написанием
 >>  CS> письма на реальной системе.
 >> Какие-то странные времена.
 >> Ты можешь их объяснить?
 CS> А что конкретно?

Ну пусть 5.7мкс -- задержка старта и в свиче.
Тогда время передачи должно быть линейно и апроксимироваться (в мкс) 5+N*8/10^4.
Т.е. 1500 -- 6.9мкс, а у тебя 10.27.
10000 -- 13.7, а у тебя 19.44
100000 -- 85.7, а у тебя 127.48.

ОК, возможно не 10Г?
Пробуем сапроксимировать: для 100000 6.56G, для 5000 -- 5.28, для 1500 -- 2.6

В общем -- ничего мне не понятно.

 >>  >> Когда идет передача на какую-то станцию все остальные желющие ей
 >>  >> что-либо сказать сосут лапу и не могут отослать желаемое свичу дабы
 >>  >> начать пересылать пакеты другим адресатам. Если есть желание -- могу
 >>  >> поискать более детальные исследования. Это не только в коммутаторах
 >>  >> езернета различного вида обнаружилось, но и в сетях хранения данных.
 >>  CS> Ну не вопрос. Но на гуляющие задержки идут, дабы сделать среднюю
 >>  CS> латенстность поменьше.
 >> Еще раз -- средняя меньше у store-and-forward. У тебя меньше минимальная,
 >> на коротких пакетах.
 CS> Которая очень часто играет большую роль при решении рассчетных задач. И
 CS> именно поэтому стремятся уменьшить латентность.

Для NAS решают ту же проблему. И там получается, что в реальной системе с существенным трафиком выйгрыш за store-and-forward.

 CS> Кстати, почему меньше средняя задержка, я так и не понял. Задержка
 CS> считается не до момента конца передачи, а от начала передачи до конца
 CS> приема (именно это играет роль). И как ее может уменьшить
 CS> store-and-forward в случае блокировки, я не понимаю. Какая разница, где
 CS> пакет будет висеть - где-то по пути, или в свитче. Все равно пока
 CS> предыдущий не пройдет, этот не поедет.

на другие порты можно передавать. в системе существенно более 2-х машин. соответственно блокироваться будет только пакеты на dst порт, а все остальные добегут куда надо.

Напрмер, с п1 и п2 хотят передать пакеты на порты 3 3 4 5 6 и 3 3 7 8 9 соответственно. В системе без буферизации:

п1-3
п2-3
п1-3
п2-3
п1-4 п2-7
п1-5 п2-8
п1-6 п2-9

в системе с буферизацией:

п1-3 п2-3
п1-3 п2-3 3:п2
п1-4 п2-7 3:п1
п1-5 п2-8 3:п2
п1-6 п2-9


 >>  >>  CS> Теперь насчет драйверов. Во-первых, в этих технологиях нет
 >>  >>  CS> такого маленького ограничения на макс. размер пакета. Я не знаю,
 >>  >>  CS> где он какой, но даже если инкрементировать размер сообщения по
 >>  >>  CS> единичке, то скачка, как на ethernet от 1500 к 1501 ты не
 >>  >>  CS> получишь, т.е. меньше прерывания.
 >>  >>
 >>  >> Я про _GigabitEthernet_ говорю. Не про Ethernet, не про FastEthernet.
 >>  >> Ты разницу видишь? На GigabitEthernet допустимы jumbo frames, это
 >>  >> 9000 байт как минимум.
 >>  CS> Хорошо. Покажи разницу во времени передачи сообщения на длинах 9000
 >>  CS> и 9001 байт.
 >> (9000+18+40+18+1)/(9000+18), т.е. 0.6%
 CS> Это теория, а не практика. Но пусть так. 1/9001 - это 0.011%. Вот и
 CS> получается, что увеличение размера пакета на 0.011% приводит к
 CS> увеличению времени передачи на 0.6%. Т.е. относительная разница - почти
 CS> в 60 раз. Таким образом, появляются дипазоны размеров сообщений, где
 CS> реальная скорость передачи падает (условная 1 на 9000 и 0.94 на 9001).
 CS> Как такое учесть при написании программы высокого уровня?

А это не учитывается?

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

это дать очередь. дается единоразовая пачка команд.

 CS> Опять же упираемся в максимальный размер пакета. В
 CS> ethernet на пакеты все режет софт. А тут - карта. Сколько прерываний
 CS> экономим?

нисколько. см. выше.
более того, интеля и сами резать могут, вроде как.

 >>  CS> Слав, ты пойми, это не нужно в обычных сетях. Это нужно именно в
 >>  CS> числодробилках, причем не на всех задачах. А там - время счета
 >>  CS> уменьшается в разы при переходе от гигабитаного эзернета к тому же
 >>  CS> InfiniBand. А это в данном случае и есть критерий истины.
 >>
 >> Это были прямые эксперементы на современном оборудовании? Не на железяках
 >> 1996 года (все что я видел уши имели оттуда)? Если так -- буду знать на
 >> будущее.
 CS> Вполне современное. Приехало в ноябре прошлого года, декабрь-март
 CS> собирали и отлаживали, вот недавно пользователям отдали. Это кластер из
 CS> 80 двухпроцессорных Оптеронов, связанных InfiniBand. Там же есть и
 CS> гигабит, по нему бегает NFS и всякие управляющие вещи типа rsh или ssh.
 CS> Если интересны подробности - http://parallel.ru/cluster/ant-config.html
 CS> , а также http://parallel.ru/cluster/ , там описаны другие кластеры, что
 CS> стоят у нас.

Разве это ответ на заданный вопрос?
Где построение такогоже кластера на гигабите и сравнение?

... Нас Reboot, а мы кpепчаем
--- 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 639 715
SEEN-BY: 5020/758 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 5062/1 10 5063/3
SEEN-BY: 5067/2 5069/7 5070/1222 5079/23 5080/80 1003 5082/6 5083/21 5085/13
SEEN-BY: 5090/108 5095/20 5096/18 6000/12 254 6001/10

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