V závěrečném díle o testování 64bitového Linuxu na serveru se dvěma
dvou-jadernými Opterony se podíváme trošku blíže na hardware a na malé testy
výkonnosti.
26.9.2005 06:00 | Ondřej Čečák | přečteno 14493×
Tak, pojďme rovnou k věci:
Přímo na desce je integrovaný ("integrace" je kvůli volnému místu
vyřešena, jak si všiml Aleš Hakl, docela zajímavě –
vlastní karta
je umístěna "nad" deskou) řadič Adaptec Serial
ATA RAID 2410S, pro který je podpora přímo v jádře díky driveru
acc-raid
, který funguje dle očekávání. V BIOSu řadiče si můžete
snadno definovat umístění disků do jednotlivých volumes, nebo do RAIDu 0, 1,
5. U RAIDu si také můžete samozřejmě určit velikost bloků.
Pro jednotlivé svazky můžete určit, zda používat nebo nepoužívat write-back cache (tedy vyrovnávací paměť řadiče a případně také zařízení pro zapisování). Zdá se, že karta řadiče nějakou baterii má, ovšem v případě zatrhnutí write-back se BIOS ptá, zda si jste skutečně jistí svojí volbou, která může vést až ke ztrátě dat.
V případě, že by vám hardwarový RAID neseděl (zaslechl jsem, že u tohoto řadiče spíše nelze doporučit) vám samozřejmě nic nebrání v použití klasického softwarového.
Když už jsem měl disky v hardwarovém RAIDu, zkoušel jsem SATA hot-swap, bohužel se mi nedařilo disk po výměně korektně připojit pomocí linuxového SCSI subsystému.
O stavu hardware se můžete dozvědět díky programu lm-sensors, který využívá I2C ovladače
jádra. Autodetekční skript sensors-detect
proběhl dobře až na
detail, který je zrovna dost podstatný – pravděpodobně kvůli chybějícímu
driveru (vanilla 2.6.13) pro chip Winbond není možné monitorovat teplotu, případně rychlost větráčků.
Je možné, že existuje patch mimo vanillu, nebo že lze sensory sledovat s upravenou konfigurací nebo přes ACPI, to jsem bohužel nevyzkoušel kvůli omezenému času testování. Také je možné, že přes ACPI nebo lm-sensors lze sledovat stav čidla pro detekci otevření case.
Výstup programu lm-sensors:
quadro:~# sensors
w83627hf-isa-0290
Adapter: ISA adapter
VCore 1: +4.08 V (min = +1.47 V, max = +1.63 V)
VCore 2: +4.08 V (min = +1.47 V, max = +1.63 V)
+3.3V: +4.08 V (min = +3.14 V, max = +3.47 V)
+5V: +5.16 V (min = +4.76 V, max = +5.24 V)
+12V: +11.73 V (min = +10.82 V, max = +13.19 V)
-12V: +0.96 V (min = -13.18 V, max = -10.80 V)
-5V: +2.09 V (min = -5.25 V, max = -4.75 V)
V5SB: +5.48 V (min = +4.76 V, max = +5.24 V)
VBat: +2.05 V (min = +2.40 V, max = +3.60 V)
fan1: 0 RPM (min = 2848 RPM, div = 2)
fan2: 0 RPM (min = 2848 RPM, div = 2)
fan3: 0 RPM (min = 6081 RPM, div = 2)
temp1: -48°C (high = +120°C, hyst = +115°C) sensor = thermistor
temp2: -48.0°C (high = +80°C, hyst = +75°C) sensor = thermistor
temp3: -48.0°C (high = +80°C, hyst = +75°C) sensor = thermistor
vid: +1.550 V (VRM Version 2.4)
alarms:
beep_enable:
Sound alarm disabled
eeprom-i2c-0-53
Adapter: SMBus AMD8111 adapter at 50e0
Memory type: DDR SDRAM DIMM
Memory size (MB): 1024
eeprom-i2c-0-52
Adapter: SMBus AMD8111 adapter at 50e0
Memory type: DDR SDRAM DIMM
Memory size (MB): 1024
Další zajímavou vlastností desky (chipsetu od AMD) je generování opravdu náhodných čísel. V
jádře je za to zodpovědný modul hw_random
, jehož výstup je v
/dev/hwrandom
(pokud máte statický /dev/
, vytvoříte
zařízení snadno příkazem mknod /dev/hwrandom c 10 183
).
V Debianu také doporučuji nainstalovat balíček rng-tools
, který
obsahuje daemona pro čtení náhodných dat ze speciálního zařízení a jejich
předávání do /dev/random
(v ostatních distribucích se může název
lišit, nebo balík nemusí být zahrnut do standardní distribuce, v tom případě
si program můžete snadno stáhnout ze stránek projektu).
Podobně jako u článku o Debianu na Dual Opteronu jsem provedl několik jednoduchých testů rychlosti (testy byly prováděny stejným způsobem, takže se nabízí případné orientační srovnání).
# rozbalení zdrojových kódů time tar xjf linux-2.6.12.4.tar.bz2 real 0m18.309s user 0m14.145s sys 0m1.648s # komprimace souboru obsahující samé nuly s velikosti 512 MB time bzip2 file real 0m17.090s user 0m16.433s sys 0m0.656s
Test překladu jádra jsem dělal se stejným .configem
a také jsem zkoušel, do jaké míry se vyplatí spouštět simultánně kompilaci.
Zvýšení proměnné CONCURRENCY_LEVEL
mělo praktický smysl pouze do
hodnoty o jednu větší než byl celkový počet jader.
time CONCURRENCY_LEVEL="1" make-kpkg --revision benchmark.1 kernel_image real 10m1.874s user 8m37.552s sys 1m29.974s time CONCURRENCY_LEVEL="2" make-kpkg --revision benchmark.1 kernel_image real 5m14.060s user 8m39.068s sys 1m33.094s time CONCURRENCY_LEVEL="3" make-kpkg --revision benchmark.1 kernel_image real 3m40.376s user 8m39.452s sys 1m35.374s time CONCURRENCY_LEVEL="4" make-kpkg --revision benchmark.1 kernel_image real 3m23.285s user 8m42.613s sys 1m35.834s time CONCURRENCY_LEVEL="5" make-kpkg --revision benchmark.1 kernel_image real 2m56.068s user 8m46.469s sys 1m39.606s
Podobně jako minule jsem spustil syntetický test Opstone Vector Scalar-Product Benchmark prostřednictvím binárního programu optimalizovaného pro AMD Opteron (tedy 64-bit a instrukční sady SSE a SSE2), který měl otestovat výkon operací v plovoucí čárce. Ve 32bitech dosáhl 3,30 Gflops (6,29 špička), v 64bitech 1,60 Gflops (2,90 špička). Při porovnání s Opteronem s taktem 1,7 GHz (testovaný je taktován na 2,2 GHz) je výkon zhruba přímo úměrný frekvenci.
Na testované sestavě by se také pěkně louskala unixová hesla, John The Ripper při benchmarku naměřil pěkných 4410 pokusů za vteřinu na jeden procesor. (jde už o čisté pokusy, ve kterých jsou započítány transformace s různou solí (salt))
quadro:~# john --test
Benchmarking: Standard DES [64/64 BS]... DONE
Many salts: 499909 c/s real, 499314 c/s virtual
Only one salt: 473925 c/s real, 474461 c/s virtual
Benchmarking: BSDI DES (x725) [64/64 BS]... DONE
Many salts: 17260 c/s real, 17260 c/s virtual
Only one salt: 17102 c/s real, 17102 c/s virtual
Benchmarking: FreeBSD MD5 [32/64]... DONE
Raw: 4416 c/s real, 4410 c/s virtual
Benchmarking: OpenBSD Blowfish (x32) [32/64]... DONE
Raw: 360 c/s real, 360 c/s virtual
Benchmarking: Kerberos AFS DES [48/64 4K]... DONE
Short: 308367 c/s real, 308367 c/s virtual
Long: 856828 c/s real, 856828 c/s virtual
Benchmarking: NT LM DES [48/64 4K]... DONE
Raw: 2633775 c/s real, 2629647 c/s virtual
Pěkně dopadl test rychlosti OpenSSL:
quadro:~# openssl speed rsa1024
Doing 1024 bit private rsa's for 10s: 13799 1024 bit private RSA's in 10.01s
Doing 1024 bit public rsa's for 10s: 222986 1024 bit public RSA's in 10.00s
OpenSSL 0.9.7e 25 Oct 2004
built on: Sat Dec 18 09:38:01 CET 2004
options:bn(64,64) md2(int) rc4(ptr,char) des(idx,cisc,16,int) aes(partial)
blowfish(ptr2)
compiler: gcc -fPIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H
-DOPENSSL_NO_KRB5 -DOPENSSL_NO_IDEA -DOPENSSL_NO_MDC2 -DOPENSSL_NO_RC5 -m64
-DL_ENDIAN -DTERMIO -O3 -Wall -DMD32_REG_T=int
available timing options: TIMES TIMEB HZ=100 [sysconf value]
timing function used: times
sign verify sign/s verify/s
rsa 1024 bits 0.0007s 0.0000s 1378.5 22298.6
Při zatížení jednoho procesoru není výsledek nijak oslňující, ale pokud spustíte test paralelně ve čtyřech instancích:
quadro:~# openssl speed rsa1024 < openssl1.out & openssl speed rsa1024 <
openssl2.out & openssl speed rsa1024 < openssl3.out & openssl speed
rsa1024 < openssl4.out &
Dostanete přibližně 4x lepší výsledek – průměrně 5471,5 podepsání za sekundu a 89233,2 ověření za sekundu u 1024 bitového RSA.
Porovnání výsledku sestavy s dvěma dual-core Opterony @ 2,2 GHz a sestavy s dvěma Opterony @ 1,7 GHz.
Na závěr jsem spustil databázový test DBD z MySQL pro MySQL a PostgreSQL s výchozím nastavením (výsledek pro MySQL, PostgreSQL). Důležité je zmínit, že tento test nelze použít pro srovnání, která z databází je rychlejší.
Sestava s Dual-core dual Opteronem se během testování chovala dle očekávání až na jeden podivný kernel ops, který zřejmě způsobila chyba v jádře vanilla 2.6.13 a kterou už jsem nedokázal později vyvolat. Stroj byl velice svižný a Linux na něm běží vyjma divné chyby naprosto bez problémů.