HPC2009 - under heavy load

burnMMX osszesen 712 peldanyban inditva

a gep mert fogyasztasa 9.3 kW.

ez a tesztterheles nagyjabol hetfoig marad, addig deruljenek ki a klimatechnikai, aramellatasi problemak.

712=44 cnode * 8 mag * 2 hyperthread + 1 hnode * 8 mag

csak bele kellett nyulni az initrd-be...

kellett egy joliranyzott 

sleep 6

az 

ipconfig -t 60 -c dhcp -i ${DEVICE}

sor ele.

hat akkor 2010-ben sem tart ott a vilag, hogy a debijan out of box tudjon nfsrootot.

( bambano | 2010. 04. 23., p – 16:33 )

a switchek nem szoktak ott tartani 2010-ben, hogy elég hamar összelinkeljenek egy frissiben felhúzott interfésszel. nem debian probléma.

Hmm... akkor viszont az initramfs-bol kell machinalni. Valamelyik linux (mandriva talan?)
loopban probalkozik ha nfs root van, egy csomo ideig var (hogy pontosan meddig, azt nem tudom, mert vmware alatt tudtam, hogy nem szabad varakoznia, mint kiderult, zavar volt az eroben a szerver oldalan).
-- 


()=() Ki oda vagyik,
('Y') hol szall a galamb
C . C elszalasztja a
()_() kincset itt alant.

ez itt linux kernel internal bug valahol. Az eth0 feljon (kartya inicializalik, /sys/class/net/eth0 megjelenik stb) de valami ioctl meg nem mukodik azonnal, mert az ipconfig/ifconfig nem latja a devicet (no such). Azert mondom, hogy initramfs hiba is, mert igazan varhatna egy kicsit, semmifele hibakezeles nincs benne (ha az ipconfig elesik, akkor elesik vele egyutt az initramfs is). Illene egy sikeres futas ellenorzest tenni az ipconfig hivas utan. A root dev megjelenesehez varakozik, ott van ellenorzes, az ipconfig utan nincs.

arra emlékszem, hogy amikor összedobtam egy pxe install környezetet, akkor a filléres buta switchel pikkpakk ment, amikor kikerült a minőségi cisco switches környezetbe, akkor meg nem... ott volt gyári workaround, valami etherwait vagy milyen paramétert kellett beállítani.

no, kotorászok a weben a memóriám után és azt látom, hogy debian preseed file változóban lehet egy kis várakozást állítani, és lehet a kernelnek preseed paramétereket is átadni, szóval ezt még előkeresem mindjárt.

( egeresz | 2010. 04. 23., p – 23:16 )

azt mondja a modprobe coretemp; sensors; hogy 60-70 fok minden cpumag.

picit sokallom, bar eloirt tartomanyon belul van. elvileg 76 fokig birja.

( egeresz | 2010. 04. 25., v – 16:18 )

Itt egy grafikon. homerseklet-eloszlas a magok kozott, avagy hany darab 71 fokos mag van, hany darab 70 fokos esigytovabb.

A 'thermalgraph1..4' az 4 kulonbzo idopontban tortent lekerdezes. Nincs koztuk lenyegi kulonbseg, egy megallpitom, hogy a rendszer 2 nap alatt nem melegszik tul, es nincsen huzamosabb hasznalat miatti tulmelegedesi jel.

( egeresz | 2010. 05. 05., sze – 16:11 )

hehe, a john-the-rippernek nagyobb a teljes aramfogyasztasa, mint a cpuburn -nak.
nem sokkal, a teljes clusterre mintegy 500 wattal tobb a john, mint a cpuburn.

( egeresz | 2010. 05. 06., cs – 11:23 )

itt egy homerseklet-grafikon

hogy szoktatok ezt csinalni?
irtam egy scriptet, ami felorankent kiadja magabol ezt a 4 erteket (min, max, avg, stdev) es kellene egy jofajta weboldal, ahol ez heti, havi, es totalban megvan, mint ahogy az mrtg vagymi.