Linux and FreeBSD

From

Slawa Olhovchenkov (2:5030/500)

To

Constantin Stefanov (2:5054/37.63)

Date

2005-05-30T16:49:42Z

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> Система не самая лучшая (свитч  не фонтан, да и глюк в матери
 >>  CS> мешает), поэтому получается больше 5 мкс. 4 мкс, по утверждению
 >>  CS> разработчика, достигается на PCI Express. Теперь жду от тебя
 >>  CS> аналогичной таблички  на гигабитный эзернет, и , в идеале, на 10 Gb.
 >> Я не опущусь до такого позора.
 CS> А почему, собственно? Прогнать тест и запостить результаты - сложно?

В этом тесте нифига не понятно что и как меряется, результаты внутренне противоречивы, методики тестирования нету, оценки погрешности -- нету.

 >> Ну щаз. Начинай лапшу с ушей сматывать -- как это будет без блокировок,
 >> если одновременно две станции захотят передавать сообщение на третью?
 CS> Две на одну - с блокировкой. Но если ты все станции на свитче разобьешь
 CS> на пары, то каждая пара может друг с другом обмениваться с той же
 CS> скоростью, как если бы она была на свитче одна. Покажи мне Ethernet
 CS> свитч с такими характеристиками.

Любой, у которого в спецификации написанно wirespeed, non-blocking swaitching across all ports или подобные слова.
Ну или у которого производительность указывается как sum_allports(speed/64B).
А это DLink, 3com, Cisco. И многие другие.

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

Еще раз -- средняя меньше у store-and-forward. У тебя меньше минимальная, на коротких пакетах.

 CS> Плюс см. ниже про разделение типа портов на
 CS> уровне карты. Если затык одному адресату - мы пока другому кинем
 CS> сообщение.



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

Тут не PCI, тут IP с [G]Ethernet тебе подлянку сделают.
Но ему можно дать очередь пакетов на отправку. Т.е. можно сказать отослать 100 пакетов, каждый по 9000 байт.

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

Я не уверен что это реально применимо. Не по соображениям секурности, а по возможности все это проинтегрировать друг с другом и синхронизировать доступ к данным. Могу ошибаться.

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

ОК, с прямым углом перепутал, там столько КБ, а не МБ.

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

Это были прямые эксперементы на современном оборудовании? Не на железяках 1996 года (все что я видел уши имели оттуда)?
Если так -- буду знать на будущее.

... Среди немыслимых побед цивилизации мы одиноки, как карась в канализации.
--- 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