Re: Linux and FreeBSD
- From
- Constantin Stefanov (2:5020/400)
- To
- Slawa Olhovchenkov (2:5054/37.63)
- Date
- 2005-05-31T11:25:34Z
- Area
- RU.UNIX.BSD
From: Constantin Stefanov <cstef@mail.ru>
Slawa Olhovchenkov wrote:
> >> 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.
NAS - это что? Может, SAN?
Кстати, технологии с обнаружением коллизии и случайной задержкой после
этого (типа ethernet не full-duplex, а на full-duplex мне трудно
представить не store-and-forward в случае блокировки) ведут себя в этом
случае не так, как, например, Myrinet, где нет задержки в случае
блокировки - как только канал освободился, там тут же пошел другой пакет.
> 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> Как такое учесть при написании программы высокого уровня?
> А это не учитывается?
А такие скачки просто нельзя учесть. Ведь прикладную программу пишут на
уровне выше ethernet - обычно MPI. Там еще оверхеда накрутят (сначала
сам MPI, потом TCP, IP, и только потом ethernet). И какой будет размер
этих заголовков, зависит как минимум от реализации MPI, а она не
единственная. Вот и получится, что такие провалы учесть просто нельзя.
> 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> стоят у нас.
>
> Разве это ответ на заданный вопрос?
> Где построение такогоже кластера на гигабите и сравнение?
На том же кластере реальных тестов мы не проводили - времени нет. Но
попробуем сравнить грубо.
Идем на supercomputers.ru. Строим две таблицы - одну кластер на Gigabit
Ethernet (18 штук) и на InfiniBand (6 штук). Потом сравниваем отношение
LinPack-производительности и пиковой (то есть эффективность
использования вычислительных ресурсов кластера при решении модельной
задачи). Что видим?
На кластерах на InfiniBand имнимальное значение на номере 15 о 20 узлах
составляет 68%. Остальные - за 70. На 1 номере (288 узлов), 27 (10
узлов) и 46 (4 узла) достигается около 83%, прочие посередине.
Теперь Gigabit Ethernet. Лучший показатель ддостигнут на номере 40 (14
однопроцессорных! это сильно повышает эффективность, узлов)- 77% На
номере 34 (8 узлов) - 76%. Далее номер 50 (10 однопроцессорных узлов -
67% и на номере 26 (16 узлов) - 63%. Все прочие болтаются в районе 50%.
Есть исключение - номер 11 (о 32 узлах) - 61%.
Беглый просмотр аналогичных выборок на top500.org примерно подтверждает
данные выводы - на больших истановках на gigabit ethernet эффективность
не достигает 50%, в то время как на InfiniBand эфеективность выше 65% -
не редкость. Правда, довольно много вылетов вниз. Но технология новая,
поэтому опыта ее использования довольно мало.
Итого. Использование другого интерконнекта дает вполне себе ощутимый
рост эффективности вычислительной установки (до 20%), особенно заметный
на больших установках. Это при том, что модельная задача имеет неплохие
коммуникационные свойства.
Вот тебе и первое приближение ответа.
А когда станет широко распространяться 10Gb Ethernet - посмотрим. Может,
ему удастся переломить ситуацию, и он станет универсальным решением.
--
Константин Стефанов
--- 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 715 758 830 937 1057 1523 1604 1630 1922 2020
SEEN-BY: 5020/2142 2238 2450 2590 4441 5021/29 5022/128 5025/3 750 5026/45
SEEN-BY: 5027/16 5029/32 5030/49 115 473 500 556 966 1063 1900 5031/70 72
SEEN-BY: 5034/13 5035/3 38 5036/1 34 5042/13 5049/1 50 97 5051/15 5054/1 4 8 9
SEEN-BY: 5054/28 35 36 37 63 66 67 70 75 81 84 85 5055/95 5057/1 5060/88
SEEN-BY: 5061/15 120 5062/1 10 5063/3 5066/18 5067/2 5069/7 5070/1222 5074/9
SEEN-BY: 5075/5 35 5079/23 5080/80 1003 5081/2 5082/6 5083/21 5085/13 5090/108
SEEN-BY: 5095/20 5096/18 6000/12 254 6001/3 10
PATH: 5020/400 4441 545 5054/1 37