Fast Ethernet в кластерах Beowulf

Технология Fast Ethernet стала основой современных локальных сетей, а Fast Ethernet — стандартом, обеспечивающим интероперабельность оборудования, выпускаемого различными компаниями. При использовании медной кабельной проводки Категории 5 вся инфраструктура локальных сетей, удовлетворяющая спецификации 100BaseTX, получается достаточно дешевой, а формальная пиковая скорость (100 Мбит/с) выглядит приемлемой для большинства приложений.

Учитывая, что пропускная способность Fast Ethernet на порядки ниже, чем у межсоединений в современных суперкомпьютерах МРР-архитектуры, для организации эффективного распараллеливания в кластере поднятая тема весьма актуальна.

Эти свойства Fast Ethernet сделали ее самой массовой технологией и в более специфической области — в качестве коммуникационной инфраструктуры кластеров Beowulf. Относительно недавно на рынке появилось и оборудование Gigabit Ethernet, которое может работать с той же проводкой категории 5. Учитывая, что уже завершаются работы над стандартом 10-Gigabit Ethernet, можно сказать, что данное семейство является одним из самых перспективных коммуникационных решений при построении кластеров. (Некоторые альтернативные варианты связи узлов кластеров рассмотрены, например, в [1]).

Вообще говоря, если отказаться от требования применения в кластере коммутатора (или группы коммутаторов), то кластером — хотя и с определенной долей искусственности — можно было бы назвать любую соединенную сетью систему компьютеров. Такая система компьютеров может быть использована для распределенной пакетной обработки невзаимодействующих заданий, например, в рамках широко пропагандируемой ныне системы GRID, или используя конкретные разработки отдельных фирм, таких как eScience канадского консорциума Canarie и т.д.

Статья адресована в первую очередь специалистам, строящим кластеры на базе Fast Ethernet. В ней рассматриваются, в частности, вопросы измерения производительности на уровне стека протоколов TCP/IP и некоторые факторы, обуславливающие выбор сетевых плат и коммутаторов Fast Ethernet. (Поскольку с задачами построения и эксплуатации кластеров Beowulf все чаще работают не только профессиональные сетевые администраторы, но и представители других «компьютерных» профессий, мы решили сопроводить публикацию данных исследований описанием некоторых базовых понятий и механизмов коммутации в сетях Fast Ethernet. Кроме того, ряд тестов выходит за рамки «классических» кластеров Beowulf; в частности, в большинстве руководств по их построению прямо указывается на необходимость отказаться от автопереговоров. Однако без этого представление результатов проведенного исследования было бы неполным. — Прим. ред.)

Учитывая, что пропускная способность Fast Ethernet на порядки ниже, чем у межсоединений в современных суперкомпьютерах МРР-архитектуры, для организации эффективного распараллеливания в кластере поднятая тема весьма актуальна. Более того, с нашей точки зрения, она представляет интерес не только при построении кластеров, но и для администраторов сетей Fast Ethernet.

Мы будем изучать сетевые платы Fast Ethernet и коммутаторы, имеющие возможность автоматического переключения между режимами 10/100 Мбит/с и дуплекс/полудуплекс.

Коммутаторы Fast Ethernet

Задача коммутатора — обеспечить пропускную способность 100 Мбит/с одновременно для всех n/2 «соединений» между парами портов n-портового коммутатора. Теоретически так называемый неблокирующийся коммутатор должен это гарантировать, но на практике весьма часто идут на компромисс — как с целью удешевления, так и с целью максимального увеличения числа портов. В последнем случае при распараллеливании могут возникать конфликты на уровне Fast Ethernet, что снижает скорость обмена сообщениями и соответственно эффективность распараллеливания.

Для того чтобы удовлетворить сформулированному требованию к производительности, архитектура коммутатора должна обладать двумя непременными свойствами. Во-первых, его «общая шина» (backplane), через которую обмениваются данными порты, должна иметь достаточную пиковую пропускную способность — хотя бы 100*n Мбит/с (оценка получена в предположении, что каждая из n/2 пар портов Fast Ethernet работает в дуплексном режиме). Во-вторых, «центральный процессор» коммутатора должен успевать обрабатывать все поступающие MAC-кадры Fast Ethernet даже при наличии одновременно полностью нагруженных n/2 передачах данных. При этом первое требование является необходимым, но не достаточным, а второе может быть достаточным. (Реальная архитектура коммутатора обычно сложнее; она может не иметь «общей шины» и «центрального процессора». Здесь эти термины используются прежде всего из соображений наглядности.)

Увы, производители коммутаторов подчас вообще не приводят соответствующей информации или ограничиваются каким-либо одним параметром. Данные о производительности «центрального процессора», выражаемые числом передаваемых в секунду пакетов, оказываются обычно неполными или несопоставимыми, поскольку относятся к разным размерам пакетов (о чем идет речь, иногда вообще не указывается). Другая важная для построения кластеров характеристика производительности коммутаторов — задержка на порт; эта величина производителями также указывается редко. Грубо говоря, задержка — это время, необходимое для прохождения пакета минимального размера. Как и пропускная способность, задержка — один из основных показателей эффективности коммуникационной инфраструктуры кластера. В действительности, пользователя интересует задержка при распараллеливании на прикладном уровне — в решениях обмена сообщениями наподобие MPI/PVM; она важна, если узлы кластера обмениваются короткими сообщениями. Эта задержка включает в себя программный компонент (задержка, определяемая стеком протоколов TCP/IP, а также возможные накладные расходы, связанные с копированием передаваемых данных из буферов пользователя в буферы ядра операционной системы) и аппаратный компонент. В последний, кроме задержек на портах коммутаторов, входят и задержки на сетевых платах. При использовании в качестве узлов кластера стандартных ПК-серверов программная задержка достаточно велика, так что об аппаратной задержке обычно не беспокоятся. Однако имеются программные средства распараллеливания, позволяющие обходиться без стека TCP/IP, обмениваясь данными непосредственно между процессами пользователя. В этом случае аппаратная задержка становится существенным фактором. Для понижения задержек, вносимых коммутаторами, в них может применяться режим «коммутации на лету» (cut-through) [2]. Его суть состоит в том, что коммутатор не дожидается полного приема пакета. Как только через порт проходят заголовки пакета, содержащие данные о получателе пакета, этот пакет направляется на нужный «выходной» порт коммутатора. Противоположный режим — с буферизацией (store-and-forward). Применяются и различные модифицированные схемы cut-through. Опасным моментом при работе в режиме cut-through является то, что аппаратура может не успевать справляться с потоком данных. Некоторые коммутаторы будут при возникновении перегрузок отбрасывать пакеты, что, конечно, плохо для производительности. Более эффективный подход, позволяющий не терять пакеты, — это увеличение емкости буферов. В современных коммутаторах часто поддерживаются оба режима коммутации; при возникновении перегрузок может происходить переключение на режим store-and-forward. (Кстати, поддержание коммутатором стандарта управления потоками данных IEEE 802.3x — естественное требование со стороны кластеров Beowulf.) К сожалению, многопортовые коммутаторы Fast Ethernet (скажем, с n >= 24) нечасто поддерживают режим cut-through. Единственная известная автору независимая база данных результатов измерения производительности коммутаторов Fast Ethernet (по RFC1242 и RFC1944), как сообщил владелец базы данных, Скотт Бреднер из Гарвардского университета, уже два года как не пополняется, а сами результаты недоступны. Дополнительную информацию по вопросам производительности коммутаторов можно найти в [2]. Еще одна важная группа особенностей коммутаторов проявляется, когда портов коммутатора не хватает, т.е. при большом числе узлов в кластере. В этом случае необходимо соединение коммутаторов между собой, тогда узлы могут быть подсоединены к портам, скажем, двух связанных коммутаторов. Тогда канал связи между коммутаторами может стать узким местом из-за возможных обменов данными узлов, подсоединенных к разным коммутаторам: все такие обмены будут использовать общий канал связи между коммутаторами. Соответственно пропускная способность такого канала должна быть гораздо выше 100 Мбит/с (в идеале в m раз, где m — число портов каждого коммутатора, к которым подсоединены узлы).

Поэтому коммутаторы бессмысленно соединять посредством пары портов Fast Ethernet; возможно применение портов Gigabit Ethernet, если таковые поддерживаются коммутаторами.

Многие коммутаторы поддерживают также альтернативные варианты соединения.

Во-первых, это так называемый «транкинг», т.е. объединение нескольких каналов Fast Ethernet в один общий скоростной канал, соединяющий однотипные коммутаторы. Очевидным недостатком такого подхода является «потеря» части портов, задействованных в межсоединении коммутаторов.

Во-вторых, это объединение коммутаторов в стек. При этом число портов удваивается (если стек состоит из двух коммутаторов). Однако, как правило, полная пропускная способность «шины» объединенного коммутатора остается на уровне одиночного коммутатора («шины» как бы стыкуются друг с другом). Соответственно снижается пропускная способность в пересчете на порт.

Наконец, последнее, о чем хотелось бы упомянуть при анализе требований к коммутаторам, которые предполагается задействовать при построении кластеров, — это поддержка режима виртуальных локальных сетей (VLAN). Он оказывается полезен, если для связи между узлами кластера планируется использовать «связывание каналов» (channel bonding), т.е. объединение нескольких каналов Fast Ethernet. При этом каждый узел подсоединяется к коммутатору более чем одним каналом.

Чтобы достичь этого, узлы надо оснастить либо несколькими сетевыми платами, либо многопортовыми платами Fast Ethernet. Связывание каналов аналогично режиму транкинга при соединении коммутаторов. Применение связывания каналов в узлах под управлением ОС Linux позволяет организовать равномерное распределение нагрузки приема/передачи между соответствующими каналами. К связыванию каналов мы вернемся ниже.

Применение VLAN призвано помочь избежать «дублирования» во внутренних таблицах коммутаторов MAC-адресов многопортовых сетевых плат. Впрочем, есть сообщения, что и поддержка VLAN не всегда помогает.

Некоторая информация о рассмотренных выше характеристиках для коммутаторов с числом портов n = 24 (большее число портов встречается существенно реже) собрана в таблице 1. Мы не претендуем на полноту данных, а лишь приводим информацию, либо полученную непосредственно от производителей, либо найденную на их Web-сайтах.

Конечно, принимая решение о выборе коммутатора, необходимо учесть и другие их характеристики, в том числе цену. Хорошая продукция и стоит дороже. Так, отличные коммутаторы Cisco Catalyst (например, известная модель 5000, имеющая большее число портов и поддерживающая возможность связывания каналов) имеют более высокую цену, чем оборудование не столь «именитых» фирм.

Выбор сетевых плат — совсем, казалось бы, «копеечных» по сравнению со стоимостью узла — также весьма важен. Ему посвящен следующий раздел.

Платы Fast Ethernet

Есть еще один вопрос, который вроде бы не должен подниматься в принципе, — интероперабельность оборудования разных производителей. Коль скоро Fast Ethernet — стандарт, то и говорить, казалось бы, не о чем. Однако наше исследование показало, что при «переговорах» между коммутатором и сетевой платой о выборе режима работы, т.е. при автоматическом выборе режима работы — 10/100 Мбит/с и дуплекс/полудуплекс (напомним, что мы рассматриваем коммутаторы с автоконфигурируемыми портами) иногда возникают проблемы.

Далее мы будем рассматривать только однопортовые PCI-платы Fast Ethernet 100BaseTX для обычной 32-разрядной шины PCI/33 МГц. Именно такие платы обычно и используются. В кластерах Beowulf применяются в основном три вида подобных плат: 3Сom (типа 3C905B), Intel EtherExpress Pro 100 и особенно популярные в кластерах платы на базе микросхем Intel 21142/21143. (Популярность последних вызвана бытующим мнением об их высокой производительности, в то время как их цена по сравнению с конкурирующими предложениями обычно довольно невелика. Intel, приобретя в свое время у DEC права на производство таких микросхем, некоторое время выпускала собственные платы на их базе, но затем перешла на применение несовместимых с 2114х микросхем собственной разработки.)

Нами были протестированы все эти три вида сетевых плат, которые широко доступны на российском рынке. Но если с 3С905B и EtherExpress 100 (новая версия с собственной микросхемой i82559) все было однозначно, то на базе 2114х в мире производится не одна такая плата. Мы исследовали платы Kingston KNE100TX (более новые их версии используют другие микросхемы), а также представленные на российском рынке платы CN100TX от CNet. Обе последних разновидности плат используют новейшую, наиболее продвинутую версию микросхемы Intel — 21143.

Поскольку нас интересовало применение Fast Ethernet в кластерах Beowulf, в наших тестах в качестве узлов применялась наиболее массовая платформа — ПК под управлением Linux. В узлах были использованы популярные материнские платы ASUS P2B-F/P3B-F/P2B-D с отлично зарекомендовавшим себя набором микросхем i440BX, и процессоры Pentium II/400 МГц и кэшем второго уровня емкостью 512 Кбайт, работающем на половинной частоте процессора. Различиями в результатах измерений для разных типов материнских плат ASUS для наших целей можно пренебречь. В тестах применялся также 24-портовый коммутатор DES-3224 компании D-Link.

Что касается драйверов, то для всех плат, за исключением EtherExpress Pro 100, мы использовали версии, созданные Д. Беккером, основным разработчиком драйверов сетевых плат, применяемых в кластерах Beowulf. Эти драйверы стандартно поставляются в составе RedHat Linux (для плат 3Сom это 3с59x, а для плат на базе 21143 — tulip). Имеющиеся альтернативы — драйверы 3с905х и de4x5 cоответственно — нами детально не исследовались. Однако мы нашли, что смена версий драйвера tulip (этот драйвер развивается, пожалуй, наиболее быстро) не меняет общей картины. Для платы Intel применялся стандартный, имеющийся в дистрибутиве драйвер eepro100. Результаты до некоторой степени шокировали: несмотря на необходимые предосторожности (качественная проводка Категории 5, оптимизированные под Fast Ethernet разъемы RJ-45) только платы KNE100TX и EtherExpress Pro 100 смогли без проблем проводить автопереговоры с коммутатором, приводящие к установке полнодуплексного режима на скорости 100 Мбит/с.

Платы 3С905B, оказавшиеся в нашем распоряжении, с точки зрения используемой на плате электроники совершенно различны в зависимости от того, выпущены ли они в США или Ирландии, и соответственно ведут себя по-разному. Американские платы проводили автопереговоры корректно, а ирландские требовали «ручной» фиксации дуплексного режима 100 Мбит/с как на коммутаторе, так и в драйвере платы. С американскими платами мы столкнулись, однако, с проблемами при работе в режиме связывания каналов.

Платы CN100TX также потребовали «ручной» фиксации режима, а заставить их работать в паре на системной плате P3B-F в режиме связывания каналов не удалось. При этом вторая плата (всегда eth1) вообще не могла установить дуплексное соединение с коммутатором. Эти проблемы сохранялись и при использовании простого четырехпортового коммутатора 3Com OfficeConnect 400. Не удалось также установить полнодуплексного соединения при соединении напрямую без коммутатора (кросс-кабелем) двух узлов, оснащенных CN100TX.

Ситуация осложняется тем, что индикация не всегда верно отражает реальные результаты автопереговоров. Типичная ситуация: коммутатор «думает», что договорился с сетевой платой об установлении полнодуплексного режима, и отражает это соответствующим индикатором, а плата работает в полудуплексе (при этом соответствующий индикатор на ней может отсутствовать). Проблема проявляется в виде низкой пропускной способности соединения; часть пакетов теряется. Для плат на базе 21143 полезно при этом применять диагностическую утилиту tulip-diag.

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

Итак, несмотря на то, что Fast Ethernet является стандартом, на практике могут возникать определенные проблемы интероперабельности. Это та самая ситуация, когда может быть разумно прибегать к помощи системного интегратора — хотя очевидно, что отечественные организации, использующие кластеры Beowulf, часто не имеют на это достаточных финансовых средств (впрочем, найти интегратора с подобным опытом дело тоже, мягко говоря, непростое — Прим. ред.).

Тесты производительности

Как уже отмечалось, при сопоставлении сетевых плат мы в основном интересовались вопросами производительности (и, естественно, стоимости) на уровне стека протоколов TCP/IP, поверх которого обычно работают средства распараллеливания типа MPI.

Среди известных тестовых программ отметим на netpipe (www.sci.ameslab.gov/netpipe) и применявшуюся нами netperf (www.netperf.org). По нашему мнению, эти инструменты относительно (и незаслуженно) редко используются в практике отечественных сетевых администраторов, поэтому целесообразно предварить полученные результаты кратким описанием возможностей netperf.

Описание, строго говоря, относится к версии netperf 2.1pl3, хотя для отдельных измерений понадобилось использовать альфа-версию netperf 2.2, любезно предоставленную нам Риком Джонсом из подразделения HP Information Network Division, главным разработчиком этой программы.

В результате установки netperf образуется два исполняемых модуля — netserver и netperf, соответственно сервер и клиент. Сервер исполняется на одном узле, а клиент — на другом; общаются они через выделенный порт (по умолчанию 12865).

Основные параметры, указывающие характеристики теста, задаются при запуске netperf. Для удобства тестирования в пакет netperf включен набор управляющих сценариев. Запускать netserver можно либо «вручную», либо включив соответствующую строку в /etc/inetd.conf:

плюс, естественно, строку в /etc/services:

В общем, все очень нехитро.

Рассмотрим теперь некоторые параметры клиента netperf. В ключе -H задается имя хоста, на котором работает netserver. В ключе -t указывается имя теста. Тестируется производительность работы как c TCP (TCP_STREAM и TCP_RR), так и с UDP (UDP_STREAM и UDP_RR). Суффикс STREAM означает тест пропускной способности на большом потоке данных, а RR, расшифровывающийся как Request/Response, — на коротких пакетах. Соответственно при распараллеливании в модели обмена сообщениями данные тестов STREAM коррелируют с пропускной способностью, а тестов RR — с задержками при передаче сообщений.

Аналогичные пары тестов имеются для высокоскоростных типов соединений — Fore ATM и HiPPI. Имеется также специальный тест TCP_CRR, который целесообразно использовать для оценок производительности при работе с протоколом HTTP. Не будем останавливаться на других типах тестов, отметим лишь, что netperf содержит коды и для работы с IPv6.

Параметр -l задает время выполнения теста в секундах (по умолчанию 10). Параметр -I уровень,интервал — уровень доверительности измерения в процентах (95/99) и широту интервала доверительности (по умолчанию 10%). В параметре -i max,min указывается соответственно максимальное и минимальное число итераций для попыток достичь запрашиваемого уровня доверительности.

В тестах, приводимых в базе данных результатов измерений netperf (она включена в дистрибутив), обычно используются следующие установки:

что отвечает погрешности ?2,5% при уровне доверительности 99%. (Мы во всех своих тестах использовали именно эти ключи.)

Из других особенностей отметим возможность измерения уровня нагрузки на процессор, задаваемую ключами -с и -С (для процессоров клиента и сервера соответственно).

Параметры netperf, специфические для определенных тестов, задаются после ключа --. В числе таких параметров для тестов STREAM можно указать, в частности, -s и -S — размеры буферов сокетов для посылки/получения данных для клиента и сервера соответственно, а также -m и -M — размеры посылаемого/принимаемого сообщений, по умолчанию совпадающие со значениями, задаваемыми в параметрах -s и -S.

Для тестов типа RR в параметре -r указывается размер запроса/ответа. Единицей измерения для всех этих параметров является байт. Производительность на тестах STREAM измеряется в Мбит/с, а на тестах RR — в запросах в секунду.

Результаты наших измерений приведены в табл. 2. В тестах измерялась производительность в двух различных Linux-средах: RedHat 5.2 (ядро 2.0.36-1, стек протоколов TCP/IP для NET3) и RedHat 6.2 (ядро 2.2.14-5, NET4). Проведение измерений на более старой версии RedHat было обусловлено сообщениями о более высокой производительности работы TCP/IP в ней по сравнению с версиями ядра 2.2.х. Если иное не указано, в таблице подразумевается RedHat 6.2.

Во всех тестах TCP_STREAM использованы подразумеваемые параметры (кроме, естественно, общих параметров для всех тестов).

В тестах UDP_STREAM задавалось -s 32768 -S 32768 -m 4096, что типично для имеющейся базы данных результатов измерений. Мы нашли, что «разумные» изменения этих параметров слабо влияют на результат. В тестах TCP_RR применялись сообщения длиной 1 байт (-r 1,1), а в тестах UDP_RR — в 16 байт (-r 16,16). В табл. 2 для иллюстрации приведен также один результат для UDP_RR при r = 13 байт (нижняя граница для UDP_RR).

Мы обнаружили, что в RedHat 6.2 утилита netserver не работает с тестом UDP_RR, для этих тестов пришлось использовать альфа-версию netperf 2.2 (соответствующие результаты и приведены табл. 2.

Кроме приведенных в табл. 2 результатов, мы иногда измеряли также нагрузку на процессор. Типовая нагрузка для тестов TCP_STREAM составляет порядка 10-15%, для TCP_RR — 25-30%.

Для тестов STREAM полученные значения для одного канала Fast Ethernet находятся на уровне 94-96 Мбит/с, что очень близко к теоретическому пределу 97,53 Мбит/с [1]. По производительности на тестах STREAM различные сетевые платы отличаются слабо, поэтому производительность имеет смысл оценивать на тестах RR. Тесты TCP_STREAM удобно использовать для проверки, действительно ли сетевая плата работает в полнодуплексном режиме: при некорректных автопереговорах с коммутатором пропускная способность будет аномально низка. Тесты UDP_STREAM являются однонаправленными и для этой цели не годятся.

Из сравнения данных для 3С905B (приведены данные для плат, выпущенных в Ирландии) с разными версиями RedHat видно, что стек протоколов в RedHat 5.2 работает быстрее, чем в RedHat 6.2, особенно на тестах RR. Платы 3С905B при работе с RedHat 5.2 опередили всех конкурентов, работающих в RedHat 6.2. Более того, в RedHat 5.2 с этими платами удалось получить результаты, лучшие среди представленных в базе данных тестов netperf.

Возможно, в RedHat 6.2 применение специальных заплаток для ядер 2.2.х, ускоряющих работу TCP/IP на коротких сообщениях, позволило бы улучшить данные тестов RR. Однако мы это не проверяли: столкнувшись с вычислительной нестабильностью ядра 2.2.14-5.0 в RedHat 6.2, мы решили, что проводить модификацию этого ядра бессмысленно.

Из табл. 2 видно, что в равных условиях в RedHat 6.2 платы с драйвером tulip на тестах RR действительно оказываются немного быстрее. При этом наилучшие результаты имеет KNE100TX, однако их версий на базе DEC/Intel 21143 уже нет на рынке. Результаты платы 3COM чуть ниже, чем Intel; последние оказались наиболее беспроблемными с точки зрения интероперабельности (если не считать снятых с производства версий KNE100TX), с ними можно строить кластеры со связыванием каналов Fast Ethernet. В режиме связывания мы проверили работу со спаренными каналами Fast Ethernet (по две одинаковых платы на узел). В табл. 2 приведены данные для тестов между ирландскими 3C905B и KNE100TX. На тестах UDP_STREAM скорость почти удваивается, в то время как в TCP_STREAM увеличение не превосходит полутора раз. На последних тестах пары плат Intel, Kingston и 3Com при работе между собой давали результаты в диапазоне от 133 до 149 Мбит/с. Производительность на тестах RR также увеличивается, но не столь значительно.

Загрузка процессоров при связывании каналов, естественно, также возрастает (до 30% на тестах TCP_STREAM). Включение режима cut-through в коммутаторе приводит к незначительному росту производительности (например, со 143 до 150 Мбит/с на тестах TCP_STREAM; на тестах RR рост лишь чуть заметнее). Влияние cut-through в обычном случае (одна сетевая плата на узел) оказалось незаметным. Можно предположить, что включение этого режима будет существеннее, если при распараллеливании с обменом сообщениями отказаться от применения TCP/IP, вносящего большие программные задержки. Наконец, для оценки роли задержек, вносимых коммутатором, мы рассмотрели вариант соединений 3C905B — 3C905B и KNE100TX — KNE100TX напрямую (кросс-кабелем). Выяснилось, что это приводит к существенному росту производительности на тестах RR.

Выводы

Проведенное подробное сопоставление производительности на тестах netperf наиболее популярных сетевых плат Fast Ethernet, соединяющих узлы кластера Beowulf, позволило сделать ряд выводов.

• Эффективный выбор коммутатора Fast Ethernet требует тщательного анализа его характеристик, которые часто недоступны.
• Найдено, что в Linux производительность плат (с учетом сделанных в тексте оговорок) на базе микросхем DEC/Intel 21143 в тестах RR несколько выше, чем у других рассмотренных в работе сетевых плат.
• Показано, что связывание каналов Fast Ethernet в пары позволяет существенно поднять производительность на тестах STREAM.
• Работа через коммутатор способна существенно уменьшить скорость обмена короткими сообщениями по сравнению с соединением узлов кластера напрямую. Работа выполнена в суперкомпьютерном центре Института органической химии РАН и финансировалась в рамках проектов РФФИ 98-07-90290 и 01-07-90072.

Литература

[1] А. Андреев, В. Воеводин, С. Жуматий, «Кластеры и суперкомпьютеры — близнецы или братья?», «Открытые системы», 2000, № 5-6

[2] Л. Куин, Р. Рассел, «Fast Ethernet». Киев, BHV, 1998

Михаил Кузьминский — старший научный сотрудник, Александр Мускатин - ведущий инженер суперкомпьютерного центра Института органической химии РАН. С ними можно связаться по телефону (095) 135-6388