Portál AbcLinuxu, 25. října 2025 16:28
Původní železo:
Deska: Gigabyte M61PME-S2P
CPU: AMD Athlon(tm) Processor LE-1640
RAM: 2GiB, @800 MHz
Disk: 2x 5400ot/min
Device Model: EcoGreen F2 HD502HI
Serial Number: S1VZJ1BS310211
User Capacity: 500,107,862,016 bytes
SMART hlásí teplotu: 23 (Lifetime Min/Max 18/26)
Tiché neparkující dísky s malým odběrem (<5.5 W)
(Jeden reklamovaný ined po koupi, druhý asi po roku, na základě SMART,
od té doba oba zdravé 3+ roků)
Uspořádání disků: RAID1 (mdadm), LVM
XEN: Domain-0 + 3x virtual, všechny něco sem-tam dělají
včetně Domain-0 (DNS + nezatížený fileserver Samba+NFS4)
Kde: dd if=/dev/urandom of=smaz bs=1048576 count=500sha512sum smazNové železo je (to o čem chci psát):
Deska: Intel S1200BTLR
Zdroj: SSR-450RM, SEASONIC G450 450W 80PLUS GOLD
CPU: Xeon E3-1230V2 BOX 3,30 GHz (chladič: Freezer 7 Pro Rev.2)
RAM: 32GiB, (4× DIMM DDR3 8GB 1333 ECC TRANSCEND CL9 STANDARD)
Disk: 2x WD10EZRX GREEN ... 1TB
2× WD20EFRX RED RAID EDITON ... 2TB
2× ST2000VX000 SEAGATE BARRACUDA ... 2TB
Kde: dd if=/dev/urandom of=smaz bs=1048576 count=500
trvá: 47 sec
a: sha512sum smaz
trvá: 1.6 sec
Celkového odběru (prozatím zjištěného) 55-98 W
Doplněno 2013-03-31: Celkový odběr po uspání 4 disků 39.7 W (hdparm -S 240 /dev/sd[d-f])
A bude tam toho o kus víc než před tím + data budou šifrována a místo OpenSuSe tam bude CentOS a místo XEN-u KVM-ko atd.
Je to v „levné-upravé-lehce-odhlučněné“ bedně (je to trochu slyšet, a výrazně méňe než šum radiátoru)
Už si zde povšimněte, že spotřeba celkové sestavy v idle je nižší, výkon nesrovnatelně vyšší 1 jádro vs. 4 a HT, paměti „trochu“ přibylo a úložný prostor je „o kapánek“ větší.
Základní odběry:
Ve vypnutém stavu <3.5W (PC vypnuto, BMC aktivní) Po zapnutí a nastartování systému: 57 W (po „nechání na pokoji“ 55 W) zatížení jednoho jádra (sha512sum) <=73 W zatížení 4 jader (sha512sum 4×) <=95 W zatížení 4HT jader (sha512sum 8+×) <=98 W (připojený LCD monitor, nezapočítaný do odběru, X-ka běží)Kdo neví, tak BMC (Baseboard Management Controller) je takový „mini-os“, který je aktivní i pokud je vypnutý zdroj, ale pod napětím a přes ethernet se můžete přihlásit a ovládat či sledovat (zapnout/vypnout).
Základní stav(y) z BMC:
Processor Fan 784 RPM Sys Fan 1 686 RPM zadní 120mm Sys Fan 2 686 RPM přední spodní 140mm Sys Fan 3 686 RPM horní přední 120mm BMC Board TEMP 36 °C (pro info limit je 105°C) Board Inlet TEMP 26 °C (pro info limit je 105°C) P1 Therm Margin -74 °CZ nastavením ventilátorů jsem si nehrál ani asi nebudu, zvolil jsem to čemu intel říká „Medium ramp“. Vzhledem k tomu, že při pokusech prozatím jsem zvedl teplotu CPU na max -51 °C, takže jsem zatím ani ventilátory nedostal do dalšího limitu a točí se furt stejně, jak je uvedeno výše.
Pokud Vás mate záporná teplota CPU (byl jsem na to stejně), tak je to teplota „kolik ještě zbývá“ k výrobní maximální hodnotě daného modelu a snad i konkrétního kusu (na první pohled to zní to divně, ale je to vlastně přesně to, co nás zajímá) info třeba tady či rovnou tady (pdf-ko).
Spotřeba disků:
Disk: Idle: Zápis: Celkem při zápisu:
WD10EZRX GREEN 3.7 W + 5.0 W = 8.7 W
WD20EFRX RED 4.0 W + 3.7 W = 8.7 W
ST2000VX000 SEAGATE 5.9 W + 4.0 W = 9.9 W
Celkem po 2 ks: 27.2 W 54.6 W
Je to jen jednoduché měření způsobem: zapojím jen systémový disk, nastartuji OS, chvíli počkám, zapíšu odběr a pak jednotlivé disky připojuji provedu to samé, nakonec dvě hodnoty odečtu.dd z /dev/zero přímo na disk a opět rozdíl hodnot před a při zápisu udává hodnotu. Takže měření nijak zvlášť přesná. Pro měření používám watt-metr Energy Check 3000.
Základní výkonové údaje (z testu):
Read MB/s Write MB/s
Disk: Min: Max: Avg: Min: Max: Avg: Acess:
WD10EZRX GREEN 70 218 118 36 119 66 17.2 ms
WD20EFRX RED 66 168 115 57 146 104 19.9 ms
ST2000VX000 SEAGATE 97 232 178 66 147 118 14.2 ms
V přílohách jsou obrázky výsledků testů.
Ceny s DPH
WD10EZRX GREEN 1509 Kč/Ks 1.62 Kč/GiB WD20EFRX RED 2633 Kč/Ks 1.41 Kč/GiB ST2000VX000 SEAGATE 2400 Kč/Ks 1.29 Kč/GiBCo k tomu říct: „WD je horší než Seagate a proto Seagate končí s klasickými disky a čtení je ekologické, proto GREEN je na tom lépe než RED, přičemž zápis zvládá ± stejně (ano, jsou to jiné kapacity…“
Na první závěr, parkování u GREEN disků:
Věděl jsem, že budu muset něco udělat, ale nečekal jsem, že nebude stačit hdparm.
Po chvíli hraní (několika více hodin provozu) jsem tam měl hodnotu u
193 Load/Unload Cycle Count skoro 900.
hdparm -B hlásí APM level = not suported (mimochodem u všech uvedených disků)
I když ve výpise hdparm -I najdeme * Power managment feature set
Pomocí utility od WD a FreeDOS-u jsem uspěl idle3 bylo nastaveno na „vypnuto“ - tedy konec parkování (maximum šlo nastavit 300 sec), existuje i idle3-tools projekt, ale nezkoušel jsem.
Drobná poznámka: pro uplatnění nové hodnoty musí být disk opravdu na chvilku vypnutý, takže bych „jen“ restart nedoporučoval.
Před přestavením se systém dostával s celkovou spotřebu až k 52 W, po přestavení 55-57 W, jak je uvedeno výše.
Na druhý závěr, ventilátory:
Nejraději používám Artic cooling ventilátory nakupované v TS-Bohemii, ale protože jsem to chtěl osadit jednou 140-kou, která v TS-ce nebyla, tak jsem si koupil červený ventilátor, ale už jsem zas na nějakou dobu vyléčený, dělá oproti a ARCTIC F14 PWM randál, s bednou dodaná 120-ka označená jako tichá, oproti ARCTIC F12 PWM je na to podobně, navíc při vyšších otáčkách plašila myši ultrazvukem, takže nakonec jsem všechny ventilátory zas osadil od Arctic-u a s PWM.
Bohužel Alza má na tyto komponenty docela fuj ceny (o 10 % vyšší než se sluší a až o 20 % vyšší než TS-ka…).
Tiskni
Sdílej:
Hraní s malým serverem I.
Xeon E3 3,30 GHz RAM: 32GiB 2x 1TB 4× 2TB…
dd if=/dev/urandom of=smaz bs=1048576 count=500
conv=fsync
conv=fsync - tady je to asi jedno, protože spíš je to rychlost dávaní, než zapisování (a moc jsem na tím nepřemýšlel). Ale uvědomil jsem si, že v některý připravených věcech (na ty testy) mám oflag=sync a teď vlastně nevím jaký je v tom rozdíl.
.
conv=fsync provede fsync nakonec, ale oflag=sync asi po každém bs.
, ten výkon bude využitý jen opravdu ojediněle, ale předchozí uvedené železo je semo-tamo nedostatečné a má radikálně nedostatečnou diskovou kapacitu (a musel by tam jít nový řadič) a nedostatečnou paměť (kde toho už moc udělat nelze), a za chvílí se tam možná začnou šklebit kondíky… $ time dd if=/dev/urandom of=smaz bs=1048576 count=500 500+0 records in 500+0 records out 524288000 bytes (524 MB) copied, 39.0765 s, 13.4 MB/s real 0m39.078s user 0m0.003s sys 0m38.990s2 roky stary desktop s Core i3-2100; 2x3.1GHz; bez TurboBoost. Disk asi 3-4 roky stary WD Green 1TB, 5400rpm. sha512sum uz hadze tak nejak ocakavane vysledky:
$ time sha512sum smaz 33c85bac1e5eb6...271eddcc smaz real 0m2.188s user 0m2.140s sys 0m0.043s
Nieco ti tam asi hnije, alebo ten RAID zerie viac, nez by som cakal:To mu hnije spíš urandom, tohle se přece vejde do cache.
~ # time dd if=/dev/urandom of=nesmaz bs=1048576 count=500 500+0 records in 500+0 records out 524288000 bytes (524 MB) copied, 57,4556 s, 9,1 MB/s real 0m57.488s user 0m0.000s sys 0m57.324s ~ # time sha512sum nesmaz 33c85bac1e5eb6...271eddcc nesmaz real 0m2.975s user 0m2.888s sys 0m0.080s ~ # time dd if=/dev/urandom of=/dev/null bs=1048576 count=500 500+0 records in 500+0 records out 524288000 bytes (524 MB) copied, 56,4191 s, 9,3 MB/s real 0m56.422s user 0m0.000s sys 0m56.376sCore i3, notebook, šifrovaný disk.
time dd if=/dev/urandom of=smaz bs=1048576 count=500 500+0 records in 500+0 records out 524288000 bytes (524 MB) copied, 57.7799 s, 9.1 MB/s real 0m57.782s user 0m0.000s sys 0m53.927sNa NE-šifrovanou partition:
time dd if=/dev/urandom of=/tests/imega/smaz bs=1048576 count=500 500+0 records in 500+0 records out 524288000 bytes (524 MB) copied, 54.0388 s, 9.7 MB/s real 0m54.041s user 0m0.000s sys 0m53.419sOpakovaně se to mění až v 10 %. (A při detailním sledování v průběhu, vidím, že někdy se zatížení CPU sníží a někdy i přeskočí z jádra na jádro…)
time dd if=/dev/urandom of=/dev/null bs=1048576 count=500 500+0 records in 500+0 records out 524288000 bytes (524 MB) copied, 55.1809 s, 9.5 MB/s real 0m55.183s user 0m0.000s sys 0m55.083sA jak vidno z diskem to nemá mnoho společného.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.