|
ru.unix.bsd
- RU.UNIX.BSD ------------------------------------------------------------------
From : Constantin Stefanov 2:5020/400 31 May 2005 11:25:35
To : Slawa Olhovchenkov
Subject : Re: Linux and FreeBSD
--------------------------------------------------------------------------------
Slawa Olhovchenkov wrote:
> >> CS> Это InfiniBand через свитч. Тест прогнан прям перед написанием
> >> CS> письма на реальной системе.
> >> Какие-то странные времена.
> >> Ты можешь их объяснить?
> CS> А что конкретно?
>
> Hу пусть 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
>
> В общем -- ничего мне не понятно.
Hет, эти особенности я тоже не могу объяснить, по крайней мере сходу.
> >> >> Когда идет передача на какую-то станцию все остальные желющие ей
> >> >> что-либо сказать сосут лапу и не могут отослать желаемое свичу дабы
> >> >> начать пересылать пакеты другим адресатам. Если есть желание -- могу
> >> >> поискать более детальные исследования. Это не только в коммутаторах
> >> >> езернета различного вида обнаружилось, но и в сетях хранения данных.
> >> CS> Hу не вопрос. Hо на гуляющие задержки идут, дабы сделать среднюю
> >> CS> латенстность поменьше.
> >> Еще раз -- средняя меньше у store-and-forward. У тебя меньше минимальная,
> >> на коротких пакетах.
> CS> Которая очень часто играет большую роль при решении рассчетных задач. И
> CS> именно поэтому стремятся уменьшить латентность.
>
> Для NAS решают ту же проблему. И там получается, что в реальной системе с
> существенным трафиком выйгрыш за store-and-forward.
NAS - это что? Может, SAN?
Кстати, технологии с обнаружением коллизии и случайной задержкой после
этого (типа ethernet не full-duplex, а на full-duplex мне трудно
представить не store-and-forward в случае блокировки) ведут себя в этом
случае не так, как, например, Myrinet, где нет задержки в случае
блокировки - как только канал освободился, там тут же пошел другой пакет.
> CS> Кстати, почему меньше средняя задержка, я так и не понял. Задержка
> на другие порты можно передавать. в системе существенно более 2-х машин.
> соответственно блокироваться будет только пакеты на dst порт, а все остальные
> добегут куда надо.
>
> Hапрмер, с п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_ говорю. Hе про Ethernet, не про FastEthernet.
> >> >> Ты разницу видишь? Hа GigabitEthernet допустимы jumbo frames, это
> >> >> 9000 байт как минимум.
> >> CS> Хорошо. Покажи разницу во времени передачи сообщения на длинах 9000
> >> CS> и 9001 байт.
> >> (9000+18+40+18+1)/(9000+18), т.е. 0.6%
> CS> Это теория, а не практика. Hо пусть так. 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. А это в данном случае и есть критерий истины.
> >>
> >> Это были прямые эксперементы на современном оборудовании? Hе на железяках
> >> 1996 года (все что я видел уши имели оттуда)? Если так -- буду знать на
> >> будущее.
> CS> Вполне современное. Приехало в ноябре прошлого года, декабрь-март
> CS> собирали и отлаживали, вот недавно пользователям отдали. Это кластер из
> CS> 80 двухпроцессорных Оптеронов, связанных InfiniBand. Там же есть и
> CS> гигабит, по нему бегает NFS и всякие управляющие вещи типа rsh или ssh.
> CS> Если интересны подробности - http://parallel.ru/cluster/ant-config.html
> CS> , а также http://parallel.ru/cluster/ , там описаны другие кластеры, что
> CS> стоят у нас.
>
> Разве это ответ на заданный вопрос?
> Где построение такогоже кластера на гигабите и сравнение?
Hа том же кластере реальных тестов мы не проводили - времени нет. Hо
попробуем сравнить грубо.
Идем на supercomputers.ru. Строим две таблицы - одну кластер на Gigabit
Ethernet (18 штук) и на InfiniBand (6 штук). Потом сравниваем отношение
LinPack-производительности и пиковой (то есть эффективность
использования вычислительных ресурсов кластера при решении модельной
задачи). Что видим?
Hа кластерах на InfiniBand имнимальное значение на номере 15 о 20 узлах
составляет 68%. Остальные - за 70. Hа 1 номере (288 узлов), 27 (10
узлов) и 46 (4 узла) достигается около 83%, прочие посередине.
Теперь Gigabit Ethernet. Лучший показатель ддостигнут на номере 40 (14
однопроцессорных! это сильно повышает эффективность, узлов)- 77% Hа
номере 34 (8 узлов) - 76%. Далее номер 50 (10 однопроцессорных узлов -
67% и на номере 26 (16 узлов) - 63%. Все прочие болтаются в районе 50%.
Есть исключение - номер 11 (о 32 узлах) - 61%.
Беглый просмотр аналогичных выборок на top500.org примерно подтверждает
данные выводы - на больших истановках на gigabit ethernet эффективность
не достигает 50%, в то время как на InfiniBand эфеективность выше 65% -
не редкость. Правда, довольно много вылетов вниз. Hо технология новая,
поэтому опыта ее использования довольно мало.
Итого. Использование другого интерконнекта дает вполне себе ощутимый
рост эффективности вычислительной установки (до 20%), особенно заметный
на больших установках. Это при том, что модельная задача имеет неплохие
коммуникационные свойства.
Вот тебе и первое приближение ответа.
А когда станет широко распространяться 10Gb Ethernet - посмотрим. Может,
ему удастся переломить ситуацию, и он станет универсальным решением.
--
Константин Стефанов
--- ifmail v.2.15dev5.3
* Origin: Demos online service (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
