Posts about hpc (old posts, page 1)

High-Performance Computing, or the art of burning money faster than ever

Направи си сам суперкомпютър

Горе-долу с мотото в заглавието стартира преди 4 години проектът, под чиято шапка започна изграждането на клъстера Physon. Много вода изтече от слънчевия зимен ден на 2006 г., когато случайна среща в алеята към ФзФ на СУ ме направи съпричастен на идеята, до късната вечер на отминалия четвъртък, когато LINPACK се произнесе за производителността на машината след финалното ѝ разширение. Много интересни проблеми възникаха и много решения бяха намерени. Научих много за управлението на разпределените ресурси, за оптимизирането на различните мрежови компоненти, за подсигуряването срещу сривове на различни софтуерни компоненти и волю-неволю се превърнах в поредния физик с докторска степен, отделящ (много) по-голяма част от времето си за системна администрация на изчислителните ресурси, отколкото за тяхното използване в научната си работа, досущ като сродните душѝ от EPCC.

../images/93.thumbnail.jpg

Снимка на Physon в наши дни

Къде сме сега? След години на доработване, донастройване, разширяване, местене в разлчни точки на стаята и така нататък, Physon достигна мечтаните параметри, които бяха заложение в началото на проекта. В момента машината се състои от два физически дяла, разделението между които обаче е чисто логическо и касае само потребителите на паралелни приложения. Условно нареченият “малък” дял е това, с което започнахме — 4 машини с по два 4-ядрени процесора Xeon E5335 всяка, събрани в две 1U шасита, по две в шаси. От 32-те ядра, в комбинация с 533 MHz ECC DDR2 памет, паралелният LINPACK успява да “изцеди” 207 Gflops при теоретичен максимум от 256 Gflops. Доброто съотношение от почти 81% се постига не без помощта на високоскоростната и нисколатентна InfiniBand връзка, която беше особено дебело перо в цената на първоначалната система. При следващите две разширения на системата заложихме на процесори Xeon E5420 (25% по-висока тактова честота и двойно повече L2 кеш в сравнение с E5335) и по-бързата 667 MHz ECC DDR2 памет, при което се появи вторият, условно наречен “голям” дял. За да не се появи и трети дял, при последното разширение подходихме силно консервативно и заложихме отново на същата техника, въпреки наличието на пазара на Xeon-и с Nehalem ядро (базирано на i7 микроархитектура), работещи с по-бързата DDR3 памет. Въпреки, че на някои решението да закупим по-стар модел техника на цена, близка до цената на по-бързата нова, може да изглежда странно, то не е лишено от своята логика, особено когато на машината започне да се гледа като на платформа за изпълнение на паралелни приложения. Така големият дял достигна 160 ядра, които под LINPACK “развиват” 1241 Gflops [1] при теоретичен максимум от 1600 Gflops. В крайна сметка запълнихме всички 24 порта на InfiniBand маршрутизатора и получихме производителност от 1448 Gflops.

И къде бихме били без едно необективно сравнение в стил ябълки с/у круши. Българският суперкомпютърен център твърди, че държавният Blue Gene/P (изписван нататък в текста за краткост като BG/P) развива максимална производителност от 23.42 Tflops (при 27.85 Tflops теоретичен максимум), което го прави 16.2 пъти по-бърз от Physon. Оперативната му памет от 4 TiB е 10.7 пъти повече от тази на Physon (384 GiB). Всичко е много добре, но съотношението в цените няма как да не наведе мислещия човек на някои много интересни разсъждения:

BG/P струва на данъкоплатците 5.4 млн. лева по официални сведения, което прави по 230.6 лева на 1 Gflops. До момента Physon струва по-малко от 150 хил. лева (с ДДС, включително климатиците), което прави по 103.6 лева на 1 Gflops [2], като при това не сме правили сериозни компромиси с качеството — шасита на Supermicro, InfiniBand маршрутизатор на SilverStorm (сега QLogic), гигабитови комутатори на Netgear, сървърни модели твърди дискове на Seagate и Western Digital, онлайн UPS-и на Ablerex (които съвестно обират големите падове на напрежение, предизвикани от кьопавата ел. инсталация) и климатик на Mitsubishi. Нежеланието ни да се обвързваме с конкретен производител по време на изграждането ни спря да използване блейдове, които щяха допълнително да свалят цената и да увеличат компактността на системата. При тази цена производителността на BG/P би струвала 2.4 млн. лв, където не е отчетена отстъпката за количества от цената на модулите, както и че цената на порт на InfiniBand маршрутизаторите намалява с увеличаване на размера на последните. Инсталирането на подобна система от българи би струвало под 100 хил. лв, които при това ще отидат обратно в българската икономика. Разликата до 5.4 млн. лв ще стигне да покрие за поне 30 години по-високата електрическа консумация спрямо тази на BG/P. Да не говорим за опита, който ще се натрупа при това начинание и за възможностите за бъдеща надстройка [3]. Не напразно фирмите от бранша възроптаха, когато стана ясен начинът, по който държавата се е сдобила с чудото на IBM.

Предимствата на една такава система пред BG/P са очевидни:

  • 64-битовите процесори на Physon позволяват на всяка непаралелна 64-битова програма достъп до всички 16 GiB оперативна памет, с които е снабден всеки изчислителен възел — нещо, което е изключено като възможност на 32-битовия BG/P.
  • Учените все по-рядко пишат безкрайни кодове на Fortran (и понякога C/C++) и все по-често залитат към удобствата на сложни и многофункционални комерсиални среди за математичен анализ като Maple, Mathematica и MATLAB, които просто нямат версии за PowerPC, но щастливо се изпълняват в пакетен режим на грид-подобни обкръжения като това на Physon.
  • Не всички научни проблеми се решават с масивно паралелни програми. Някои учени имат серийни програми, които биха желали да пуснат върху множество от хиляди различни входни данни (т.нар. смущаващ паралелизъм, най-ярък представител на който е разпределеният проект SETI@Home). Очевидно BG/P, където всяка задача използва минимум 512 ядра, не е техният избор.

Финансирането на Physon не дойде наведнъж, а под формата на поредица от годишни траншове, къде по-големи, къде по-малки. През всичкото това време цялата информация за машината — конфигурация, упътване и статистики за използване, беше публично достъпна онлайн и продължава да бъде такава. Последното считам за особен дълг, когато става дума за харчене на държавни средства и с радост участвам в мероприятията, популяризиращи проекта, дори когато после ги преписват дословно тук-там.

Подробности за софтуера и хардуера, които направиха мечтата реалност, ще напиша някой друг път.

[1] Стойността е предварителна и при незавършено конфигуриране на параметрите в BIOS на новите машини. По-точно замерване ще направя при следващото спиране за рутинна поддръжка.
[2] Една система с nVidia Tesla или Fermi ще даде на порядъци по-добро съотношение, но подобни системи са подходящи само за тесен кръг от проблеми, много по-тесен от кръга на задачите, които се решават на BG/P и/или на Physon.
[3] Суперкомпютърният център на Университета в Единбург (EPCC) веднъж надстрои компютъра HECToR, заменяйки всички 5664 двуядрени Opteron-и с четириядрени, а в момента гласи замяната на последните с шестядрени, при което напълно се запазва инвестицията в останалата част от техниката на Cray. Първоначалната цена на компютъра беше 5.6 млн. британски лири.

Що е то HPC?

Що е то HPC и има ли то почва у нас? Кои са тези особености на хардуера и софтуера, които правят HPC уникална по рода си област на компютърното познание?

HPC или High Performance Computing е технически термин, с който се обозначава специфичен клас от хардуерни и софтуерни технологии, както и спецификата на тяхното програмиране и използване. Обикновено към класа на HPC отнасят научните и инженерни задачи, изискващи извършването на огромна по обем обработка на данни и използващи за целта мощни (супер-)компютри, които далеч надхвърлят по производителност средностатистическия домашен или бизнес компютър. Към HPC често (и неправилно) причисляват и т. нар. High Throughput Computing (или HTC). Въпреки, че целта и при HPC, и при HTC е да се обработи възможно най-много информация за единица време, при HTC информацията обикновено постъпва под формата на множество работни единици — заявки или транзакции. Типичен пример за HPC е детайлното моделиране на климатичната обстановка с цел добиване на по-точна прогноза за времето, а за HTC — обработването на милиони заявки за търсене в огромна база данни (напр. Google). Тъй като повечето HPC задачи обработват информация под формата на масиви от числа с плаваща запетая, проиводителността при тях обикновено се измерва в милиарди операции с плаваща запетая за секунда, Gflop/s (гигафлопи за секунда или просто гигафлопси), където flop е съкратено от floating-point operation. С развитието на суперкомпютърната техника префиксът на мярката постепенно се измества от гига- към тера-, като най-бързият суперкомпютър в света, Roadrunner на лабораторията в Лос Аламос, има производителност от над 1 Pflop/s (петафлопи за секунда). При HTC производителността обикновено се измерва в транзакции за секунда, tps, със съответните степенни префикси от системата SI.

HPC се различава от обикновената изчислителна техника, както в хардуерен, така и в софтуерен аспект. Суперкомпютрите са бързи. При това, те не са просто бързи, а БЪРЗИ, като бързодействието често пъти се постига с нетрадиционни за масовата техника похвати. Като пример мога да посоча факта, че когато масата персонални компютри в България през 80-те години на миналия век са 8-битови скаларни CISC архитектури, работещи на честоти 1—4 MHz и извършващи едва десетина Kflop/s без допълнителни математически копроцесори (или транспютри), то типичният представител на суперкомпютрите от него време Cray-1 е 64-битова векторна RISC архитектура с тактова честота 80 MHz и пикова производителност от 250 Mflop/s. Въпреки, че последната изглежда смешно на фона на съвременната микропроцесорна техника, за реализиране на подобно устройство през тях години е било необходимо да се използва екзотичната емитерно свързана логика (ECL), осигуряваща висока скорост на превключване за сметка на много ниска степен на интеграция и ОГРОМНА консумирана мощност, изискваща иновативни и скъпи охлаждащи системи. Друг подход за увеличаване на изчислителната мощност, доминиращ HPC пазара и в наши дни, е едновременното използване на множество (до стотици хиляди) процесорни елементи — т. нар. масивно-паралелни архитектури. При това инженерната сложност се пренася от построяването на свръхбърз микропроцесор към измислянето на начин за ефикасно свързване на процесорните елементи. За целта обикновено се използват специализирани превключващи елементи (напр. SeaStar 2 в XT3/XT4 на Cray), осигуряващи предаването на информацията по сложна система от връзки. В зависимост от броя на свързаните процесори, свързващата подсистема може или да бъде от тип “телефонна централа” (crossbar), която осигурява директна комутируема свързаност от тип всеки с всеки (напр. IBM SP2), или информацията да се маршрутизира върху дву-, три- или повече измерна мрежа от изчислителни възли, подобно на силно структурирано и опростено подобие на Интернет. Кросбар мрежите осигуряват огромна пропускателна способност (измервана в GiB/s) по множество от независими канали и ниска латентност (времето между стартиране на операция по пренасяне на информация и нейното физическо завършване), но сложността им нараства експоненциално с броя на свързаните процесори, а разширяването им за включване на допълнителни процесори е практически невъзможно, поради което те почти не намират приложение в съвременната HPC техника. Далеч по разпространени са мрежите с маршрутизиране на трафика. Освен специализираните комуникационни контролери, широко приложение намират и мрежовите преносни среди с общо предназначение InfiniBand и Ethernet, последната главно в съвременната инкарнация с пропускателна способност от 10 Gbps.

Особеният хардуер изисква и особено програмиране. Отличителна черта на HPC софтуера е, че логиката в него е сведена до минимум, а данните са структурирани по възможно най-прост начин, позволяващ тяхната паралелна и/или векторна обработка. Корените на голяма част от програмните кодове датират от времена, когато доминиращ програмен език е бил FORTRAN 77, понятието “структуриран тип данни” е било приемано с недоумение, а на оператора GOTO не се е гледало с отвращение. По традиция известна част от HPC приложенията продължават да се пишат на FORTRAN, понятието “структуриран тип данни” продължава да буди недоумение сред определени кръгове, а операторът GOTO продължава да живее щастливо сред милионите редове програмен код. Смело може да се твърди, че кодът на един съвременен браузър е многократно по-сложен и от най-сложната програма за симулации в областта на твърдотелната физика. И въпреки това, писането на качествен и бърз HPC код е нетривиална инженерна задача и изисква много задълбочено познаване на основите на микропроцесорната и мрежова технология, лежаща в основата на съвременните компютърните архитектури.

Елементарна задчка за размисъл: защо следният код

int bigarray[DIM1][DIM2], i, j;

for (i = 0; i < DIM1; i++)
  for (j = 0; j < DIM2; j++)
    bigarray[i][j] *= 2;

се изпълнява шест пъти по-бързо (при DIM1 = DIM2 = 10000) от напълно аналогичния

int bigarray[DIM1][DIM2], i, j;

for (j = 0; j < DIM2; j++)
  for (i = 0; i < DIM1; i++)
    bigarray[i][j] *= 2;

(жокер: причините са повече от една)

Програмирането на (масивно-)паралелни машини предоставя допълнителни предизвикателства. За целта са развити няколко програмни техники и парадигми, които предлагат различно съотношение между леснотата на тяхното използване и мащабируемостта на резултатните изпълними кодове. В най-простия случай се разчита на компилатора да открие и по възможност паралелизира части от програмния код (т. нар. автоматична паралелизация), с която задача различните компилатори се справят с променлив успех. В най-сложния случай цялата грижа за комуникацията и синхронизацията между отделните изчислителни елементи е оставена на програмиста, като на последния се осигурява само стандартен набор от комуникационни примитиви (MPI, PVM и др.). Обикновено това е методът, използван в най-производителните и мащабируеми кодове. По средата на спектъра са т. нар. “data parallel” парадигми, при които се използват или специални диалекти на известни програми езици, разширени с допълнителни паралелни конструкции, напр. High Performance Fortran (HPF) или Unified Parallel C (UPC), или стандартните диалекти се разширяват с позволените в тях механизми, напр. OpenMP (реализиран като набор от #pragma директиви в C и като специално форматирани коментари във Fortran). За MPI и OpenMP ще стане дума по-нататък в следващите писания по въпроса.

Има ли HPC почва у нас? Учудващо за мнозина, но отговорът е утвърдителен. Компютрите се използват за решаване на инженерни и научни задачи в България още от времената на машините от Единната Система и СМ, “аналози” на популярни за времето си мейнфрейм машини на IBM и миникомпютри на DEC. През 90-те години на миналия век, когато връх на персоналните компютри в родината бяха грешащият при деление Pentium (а само по експота и панаири може да се види мускулестият му братовчед Pentium Pro), в различни изчислителни центрове в страната “мелят” 64-битови RISC машини (една от които кротко залежава като музеен експонат под бюрото ми във ФзФ). А откак преди година България се сдоби и с 8192-ядрен Blue Gene/P, то не остана и капка съмнение, че у нас HPC има почва. Доколко стабилна е тя, бъдещето ще покаже.

Intel Core i7 vs Xeon

Мине се не мине някое време и Intel изважда от голямата си технологична шапка поредния заек. И макар повечето зайци на Intel, както и на другите “иноватори” в информационната индустрия, да са просто преродените души на умрелите динозаври, всички вкупом се втурват да правят тестове и да възхваляват новите продукти. Реших, че нямам причина да изоставам от тази всеобща треска и се захванах да проверя, става ли Core i7 за научни пресмятания, не става ли.

Вместо предисловие

Intel най-накрая осъзна, че съвременните интензивни приложения изискват все по-бърз достъп до все по-големи обеми информация, съхранявана в RAM паметта, чиято пространствена кохерентност в общия случай е недостатъчно голяма и дори 2x6 MB L2 кеш на последните поколения Xeon не са достатъчни за преодоляване на това най-тясно гърло на системата (изключвам дисковата и мрежова входно/изходни подсистеми). AMD отдавна интегрираха контролера на паметта в чипа на процесора, което в комбинация с HyperTransport шината създаде изключително производителния при обща употреба Opteron. Не случайно Cray избраха Opteron като наследник на Alpha в техните суперкомпютри (като частичната съвместимост на шините вероятно също е допринесла за решението). Най-бързият суперкомпютър към настоящия момент, RoadRunner на IBM, също използва Opteron за x86 гръбнака. Opteron се използва и в HECToR, 11328-ядреното чудовище на EPCC, на което имах удоволствието да работя по време на престоя си в Единбург в края на миналата година.

Отговорът на Intel, след години на разработки и лабораторни тестове, беше микроархитектурата Nehalem, наследникът на Core 2, известна под търговското наименование Core i7. При нея контролерът на паметта е интегриран в процесорния чип, а йерархията на кеша е усложнена с добавяне на трето ниво (L3). За разлика от Core 2, където кешът от второ ниво се споделя от две ядра, при Nehalem всяко ядро разполага със собствен кеш от второ ниво, макар и силно редуциран по обем — само 256 KiB/ядро. Следният изход от инструмента cpuinfo на Intel показва организацията на ядрата и кешовете в процесор Core i7 920 (Nehalem):

Processor     : Intel Core i7 920
Architecture  : x86_64
Hyperthreading: disabled
Packages   : 1
Cores      : 4
Processors : 4
=====  Processor identification  =====
Processor       Thread  Core    Package
0               0       0       0
1               0       1       0
2               0       2       0
3               0       3       0
=====  Processor placement  =====
Package Cores           Processors
0       0,1,2,3         0,1,2,3
=====  Cache sharing  =====
Cache   Size            Processors
L1      32 KB           no sharing
L2      256 KB          no sharing
L3      8 MB            (0,1,2,3)

За сравнение, организацията в Xeon E5420 (Core 2) е следната:

Processor     : Intel Xeon E5420
Architecture  : x86_64
Hyperthreading: disabled
Packages   : 1
Cores      : 4
Processors : 4
=====  Processor identification  =====
Processor       Thread  Core    Package
0               0       0       0
1               0       1       0
2               0       2       0
3               0       3       0
=====  Processor placement  =====
Package Cores           Processors
0       0,1,2,3         0,1,2,3
=====  Cache sharing  =====
Cache   Size            Processors
L1      32 KB           no sharing
L2      6 MB            (0,1)(2,3)

Добавянето на кеш от трето ниво ни връща в годините на RISC процесорите от типа на POWER на IBM, където подобна организция беше нещо нормално, налагащо се от факта, че суперкомпютърната индустрия дълго време отказваше да използва по-нови поколения памети, разчитайки на по-бавни, но изпитани с времето технологии.

Системите

Като площадка за тестване на Xeon E5420 е използван един от възлите на клъстера physon, а достъп до машина с Core i7 920 беше любезно предоставен от Васил Колев (a.k.a. ManiaX). Съществените в случая характеристики на системите са както следва:

Система с Xeon E5420

CPU: 2 x Intel Xeon E5420 (2.5 GHz, 1333 MT/s FSB)
MoBo: Supermicro X7DBT-INF
Chipset: Intel 5000P
RAM: 8 x 2 GiB ECC DDR2-667

Система с Core i7 920

CPU: Intel Core i7 920 (2.66 GHz, 4.80 GT/s QPI, спрян HT)
MoBo: Intel DX58SO
Chipset: Intel X58
RAM: 3 x 2 GiB DDR3-1066 (tripple channel)

Тестовете

Науката е или физика, или колекциониране на пощенски марки.”

—Е. Ръдърфорд

Опирайки се на горното твърдение, ограничих тестовете до едно синтетично и две реални приложения за симулиране на физични процеси и свойства на вещества в наноразмерната област.

memset тест

memset тестът е елементарно многонишково приложение, всяка нишка на което многократно запълва динамично заделен блок от 512 MiB (229 байта), използвайки стандартната библиотечна функция memset(3). Приложението е компилирано с Intel C Compiler 11.0.074 с ниво на оптимизация O3 и целево множество от инструкции SSE4.1 за теста на Xeon E5420 и SSE4.2 за теста на Core i7 920, което свързва кода със силно оптимизирана реализация на memset(3).

Изпълнението с една нишка оправдава обещанията на Intel, като i7 920 постига 8863 MB/s в сравнение с 3675 MB/s при Xeon E5420. Двунишковото изпъление изяжда почти цялата налична пропускателна способност на връзката между процесор и памет, достигайки 13172 MB/s при i7 920 и 4188 MB/s при E5420. Изпълнението на 4 нишки показва, че е на лице насищане с 13416 MB/s при i7 920 и 4192 MB/s при E5420.

Чипсетът Intel 5000P предоставя независима шина до всяко процесорно гнездо. И наистина, при двунишково изпъление, когато всяка нишка работи в отделен физически процесор, общата пропускателна способност достига 5440 MB/s, като при 4 нишки (по две на физически процесор) тя е 5768 MB/s. При 8 нишки се наблюдава лек спад до 5728 MB/s.

md тест

Тестът представлява типична компютърна симулация от областта на физиката на кондензираните среди и разглежда еволюцията във времето на положенията и скоростите на атомите на моделна въглеродна нанотръба. За целта се използва методът на молекулната динамика, от където и идва наименованието на теста. Особеното на този тест е, че всички работни променливи се побират напълно в обема на последното ниво от кешовата йерархия и на двата разглеждани процесора.

Без да се впускам в подробности за организацията и работата на програмата ще кажа, че компилаторът на Intel векторизира вътрешните цикли и произвежда векторни SSEx опкодове, което позволява на програмата да използва всичката изчислителна машинария, налична във всяко процесорно ядро. За разлика от следващия тест, тук не се използват никакви външни специализирани библиотеки за математически пресмятания.

Core i7 920 постига производителност от 155.9 стъпки/s, докато при Xeon E5420 тя е 137.3 стъпки/s. Нормирани на тактовата честота на процесора, горните производителности (в единици наностъпки/такт) се редуцират до 58.6 при i7 920 срещу 54.9 при E5420, т.е. за подобен род пресмятания микроархитектурата на Core i7 е с около 7% по-ефективна спрямо Core 2 при една и съща тактова честота.

qe тест

Quantum Espresso представлява тежък код за пресмятане на квантовомеханичните свойства на кондензирани среди с методите на теорията на функционала на електронната плътност в базис от плоски вълнови функции (иначе казано PWDFT). Изисква огромно количество памет за съхранение на работните данни, върху които прилага множество матрични операции и дискретни трансформации на Фурие. Основната изчислителна работа се поема от три специализирани външни библиотеки: BLAS и LAPACK за матричните операции и FFTW за трансформациите на Фурие. Програмата е многонишкова, като всяка нишка е отделен процес, а за обмяна на данни между процесите се използва Open MPI, която среда ще разгледам в по-следващите писания за парадигмите и методите на паралелното програмиране. Използва се оптимизирана реализация на BLAS и LAPACK в Intel Math Kernel Library (IMKL), а FFTW е реализирана под формата на интерфейсен слой над IMKL.

Програмата може да се изпълнява както в еднонишков (сериен), така и в многонишков (паралелен) режим. Времето за изпълнение на симулацията в сериен режим на Core i7 920 е 122 минути (11.80 сим/ден), докато при Xeon E5420 то е 143 минути (10.07 сим/ден). Ефективността, измервана в единици сим/(ден•GHz), е както следва: 4.44 за i7 920 и 4.03 за E5420. Core i7 920 е с 10% по-ефективен от Xeon E5420 при този род пресмятане.

Паралелният режим на работа позволява да се наблюдава влиянието на северния мост при Xeon, както и влиянието на споделянето на L2 кеша между ядрата. С 4 процеса Core i7 920 успява да “смели” задачата за 45.41 минути (31.71 сим/ден), докато при E5420 времето варира от 48.27 мин (29.83 сим/ден) до 60.00 мин (24.00 сим/ден) в зависимост от разпределението на процесите по ядрата на двата микрочипа. Най-лошият случай (24.00 сим/ден) се реализира, когато всички 4 процеса се изпъляват в рамките на един микрочип, а най-добрият (29.83 сим/ден) — когато всеки процес се изпълнява без да споделя L2 кеш с друг процес. Междинният случай, при който два по два процесите споделят общ L2 кеш, но двойките се изпълняват в различни микрочипове, се изпълнява за 54.26 мин (26.54 сим/ден).

Вижда се, че при 4 процеса Core i7 920 извършва пресмятането 2.69 пъти по-бързо, единичен Xeon E5420 — 2.38 пъти по-бързо, а два Xeon E5420 — 2.96 пъти по-бързо или 2.64 пъти по-бързо, в зависимост от постановката.

В страни от явното по-доброто мащабиране на програмата върху Core i7 при еднопроцесорни конфигурации, резултатите от двата Xeon процесора са много поучителни и следва да се имат предвид, както от потребителите на подобни многоядрени системи, така и от техните администратори.

Някои изводи

От направените тестове мога да заключа, че Core i7 е достоен процесор за работната станция на всеки сметач. Дори най-евтиният представител на семейството, Core i7 920, се представя по-добре от по-скъпия Xeon E5420. При многонишкова работа i7 920 се представя по-добре от E5420 в еднопроцесорния случай, като последният разгръща способностите си едва в многопроцесорни конфигурации.

X11 forwarding with “X11UseLocalhost no”

Just a quick tip. If you’ve ever tried to run sshd with the option X11UseLocalhost set to no (e.g. in a cluster environment where interactive jobs running not on the login node should be able to display something), you might have observed that X11 forwarding suddenly stops working. And although the DISPLAY variable is set accordingly and xauth list shows that authentication tokens are present, X clients still can’t connect:

hristo@cn001:~$ echo $DISPLAY
cn001:10.0
hristo@cn001:~$ xauth list
cn001.local:10 MIT-MAGIC-COOKIE-1 0123...
hristo@cn001:~$ xterm
xterm Xt error: Can't open display: cn001:10.0

And it’s even worse:

hristo@cn001:~$ telnet cn001 6010
Trying 10.1.1.1...
telnet: Unable to connect to remote host: Connection refused

The root of the problem stems from the fact that sshd usually binds only to the first address family it finds in the system and if your system has IPv6 enabled (e.g. the default on Ubuntu Server 7.10) it ends up binding only a tcp6 socket (and the X11 client library tries to establish a regular TCP connection):

hristo@cn001:~$ netstat -an | grep 6010
tcp6 0 0 :::6010 :::* LISTEN

In order to fix this you can either disable IPv6 in the kernel or simply add the following option to /etc/ssh/sshd_config:

AddressFamily inet

After you restart the SSH server it will no longer use IPv6 and will start binding its X11 proxy listeners to the usual IPv4 INADDR_ANY of 0.0.0.0.

InfiniBand on Ubuntu Server 7.10

If for some obscure reason you ever want to use Ubuntu Server 7.10 in a HPC scenario where your compute nodes are interconnected through InfiniBand fabric bear this in mind — Ubuntu’s IB support is broken and it has been in such a state for at least an year!

Besides from not providing the full OFED package, Ubuntu also gives us errors in udev’s configuration, namely in /etc/udev/rules.d/20-names.rules. On a pristine system the Infiniband section reads:

...
# Infiniband devices
KERNEL=="umad[0-9]*",         NAME="infiniband/%k"
KERNEL=="issm[0-9]*,          NAME="infiniband/%k"
KERNEL=="uverbs[0-9]*,        NAME="infiniband/%k"
KERNEL=="ucm[0-9]*,           NAME="infiniband/%k"
KERNEL=="rdma_cm",            NAME="infiniband/%k"
...

Noticed it? The closing double quotes on the lines for issm, uverbs, and ucm are missing. Thus udev ignores those lines as errors and puts theirs device nodes in /dev instead of /dev/infiniband/ where most software expects them to be. For example, OpenMPI’s openib BTL fails to run with such a configuration.

Correct the section so that it reads:

# Infiniband devices
KERNEL=="umad[0-9]*",         NAME="infiniband/%k"
KERNEL=="issm[0-9]*",         NAME="infiniband/%k"
KERNEL=="uverbs[0-9]*",       NAME="infiniband/%k"
KERNEL=="ucm[0-9]*",          NAME="infiniband/%k"
KERNEL==“rdma_cm",            NAME="infiniband/%k"

Now reboot and your device nodes will be placed where they are meant to be.