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.

Consistent performance

Our Physon (in Bulgarian only) HPC cluster was originally composed of four dual Xeon MoBos with QDR (20 Gbps) InfiniBand links as interconnection fabric for MPI message passing. Armed with eight quad-core Xeon E5335 (2,0 GHz, 2x4 MB L2 cache) the system peaked at Rmax equal to 209,0 GFLOPS for Nmax of 74880 on the HPL test. Since the theoretical top performance is Rpeak equal to 256 GFLOPS, our old nodes have parallel efficiency of 0,816.

Now, about an year later, we got a shiny new addition of eight dual MoBos with the newer quad-core Xeon E5420 (2,5 GHz, 2x6 MB L2 cache). Since four nodes were already installed and powered on, I run the HPL test again to see how well the new processors compare to the old ones. The new nodes peaked at Rmax equal to 256,2 GFLOPS for the same matrix size. With a theoretical top performance of Rpeak equal to 320 GFLOPS we still have a good parallel efficiency of 0,801 (or 1,226x the performance for 1,25x the CPU frequency).

It is now obvious why most cluster systems in the Top500 list utilize the (now) relatively cheap InfiniBand as their interconnection fabric instead of the more sophisticated and much more expensive proprietary interconnects.

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.

R.I.P. SP2

Днес, с нескрита болка в сърцето установих, че старият IBM SP2 в мазето на ФМИ е мъртъв. Причината за смъртта - инфаркт (датиращ още от 2005 г.), последван от технологичния еквивалент на гаврата с труп.

Предистория

../images/13.thumbnail.jpg

SP2 във ФМИ - преди

Машината беше докарана през далечната 2005 г. от Германия, след като вярно беше служила в един от теоретичните институти на Max Planck Institute. Инициатор от германска страна беше един от бившите дипломанти на настоящата ми научна ръководителка, който използва вратичка в тамошните закони и осигури даряването на машината на СУ. От българска страна цялата работа беше свършена от научната ми ръководителка (доц. Пройкова), която използва връзките си от най-високо ниво за да уреди транспорта и безмитния внос на скъпата за времето си техника. След като се оказа, че престоят на SP2 в сградите на ФзФ няма да го бъде, беше договорено специално помещение във ФМИ, където беше изградена климатична система и осигурена трифазна електрозахранваща линия. IBM България проектираха помещението и свързаха множеството кабеляци на добра воля (т.е. безплатно), но по-голямата част от захранващите блокове изгоряха при тестовото пускане на системата. Причините останаха неизяснени и до ден днешен, а ремонтът на блоковете се отложи с години. За закупуване на нови не можеше и дума да става (при цена от 8000 евро на старо за захранващ блок!). Бяха направени няколко запитвания към източно- и централнооевропейската дирекция на IBM за евентуална помощ за възстановяване на машината или за изграждането на нова такава, бяха дадени и обещания от високопоставени служители, но в крайна сметка нищо не се случи. Постепенно интересът замря, особено след закупуването на новия клъстер във ФзФ. Остана само надеждата, че някой ден машината ще намери мястото си като музеен експонат на напредналата технология на IBM от 1994 г.

За съжаление машината никога няма да види музей, защото…

Наши дни

../images/14.thumbnail.jpg

Остатъците от SP2 във ФМИ

Това, което не се забелязва на снимката е, че едната кула е напълно изтърбушена, а другата се използва за стелаж. Навсякъде из помещението има разхвърлени части от някогащните процесорни възли, примесени с дебел слой прах от строителни отпадъци. От достоверен източник, участвал активно в разграбването, се разбра, че машината е потребена “по предназначение” (да се чете - всеки си взел каквото му потрябвало). Контролните работни станции от тип RS/6000 също не са оцелели (едната беше съоръжена със 128 MB RAM /от 1994 г.!/)…

../images/15.thumbnail.jpg

Бивш изчислителен възел

../images/16.thumbnail.jpg

На някого са му трябвали памети…

Гледката е просто покъртителна. Но много по-покъртително е отношението на тези, които са се отнесли към университетското имущество като към трактор в изоставено ТКЗС. Гореупоменатият източник - дългокос и очилат момък, далечно подобие на администратор (или /не/вещо техническо лице), разказваше с някакъв особен патос за превръщането на процесорните радиатори в охлаждане за… аудио усилватели. А твърдите дискове били “рециклирани” и с тях били снабдени някакви PC-та… WTF?! Разбира се, някой (да не споменавам имена) е позволил всичко това.

Дори сарказмът ми отказа да коментира в случая…

Sun Studio 12 - по-бързо и за без пари

Поредната приятна изненада от страна на Sun Microsystems. След като преди време отвориха софтуерната си кутия и пуснаха за свободно ползване без ограничения компилаторите си, първо за Solaris, след това и за Linux, с огромен интерес следя развитието им, главно като основен конкурент на Intel в качествените средстава за разработка, достъпни за бедната ни академична институция, именувана Физически Факултет на СУ. Естествено, тези на Intel печелеха като производителност - все пак и техни са железата, на които се изпълняват програмите, те си ги познават по-добре, а и за без пари - толкова от Sun. Главният недостатък (един вид) на компилаторите на Intel - безплатният им лиценз за Linux е приложим само за индивидуално ползване. Недостатък, защото не можем да си позволим да си купим пакета компилатори, дори след невероятните отстъпки за академиите.

Първата (ми) изнендата дойде с FreeBSD-MD5 модула на JtR, написан изцяло на C и не използващ аритметика с плаваща запетая (обикновено силната страна на Intel XYZ Compiler), където Intel C Compiler v10.0 се провали с гръм и трясък, изоставайки дори от GCC 4.0 на Debian, въпреки нечовешките опити за оптимизация от страна на компилатора. За съжаление резултатите от тогавашния тест, проведен на машина с два Xeon E5335 заминаха с базата данни на сайта и вече не са налични, а ме мързи да ги повтарям, но тогава Sun Studio 12 (200705) убедително поведе класацията.

Другата ми изненада дойде днес, т.е. вече вчера. Имам си аз една боза програма, разработена в Единбург през далечната 2003-та година, когато бях млад, зелен и за първи път писах някакъв научен код. От тогава насам е претърпяла някои малки промени, главно в смяна на броя интервали в отстъпа на блоковите конструкции, но основното изчислително ядро си остава същото - няколко хиляди реда нечетлив код на FORTRAN 77, който (чудващо) се компилира с g77 (GNU), ifort (Intel) и f90 (Sun, на какъвто и беше разработен всъщност). Програмата представлява симулатор на системи от въглеродни атоми, използващ метода на молекулната динамика за решаване на уравненията на движение на отделните атоми в системата. Потенциалната функция е многочастична и трудна за ръчна оптимизация, но включва множество цикли, които подлежат на векторизация на съвременните микропроцесори със SSE2, SSE3 и пр. SIMD инструкции, включващи много букви “S” в началото и разни цифри в края на абревеатурата си. Та въпросната програма често пъти я прекомпилирам с всички налични ми средства за разработка на FORTRAN и сравнявам времето, необходимо за пресмятане на 10 хиляди времеви стъпки на стандартна система - въглеродна нанотръба от 1200 атома. Днес беше поредното сравнение, не особено учудващо (времената са при изпълнение върху Intel Xeon E5335 в 64-битов режим):

  • Intel Fortran Compiler v10.0 (-O3 -xT -ipo) - 33,6 s
  • Sun Forte 200705 (-fast -xarch=sse3 -xchip=pentium4 -xvector=simd) - 38,7 s

Изненадата дойде, след като преодолях мързела си и деинсталирах всички пакети на Sun Studio 12, защото по една или друга причина APT на Scientific Linux смяташе 3 пакета за счупени и трябваше да ги махам преди и инсталирам обратно след всяко обновяване на системата. След като доизтрих останалите непакетни части, инсталирах от tarball обновената версия 200709. Естествено за 4 месеца едва ли нещо се е променило, но въпреки това още една прекомпилация и измерване на времето няма да навреди. И тогава…

  • Sun Forte 200709 (-fast -xarch=sse3 -xchip=pentium4 -xvector=simd) - 28,1 s

WTF?! Трябва да е грешка на time. Повторно пускане и повторение на времето. Прекомпилация и ново повторение. Прекомпилация с Intel-ския компилатор - отново 33,6 s. Резултатите - съвпадат (т.е. никой не лъже с плаващата аритметика или поне и двата компилатора лъжат по един и същ начин).

Този път без фанфари, за разлика от традиционните “Sun <някакъв модел> + Solaris 10 + Sun Studio 12 счупи рекорда на <някакъв тест>” реклами, Sun са вкарали поредната оптимизация, която драматично променя съотношението на силите в бизнеса с плаваща запетая. Така че, поне според мен, повече разработчици следва да обърнат внимание на прекрасния продукт, наречен Sun Studio 12. Освен това от Sun обещават, че на Solaris програмите врървят по-добре ;)

П.П. А отвън духа ураганен вятър…