InfiniBand свичи

Общий ликбез (наверно многое для вас уже известно) http://www.mka.ru/?p=44434

>В частности, интересует сравнение InfiniScale II с InfiniScale III.

InfiniScale II: http://mellanox.com/products/infiniscale_switch_silicon.php

InfiniScale III: http://mellanox.com/products/switch_silicon.php

Кстати а разве второй еще где то продаётся ? Уже повсеместно третий идёт и уже четвёртый скоро будет доступен http://mellanox.com/products/is4_arch.php

Спасибо, конечно... Но это все -- маркетоидный бред!

У меня реальная проблема -- что купить! И нет уже времени раскрутить фирмачей на бенчмарки.... :(

>Но это все -- маркетоидный бред! В смысле ? У них всё различие это суммарная пропускная способность. (по разному сгруппировая)

>У меня реальная проблема -- что купить! И нет уже времени раскрутить фирмачей на бенчмарки.... :(

Они внутри все одинаковые если имеется виду не сборщика а производителя чипов (если мы обсуждаем только Mellanox). Сейчас в основном используется 4x DDR , исходя из числа портов и выбирайте.

PS: Берите на III, не ошибётесь (10 гигабит в каждую сторону в группе из 24 штук 4x DDR на один чип)

PPS: У меня к примеру OEM-ный Flextronics на InfiniScale III на 24 порта

Для SVU домашний свитчик присматриваете? ;)

>Для SVU домашний свитчик присматриваете? ;)

Ему дома надо 480Gb/s за 5 килобаксов ? У него кстати и вентиль унутри нехило шумит так что я бы домой такой брать бы не стал ;)

> У него кстати и вентиль унутри нехило шумит так что я бы домой такой брать бы не стал ;)

Понятное дело, что шумный. Я бы тоже шумел, если бы на частоте 2.5ГГц работал :)

> я бы домой такой брать бы не стал ;)

:-)

Мне шум совершенно не актуален -- интересует стойка из 25 нодов, которая будет стоять в холодной комнате. Рядом стойка с 30 очень тонкими оптеронами, которые свистят, как соловей-разбойник, еще рядом пара Альтиксов, жужжащих басом... Кричать приходится!

Ну, собственно, вопрос возник после того, как я разобрался с карточками -- оказалось, разница в latency между Mellanox ConnectX и Mellanox InfiniHost III -- ровно в 2 раза, а аппликуха, ради которой кластер покупается, очень к latency чувствительна. Вот я и подумал -- а как свичи себя ведут? Не получится ли так, что, покупая в 2 раза более дорогой HCA, мы все эти деньги бездарно сольем в медленном свиче? Он-то один (ну, два), его цена совершенно не критична!

>Мне шум совершенно не актуален -- интересует стойка из 25 нодов

Если выкинуть одну ноду то любой свитч на 24 порта с InfiniScale III

Обычно свитчи бывают на 8, 24 и 144 порта. Несколько свитчей усложняют топологию и вообще говоря ухудшают латентность. Ну или брать пару (на вырост).

PS: У меня два блейда по 10 лезвий (20 нод) воткнуты в 24 портовый свитч "звездой" короткими (0.5 м) кабелями. Выглядит весьма компактно и красиво в 36U стойке (вместе с парой мегаUPS-ов на 10 КВт) ... но шумит оно конечно не по деЦки ;)

> Если выкинуть одну ноду то любой свитч на 24 порта с InfiniScale III

Ну, мы рассматриваем только звезду на 24, остальные (если будут -- теоретически до 28 нод можем по финансам потянуть) обойдуться без ИБ. Но, возможно, придется еще файлуху поверх ИБ пускать, то есть, еще один свич.

Кстати, я даже не знаю, вообще, можно ли двухпортовые карточки (конкретно Mellanox ConnectX) для этого приспособить?

>Кстати, я даже не знаю, вообще, можно ли двухпортовые карточки (конкретно Mellanox ConnectX) для этого приспособить?

Я бы поставил 2 отдельных (если есть такая возможность по количеству свободных PCI-E и габаритам). Они ведь на одной шине будут висеть. Двухпортовки могут разруливаться кстати за счёт собственной памяти на плате (128-256Мб) то есть если речь идёт о низколатентных обменах то тормоза могут быть запросто. Ну и еще двухпортовка длиннее значительно однопортового адаптера. У меня кстати именно из за этого стоят короткие однопортовки. В мой суперкомпактный кластер двухпортовки просто по габаритам не влезли (хотя там и так всё не очень стандартное по размерам)

> Я бы поставил 2 отдельных (если есть такая возможность по количеству свободных PCI-E и габаритам)

Такая возможность есть. Но -- цена!

Мне нужна низкая латентность, то есть, из Mellanox устроит только ConnectX, а он дорогой. Лишняя карточка означает минус пару нод!

В принципе, только Сантехники настаивают на распределенной файлухе, есть и другие предложения. Локальный RAID на каждой ноде с приличной редундантностью по терабайтам стОит примерно так же. А если для центрального файлсервера еще придется карточки по 500 ЕВР закупать на каждую ноду, то локальный редундантный сторадж однозначно дешевле будет...

>Такая возможность есть. Но -- цена!

Насколько я помню около 800-1000 вечнозелёных (если брать отдельно, и это с памятью на борту, MemFree подешевле), оно по любому одно из самых дорогих частей ноды. Кстати аппликуха сторонняя или своя самописная ?

Если самописная можно просто развязать обмены по MPI и дисковый I/O на уровне приложения. Ну и потом кто мешает для файлушки взять более дешёвые карточки, даже не обязательно DDR а скажем SDR Какой нибудь InfiniHost III Lx SDR HCA но это по любому не меньше 400-600 баков

>В принципе, только Сантехники настаивают на распределенной файлухе, есть и другие предложения. Локальный RAID на каждой ноде с приличной редундантностью по терабайтам стОит примерно так же. А если для центрального файлсервера еще придется карточки по 500 ЕВР закупать на каждую ноду, то локальный редундантный сторадж однозначно дешевле будет...

А какой смысл в локальных рейдах ? Просто быстрое хранилище для временных файлов ?

> Насколько я помню около 800-1000 вечнозелёных

Ну да, около того. Чуть дешевле, поскольку все в комплекте -- мы ж не сами кластер собираем, покупаем вместе с техподдержкой.

> Если самописная можно просто развязать обмены по MPI и дисковый I/O на уровне приложения.

Не понял! Обмены по MPI и дисковый I/O на уровне приложения и так развязаны... Потом, никакая логическая развязка не увеличит ширину канала.

Да, аппликуха самодельная.

> А какой смысл в локальных рейдах ? Просто быстрое хранилище для временных файлов ?

Да. Аппликуха имеет свою систему свопа и рассчитана на постоянные последовательные чтение/запись большими буферами (кстати, оказалось, что SATA в таком режиме производительнее SCSI).

Оказалось, наша аппликуха на ксеоновых машинках неожиданно сильно чувствительна к скорости диска. Разница между одним диском и страйпнутым на 4 персоны райдом составила от 10% (для последовательного режима) до 60% (когда параллелимся по 8 рабочих на ноду). На Оптеронах такой сильной зависимости не наблюдается! Чудеса южного моста? -- Все равно не понимаю, почему райд помогает...

>Не понял! Обмены по MPI и дисковый I/O на уровне приложения и так развязаны... Потом, никакая логическая развязка не увеличит ширину канала.

Речь шла про то чтобы I/O сетевой файловой системы не мешали MPI обменам и не шли _одновременно_ (2-х портовка сидит на одной шине хоть и окромной пропускной способности) Если ноды сконфигурированы под эксклюзивное использование (приложение захватывает ноду целиком) то это условие выполняется - Просто бери 2-х портовку и всё.

>Аппликуха имеет свою систему свопа и рассчитана на постоянные последовательные чтение/запись большими буферами (кстати, оказалось, что SATA в таком режиме производительнее SCSI).

У меня похожая схема только нету больших чтений (только в самом начале если стартую с сохранённых на чекпоинте данных) а только запись (чекпойн задачи каждые 10-20 минут нескольких десятков Гб в общее хранилище на PVFS2 ) и тоже стоят SATA а не SCSI

>Чудеса южного моста? -- Все равно не понимаю, почему райд помогает...

Увеличение суммарных внутренних буферов в 4 раза ?

> Речь шла про то чтобы I/O сетевой файловой системы не мешали MPI обменам и не шли _одновременно_ (2-х портовка сидит на одной шине хоть и окромной пропускной способности) Если ноды сконфигурированы под эксклюзивное использование (приложение захватывает ноду целиком) то это условие выполняется - Просто бери 2-х портовку и всё.

К сожалению, не так все просто.

Когда я что-то пишу на диск, оно в кыш сначала попадает, и только потом (в тяжелых случаях -- через минуты) его pdflush на диск сбрасывает.

Для того, чтобы это работало так, как ты говоришь, мне необходимо не давать I/O контроль ядру, самому написать I/O шедулер и состыковать его с драйвером. Воспользоваться "сырыми" девайсами или O_DIRECT флагом не получится, я пробовал: нужен хороший шедулер, правильно переупорядочивающий чтение/запись и грамотно взаимодействующий с драйвером, иначе все здорово тормозит.

>Когда я что-то пишу на диск, оно в кыш сначала попадает, и только потом (в тяжелых случаях -- через минуты) его pdflush на диск сбрасывает.

Я немного про другое а именно про _сетевой_ обмен _сетевой_ FS. Если данные пройдут через IB контроллер они уже не будут влиять на латентность MPI. Кстати я не понял как спасёт производительность низколатентный IB котроллер (у которого латентность 1.6 usec в пинг-понге) если по твоим словам она упирается в скорость I/O дисков. Там времена на 2 порядка различаются.

> Я немного про другое а именно про _сетевой_ обмен _сетевой_ FS. Если данные пройдут через IB контроллер они уже не будут влиять на латентность MPI.

Все равно не понял.

Допустим, я делаю MPI вызов, и в этот момент он перебивается (просто слайс исчерпался) ядром по причине того, что pdflush послал буфер дисковой сетевухе. Наверное, по причине DMA ядро сразу вернется и начнет посылать данные для MPI, но контроллер-то занят, он "дисковый" буфер читает. Я не знаю деталей; конечно, теоретически это можно разрулить, не уменьшая латентности, но все равно оба буфера будут пересылаться по одному каналу одновременно (в смысле, поделят его ширину). Теоретически, могут помочь неблокируюшие MPI вызовы, но на практике они не всега возможны, во-первых, а во-вторых они существенно менее эффективны.

> Кстати я не понял как спасёт производительность низколатентный IB котроллер (у которого латентность 1.6 usec в пинг-понге) если по твоим словам она упирается в скорость I/O дисков

Нет, скорость дискового I/O -- только один из критических параметров. К сожалению, и латентность, и ширина MPI тоже влияют очень сильно, особенно при количестве рабочих более 10, а мы надеемся, что реально сможем работать с 24-32.

> 2-х портовка сидит на одной шине хоть и окромной пропускной способности

Кстати, еще один момент я не понимаю:

Двухпортовка мне обешает 20 гигабит/сек на каждый порт, т.е. в сумме 40 гигабит/сек или 5 гигабайт/сек. И сидит она на PCI-E x8, которая тянет только 2 гигабайта в секунду!

>Допустим, я делаю MPI вызов, и в этот момент он перебивается (просто слайс исчерпался) ядром по причине того, что pdflush послал буфер дисковой сетевухе. Наверное, по причине DMA ядро сразу вернется и начнет посылать данные для MPI, но контроллер-то занят, он "дисковый" буфер читает. Я не знаю деталей; конечно, теоретически это можно разрулить, не уменьшая латентности, но все равно оба буфера будут пересылаться по одному каналу одновременно (в смысле, поделят его ширину). Теоретически, могут помочь неблокируюшие MPI вызовы, но на практике они не всега возможны, во-первых, а во-вторых они существенно менее эффективны.

А зачем на счётных машинах собирать ядро с preempt ? ;)

Вообще то там действует принцип "кто первый, того и тапки". Ну и потом лишний раз сказать sync после I/O никто не запрещает. Кстати не знаю как в ваших задачах а на моих асинхронные вызовы _очень_ эффективны. Бывают случаи когда скорость с ними возрастает почти в 2 раза.

PS: В PCI-E 1x это 250 MB/s в _каждую_сторону_

>К сожалению, и латентность, и ширина MPI тоже влияют очень сильно, особенно при количестве рабочих более 10, а мы надеемся, что реально сможем работать с 24-32.

10 это воркеров или нод ?

Я вот сейчас гоняю очень неудобную эволюционную задачку (маленькая расчётная область, которая параллелится путём резки в виде 1-D domain decomposition). Всё это хозяйство выходит на полку на 24 воркерах (6 нод, в каждой по паре 2-х ядерников) а потом на этой полке и остаётся аж до 40 воркеров.

> А зачем на счётных машинах собирать ядро с preempt ? ;)

Чур меня! Я говорил про потерю слайса при MPI вызове ДО входа в ядро!

Потом, я верю, что латентность таким образом не шибко портится, но ширина-то все равно делится!

И еще -- мне слабо верится, что существующие реализации MPI имеют шедулеры, учитывающие активность разделяющих с ними IB траффик файлушных шедулеров. Кстати, на след. неделе, возможно, смогу это проверить: нам Сантехники ссудили "на поиграться" их файлсервер, 4 IB карточки и свич. Правда, карточки однопортовые, так что нужно будет хорошенько подумать модель, как тестировать.

> Кстати не знаю как в ваших задачах а на моих асинхронные вызовы _очень_ эффективны.

Там, где они теоретически возможны (по алгоритму), они, конечно, могут быть весьма эффективны. Но они не везде возможны и не всегда эффективны.

> В PCI-E 1x это 250 MB/s в _каждую_сторону_

Ну, согласно спецификации IB, как я понимаю, 4x DDR IB и дает: 2.5 Гбит/с * 4 * 2 = 20 Гбит/с в каждом направлении! A PCI-E x8 = PCI-E 1x * 8 = 2 GB/s в каждом направлении...

> 10 это воркеров или нод ?

Воркеров.

У нас полка сильно зависит от железа. На Итаниках под вторым КвадриксНетом до 60 еще полки нет, а на старых Ксеонах под Езернетом на 8 наступает, да и наклон смехотворный, больше 2.5 спидапа не получается...

По предварительным оценкам, основанным на бенчмарках, сделанных в разных фирмах, на Ксеонах (Клевертаунах) под IB будем иметь разумный наклон до 24 и полную полку в районе 60. А вообще, продакшн джоб в основном по 8 рабочих в основном гоняем, поэтому восьмикорковые ноды нужны -- для SMP у нас есть версия без MPI, она пошустрее чуть.

Кстати, только сейчас сообразил, что у меня одна карточка на 8 воркеров, а ты про ноду говорил... То есть мы с тобой, похоже, просто не понимали друг друга в рассуждениях про разруливание MPI и сетевой файлухи :).

> Кстати, только сейчас сообразил, что у меня одна карточка на 8 воркеров, а ты про ноду говорил..

А у меня одна на 4 но суть не в этом. У меня обмены идут с I/O не в параллель. Сначала 10-20 минут обменов (параллельная часть) а толко потом I/O (последовательная часть). Алгоритм параллельно-последовательный.

Ну и потом через карточку _большими_данными_ обмениваются 2 "крайних" воркера (остальные обмениваются внутри ноды) ну и всякой мелочью в bcast-е (типа локальных невязок и рассчитаным по локальным данным следующим шагом по времени, по алгоритму из этой кучи выбираются крайние и снова рассылаются на узлы). Если расчётная облась большая (ну например минимальный кусок 200-500Мб на один воркер) то это всё почти линейно масштабируется и на 80 воркеров (20 узлов) а если эти куски меньше на порядок то полка наступает на 20 воркерах. В текущей задаче например интенсивность обменов порядка 130 в секунду (размер пересылаемых данных порядка 6-7 кб в одном куске + мелочь в несколько байт bcast-ами)

Кстати нашёл обзор с бенчмаркамиhttp://wwwcs.uni-paderborn.de/pc2/about-us/staff/jens-simons-pages/benchmarki...

У меня по бенчмаркам были примерно такие же результаты

> У меня обмены идут с I/O не в параллель.

У меня, к сожалению, в параллель. Как я описывал, своя система подкачки, никуда не денешься...

Я понял твою идею про разруливание.

Слушай, я нашел твой мэйл, мы ж с тобой не так давно списАлись... Короче: если твой мэйл на mail.ru еще валидный, я туда дальше отвечу. Тут, все равно, никому уже не интересно, а там я хоть смогу на свои статьи ссылаться.

>Короче: если твой мэйл на mail.ru еще валидный, я туда дальше отвечу. Тут, все равно, никому уже не интересно, а там я хоть смогу на свои статьи ссылаться.

Должен быть валидным. Пиши.