Re: Linux and FreeBSD
- From
- Constantin Stefanov (2:5020/400)
- To
- Slawa Olhovchenkov (2:5054/37.63)
- Date
- 2005-05-30T18:41:14Z
- 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мкс, у тебя что там, машина времени?
> 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. У тебя меньше минимальная, на
> коротких пакетах.
Которая очень часто играет большую роль при решении рассчетных задач. И
именно поэтому стремятся уменьшить латентность.
Кстати, почему меньше средняя задержка, я так и не понял. Задержка
считается не до момента конца передачи, а от начала передачи до конца
приема (именно это играет роль). И как ее может уменьшить
store-and-forward в случае блокировки, я не понимаю. Какая разница, где
пакет будет висеть - где-то по пути, или в свитче. Все равно пока
предыдущий не пройдет, этот не поедет.
> >> 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%
Это теория, а не практика. Но пусть так. 1/9001 - это 0.011%. Вот и
получается, что увеличение размера пакета на 0.011% приводит к
увеличению времени передачи на 0.6%. Т.е. относительная разница - почти
в 60 раз. Таким образом, появляются дипазоны размеров сообщений, где
реальная скорость передачи падает (условная 1 на 9000 и 0.94 на 9001).
Как такое учесть при написании программы высокого уровня?
> >> CS> Во-вторых, на InfinBand релизована хитрая технология RDMA (Remote
> >> CS> DMA), которая позволяет дать карточке команду "отслать вот эту
> >> CS> область данных (ну или принять от того-то туда-то)", после чего весь
> >> CS> процесс произойдет без прерываний, т.е. опять имеем уменьшение
> >> CS> нагрузки.
> >>
> >> А теперь без булшита -- чем это круче тривиального busmaster в
> >> тривиальныйх интелях и броадкомах? И почему тебе после отсылки прерывание
> >> не нужно?
> CS> Нужно. Только ты сможешь сказать ителю "отошли мне вот отсюда 2 МБ"? Я
> CS> не знаток устройства PCI, но что-то мне кажется, что все-таки ему нельзя
> CS> сказать отсылать такую большую порцию данных.
>
> Тут не PCI, тут IP с [G]Ethernet тебе подлянку сделают.
> Но ему можно дать очередь пакетов на отправку. Т.е. можно сказать отослать 100
> пакетов, каждый по 9000 байт.
Дать очередь - это по одному дать указание, или все же одним командой
"отсюда 2 МБ"? Опять же упираемся в максимальный размер пакета. В
ethernet на пакеты все режет софт. А тут - карта. Сколько прерываний
экономим?
> CS> Кроме того, там можно настроить все это так, чтобы одна машина дает
> CS> команду своим драйверам "воон тому хосту можно лить мне в память что ему
> CS> надо". А тот уже дает команду драйверу, в какое место адресного
> CS> пространства удаленного процесса запихнуть данные. Это не очень секурно
> CS> вероятно, но там, где это применяется, другие подходы к безопасности, но
> CS> опять-таки позволяет сэкономить.
>
> Я не уверен что это реально применимо. Не по соображениям секурности, а по
> возможности все это проинтегрировать друг с другом и синхронизировать доступ к
> данным. Могу ошибаться.
Работает. Реально.
> CS> Слав, ты пойми, это не нужно в обычных сетях. Это нужно именно в
> CS> числодробилках, причем не на всех задачах. А там - время счета
> CS> уменьшается в разы при переходе от гигабитаного эзернета к тому же
> CS> InfiniBand. А это в данном случае и есть критерий истины.
>
> Это были прямые эксперементы на современном оборудовании? Не на железяках 1996
> года (все что я видел уши имели оттуда)?
> Если так -- буду знать на будущее.
Вполне современное. Приехало в ноябре прошлого года, декабрь-март
собирали и отлаживали, вот недавно пользователям отдали. Это кластер из
80 двухпроцессорных Оптеронов, связанных InfiniBand. Там же есть и
гигабит, по нему бегает NFS и всякие управляющие вещи типа rsh или ssh.
Если интересны подробности - http://parallel.ru/cluster/ant-config.html
, а также http://parallel.ru/cluster/ , там описаны другие кластеры, что
стоят у нас.
--
Константин Стефанов
--- 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