HOWTO: otestujte si pocitac ..

[slamozrout]

Kód: [Vybrat]

[slamik@myhost ~]$ bash version-check.sh
bash, version 3.2.39(1)-release
/bin/sh -> /bin/bash
Binutils: (GNU Binutils) 2.18.0.20080610
bison (GNU Bison) 2.3
/usr/bin/yacc -> /usr/bin/yacc
bzip2,  Version 1.0.5, 10-Dec-2007.
Coreutils:  6.12
diff (GNU diffutils) 2.8.1
find (GNU findutils) 4.4.0
GNU Awk 3.1.6
awk not found
gcc (GCC) 4.3.2
GNU C Library stable release version 2.8,
GNU grep 2.5.3
gzip 1.3.12
Linux version 2.6.26-ARCH (root@T-POWA-LX) (gcc version 4.3.2 (GCC) ) #1 SMP PREEMPT Tue Sep 9 09:56:28 UTC 2008
GNU Make 3.81
patch 2.5.9
GNU sed version 4.1.5
tar (GNU tar) 1.20
makeinfo (GNU texinfo) 4.13


[nettezzaumana]

4quejky :: haha .. az na jeden pripad to pokud nemame stejny, tak mam novejsi verze .. njn. i ten debian testing laguje
4*buntaci :: no .. vy to zase mate trocha novejsi temer vse nez ja

[qUAKER]

no mě nevadí že to mám starší pokud to funguje
a vzhledem k tomu, že jsem zatím neměl jediný problém, mi nevadí, že mám od některých věcí trošku starší verze..

[hase]

[palo@localhost ~]$ bash version-check.sh
bash, version 3.2.19(2)-release
/bin/sh -> /bin/bash
Binutils: version-check.sh: line 8: ld: command not found
version-check.sh: line 9: bison: command not found
yacc not found
bzip2,  Version 1.0.5, 10-Dec-2007.
Coreutils:  6.10
diff (GNU diffutils) 2.8.7
GNU find version 4.2.33
GNU Awk 3.1.5
/usr/bin/awk -> /bin/gawk
version-check.sh: line 19: gcc: command not found
GNU C Library stable release version 2.7,
GNU grep 2.5.3
gzip 1.3.12
Linux version 2.6.24.7-desktop-1mnb (qateam@titan.mandriva.com) (gcc version 4.2.3 (4.2.3-6mnb1)) #1 SMP Mon Jul 28 15:12:10 EDT 2008
version-check.sh: line 24: make: command not found
patch 2.5.9
GNU sed version 4.1.5
tar (GNU tar) 1.19
version-check.sh: line 28: makeinfo: command not found
[palo@localhost ~]$

nieco tam asi hapruje...

[Martin Kiklhorn]

II včetně dnešních aktualizací

Kód: [Vybrat]

xenie@san1:~# uname -a
Linux san1 2.6.27-6-server #1 SMP Tue Oct 7 05:00:08 UTC 2008 i686 GNU/Linux
xenie@san1:~# bash version-check.sh
bash, version 3.2.39(1)-release
/bin/sh -> /bin/dash
Binutils: (GNU Binutils for Ubuntu) 2.18.93.20081009
bison (GNU Bison) 2.3
/usr/bin/yacc -> /usr/bin/yacc
bzip2,  Version 1.0.5, 10-Dec-2007.
Coreutils:  6.10
diff (GNU diffutils) 2.8.1
find (GNU findutils) 4.4.0
GNU Awk 3.1.6
/usr/bin/awk -> /usr/bin/mawk
gcc (Ubuntu 4.3.2-1ubuntu10) 4.3.2
GNU C Library development release version 2.8.90,
GNU grep 2.5.3
gzip 1.3.12
Linux version 2.6.27-6-server (buildd@palmer) (gcc version 4.3.2 (Ubuntu 4.3.2-1ubuntu9) ) #1 SMP Tue Oct 7 05:00:08 UTC 2008
GNU Make 3.81
patch 2.5.9
GNU sed version 4.1.5
tar (GNU tar) 1.20
makeinfo (GNU texinfo) 4.11

[Martin Kiklhorn]

test na starém P4 (HT) - disk je super rychlý na to že jdu proti iSCSI na PC s jen 100mbit síťovkou

Kód: [Vybrat]

root@asterisk:/mnt/testdisk# time (dd if=/dev/zero of=xx.file bs=1048576 count=1000 && sync)
1000+0 records in
1000+0 records out
1048576000 bytes (1,0 GB) copied, 87,0218 s, 12,0 MB/s

real    1m31.048s
user    0m0.000s
sys     0m6.110s
root@asterisk:/mnt/testdisk# time dd if=/dev/urandom of=/dev/null bs=1048576 count=100
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 23,8612 s, 4,4 MB/s

real    0m23.892s
user    0m0.010s
sys     0m23.860s
root@asterisk:/mnt/testdisk# time dd if=/dev/zero of=/dev/null bs=1048576 count=100000
100000+0 records in
100000+0 records out
104857600000 bytes (105 GB) copied, 20,5372 s, 5,1 GB/s

real    0m20.540s
user    0m0.030s
sys     0m20.510s
root@asterisk:/mnt/testdisk# uname -a
Linux asterisk.vu2508.cz 2.6.24-19-server #1 SMP Wed Aug 20 23:54:28 UTC 2008 i686 GNU/Linux
root@asterisk:/mnt/testdisk# cat /proc/cpuinfo | grep model
model           : 4
model name      : Intel(R) Pentium(R) 4 CPU 3.00GHz
model           : 4
model name      : Intel(R) Pentium(R) 4 CPU 3.00GHz
root@asterisk:/mnt/testdisk#
//edit:
a ještě PC s gigovou síťovkou

Kód: [Vybrat]

alfa:/mnt/testdisk# time (dd if=/dev/zero of=xx.file bs=1048576 count=1000 && sync)
1000+0 records in
1000+0 records out
1048576000 bytes (1.0 GB) copied, 2.02291 seconds, 518 MB/s

real    0m15.707s
user    0m0.000s
sys     0m2.420s
alfa:/mnt/testdisk# du -m xx.file
1001    xx.file
alfa:/mnt/testdisk# perl -e 'print 1001 / 15.707 ." Mb\\sec\n";'                       
63.7295473355829 Mb\sec
na tomhle vidím jak šílený je IP stack ve Windows kde se proti stejnému targetu při opakovaných testech pohybuji v rozmezí 27-36MB/s
Target je 2x Raptor WD74 v SW Raid1, nad tím LVM a nad tím IET iSCSI vrstva a formátovaný ext3.

[Martin Kiklhorn]

A když jsme u toho měření rychlosti - prokletí mého HW raid řadiče LSI MegaRAID SATA 300-8X
Zkusil jsem si udělat další target s sedmi disky v HW raid5 na uvedeném řadiči (koupen někdy na přelomu 2004/2005, dnes v cenících kolem 10.000,-). Při měření jsem se dostával pouze na jednotky MB/s (Raid 1 je OK, viz minulý příspěvek) a začal jsem hledat kde může být chyba.
HW raid 5 jsem zrušil, vytvořil jsem na úrovni řadiče 7x samostatný logický disk a následně jsem z nich vytvořil softwarový Raid 6
Zápis na SW Raid 6 více než desetinásobně rychlejší (81MB/s) oproti HW Raid 5.
Chtěl jsem také otestovat chování při chybách disků tak jsem jeden z disků dočasně odpojil a znovu připojil abych dostal rozsynchronizované pole, v průběhu synchronizace jsem odpojil jiný disk - takže se pole nachází ve stavu
Active & degraded & recovering & synchronizing - a na tomto jsem opět spustil test. 35 MB/s
Zatížení procesoru (HT P4/3GHz) se v tomto stavu osciluje kolem 90% (počítá toho celkem dost - stav pole a je to raid 6)

Následně jsem našel testy tohoto řadiče, jeho XOR procesor hrubě nestíhá ani při nedegradovaném raid 5.
testy zde: http://www.xbitlabs.com/articles/storage/display/lsi-megaraid300-8x_20.html

Takže ne vždy se dá věřit údajům výrobce a ne vždy je HW Raid výhrou.

[nettezzaumana]

4 kikihorn .. hmm .. mas opravdu po vsech smerech pozoruhodne kousky zeleza

ad.1) zkousel jsem to delat ve vice vlaknech (teda ty propustnosti sbernic a hlavne proc) a tam jsou vysledky taky pomerne zajimave ..

na x86 pod linuxem ve 20ti vlaknech jsem to co normalne v jednom trva minutu asi po pul hodine musel pozabijet .. totalni konec ..
na sparcu (t5240) na Solarisu to same probehlo asi s 20% spozdenim, pricemz jedno vlakno melo vykonovy pokles asi o pouhych 10% ..

ps. delal jsem to takhle ::

time for ((x=0;x<20;x++)) { foo() &; } // pricemz ve foo() jsem si jeste jednotlive cykly logoval pomoci `tee` i zvlast

[Martin Kiklhorn]

Linux alfa 2.6.18.8-xen #1 SMP Tue Sep 30 07:53:31 CEST 2008 x86_64 GNU/Linux
Mám osm jader, udělám si nějaké testy, celkovou propustnost spočítám poctivě ze všech výsledků (z důvodu délky všechny nevypisuji)
Tak jedno vlákno

Kód: [Vybrat]

time dd if=/dev/urandom of=/dev/null bs=1048576 count=100 &
104857600 bytes (105 MB) copied, 15.1978 seconds, 6.9 MB/sjedno vlákno: = 6,9 MB/s
dvě: 2x3,7 = 7,4 MB/s
tří: 3x2,5 = 7,5 MB/s
čtyři: 5,8 MB/s
pět: 4,9 MB/s
šest: 4,7 MB/s
pustím to na sedmi

Kód: [Vybrat]

time for ((x=0;x<7;x++)) { dd if=/dev/urandom of=/dev/null bs=1048576 count=100 & }
104857600 bytes (105 MB) copied, 119.541 seconds, 877 kB/s
104857600 bytes (105 MB) copied, 188.816 seconds, 555 kB/s
104857600 bytes (105 MB) copied, 188.76 seconds, 556 kB/s
104857600 bytes (105 MB) copied, 203.095 seconds, 516 kB/s
104857600 bytes (105 MB) copied, 203.233 seconds, 516 kB/s
104857600 bytes (105 MB) copied, 204.967 seconds, 512 kB/s
104857600 bytes (105 MB) copied, 205.266 seconds, 511 kB/s4 MB/s
Je to dlouhé, zkusím s menším objemem dat, přesnost klesne ale nemělo by to mít velký vliv ?

Kód: [Vybrat]

for ((x=0;x<7;x++)) { dd if=/dev/urandom of=/dev/null bs=1048576 count=10 & }
10485760 bytes (10 MB) copied, 12.2736 seconds, 854 kB/s
10485760 bytes (10 MB) copied, 18.4268 seconds, 569 kB/s
10485760 bytes (10 MB) copied, 18.7979 seconds, 558 kB/s
10485760 bytes (10 MB) copied, 19.1058 seconds, 549 kB/s
10485760 bytes (10 MB) copied, 20.17 seconds, 520 kB/s
10485760 bytes (10 MB) copied, 20.4013 seconds, 514 kB/s
10485760 bytes (10 MB) copied, 20.4878 seconds, 512 kB/s4 MB/s
Velký vliv to nemá, pustím osm vláken

Kód: [Vybrat]

for ((x=0;x<8;x++)) { dd if=/dev/urandom of=/dev/null bs=1048576 count=10 & }
10485760 bytes (10 MB) copied, 29.4299 seconds, 356 kB/s
10485760 bytes (10 MB) copied, 31.2589 seconds, 335 kB/s
10485760 bytes (10 MB) copied, 30.6556 seconds, 342 kB/s
10485760 bytes (10 MB) copied, 31.2022 seconds, 336 kB/s
10485760 bytes (10 MB) copied, 32.3281 seconds, 324 kB/s
10485760 bytes (10 MB) copied, 32.6528 seconds, 321 kB/s
10485760 bytes (10 MB) copied, 32.2793 seconds, 325 kB/s
10485760 bytes (10 MB) copied, 32.231 seconds, 325 kB/s~= 2,6MB/s
Pustím to v 40ti  vláknech

Kód: [Vybrat]

10485760 bytes (10 MB) copied, 157.93 seconds, 66.4 kB/s
10485760 bytes (10 MB) copied, 162.303 seconds, 64.6 kB/s
..
10485760 bytes (10 MB) copied, 173.421 seconds, 60.5 kB/s
..
10485760 bytes (10 MB) copied, 196.165 seconds, 53.5 kB/s
2,3MB/s
Při tomto počtu vidím už lineární závislost ? - odhadem - 5x více vláken = 5x pomalejší
Je to pravda? Pokud bych pustil 400 vláken tak by to mělo trvat jen něco přes půl hodiny. No zkusím, stejně musím na chvilku pryč.

Kód: [Vybrat]

10485760 bytes (10 MB) copied, 1446.95 seconds, 7.2 kB/s
...
10485760 bytes (10 MB) copied, 1590.4 seconds, 6.6 kB/s
...
10485760 bytes (10 MB) copied, 1930.92 seconds, 5.4 kB/s= 2,4MB/s

[nettezzaumana]

hmm .. pozoruhodne vysledky .. no rekl bych, ze to 10ti mego na urandom muze stacit, ale cista generace aka /dev/zero toho vyprodukuje mnohem vic ..

taky to jeste zejtra prozenu ..

[Martin Kiklhorn]

FSB - Dostávám zajímavé výsledky v závislosti na jádře:
(2PC s identickým HW) počet threadů 1 až 90

for ((x=0;x<90;x++)) { time dd if=/dev/zero of=/dev/null bs=1048576 count=10000 & }

uname -a
Linux alfa 2.6.18.8-xen #1 SMP Tue Sep 30 07:53:31 CEST 2008 x86_64 GNU/Linux
time dd if=/dev/zero of=/dev/null bs=1048576 count=10000
1, 10485760000 bytes (10 GB) copied, 2.99504 seconds, 3.5 GB/s = 3,5 GB/s
2, 10485760000 bytes (10 GB) copied, 4.59596 seconds, 2.3 GB/s = 4,6 GB/s
3, 10485760000 bytes (10 GB) copied, 4.96224 seconds, 2.1 GB/s = 6,2 GB/s
4, 10485760000 bytes (10 GB) copied, 5.77682 seconds, 1.8 GB/s = 7,2 GB/s
5, 10485760000 bytes (10 GB) copied, 6.10528 seconds, 1.7 GB/s = 8,5 GB/s
6, 10485760000 bytes (10 GB) copied, 7.2217 seconds, 1.5 GB/s = 9 GB/s
7, 10485760000 bytes (10 GB) copied, 9.30288 seconds, 1.1 GB/s = 7,7 GB/s
8, 10485760000 bytes (10 GB) copied, 11.1839 seconds, 0,94 = 7.5 GB/s
9, 10485760000 bytes (10 GB) copied, 12.1225 seconds, 0,85 (0.76-0.95) = 7,7 GB/s
90, 10485760000 bytes (10 GB) copied, 127.107 seconds, 0,08 (0.07-0.08) = 7,2 GB/s by woko

uname -a
Linux astra 2.6.26-1-amd64 #1 SMP Wed Sep 10 15:31:12 UTC 2008 x86_64 GNU/Linux
1, 10485760000 bytes (10 GB) copied, 0.995522 s, 10.5 GB/s = 10.5 GB/s
2, 10485760000 bytes (10 GB) copied, 0.994499 s, 10.6 GB/s = 21.2 GB/s
3, 10485760000 bytes (10 GB) copied, 0.977325 s, 10.7 GB/s = 32.1 GB/s
4, 10485760000 bytes (10 GB) copied, 0.99796 s, 8,97 (7,8-10.5) = 35,9 GB/s
5, 10485760000 bytes (10 GB) copied, 0.977671 s, 9,58 (8.1-10,7) = 47,9 GB/s
6, 10485760000 bytes (10 GB) copied, 0.999366 s, 8,93 (8,1-10.5) = 53,6 GB/s
7, 10485760000 bytes (10 GB) copied, 0.999054 s, 8,44 (8,1-10.5) = 59,1 GB/s
8, 10485760000 bytes (10 GB) copied, 1.27825 s, 8.2 GB/s = 65,6 GB/s
9, 10485760000 bytes (10 GB) copied, 1.28976 s, 7,13 (5.9-8,1) = 64,2 GB/s
90, 10485760000 bytes (10 GB) copied, 13.8611 s, 0,74 (0,7-0,8) = 66,6 GB/s by woko

a pro porovnání zopakuji na tomto stroji alespoň jeden minulý test CPU ve 40ti vláknech

Kód: [Vybrat]

for ((x=0;x<40;x++)) { dd if=/dev/urandom of=/dev/null bs=1048576 count=10 & }
10485760 bytes (10 MB) copied, 93.7754 s, 112 kB/s
..
10485760 bytes (10 MB) copied, 94.3177 s, 111 kB/s= 4,44 MB/s (na 2.6.18-8-xen 2,3MB/s)

[Martin Kiklhorn]

Tak nakonec místo plánovaného X25-E 64GB (papírově R/W 250/170 MBps), mám úspornější Intel SSD X25-M 80GB (papírově R/W 250/70 MBps)

Kód: [Vybrat]

a3-ntb% hwinfo --disk --short
disk:                                                           
  /dev/sda             INTEL SSDSA2MH08
a3-ntb% time (dd if=/dev/zero of=xx.file bs=1048576 count=1000 && sync)
1000+0 vstoupivších záznamů
1000+0 vystoupivších záznamů
1 048 576 000 bajtů (1,0 GB) zkopírováno, 11,1811 s, 93,8 MB/s
(; dd if=/dev/zero of=xx.file bs=1048576 count=1000 && sync; )  0,00s user 5,67s system 37% cpu 15,098 total
a3-ntb% echo $((1048576000/15.098/1024/1024)) MB/s
66.233938269969528 MB/s
a3-ntb% time dd of=/dev/null if=xx.file bs=1048576       
1000+0 vstoupivších záznamů
1000+0 vystoupivších záznamů
1 048 576 000 bajtů (1,0 GB) zkopírováno, 6,711 s, 156 MB/s
dd of=/dev/null if=xx.file bs=1048576 count=1000  0,01s user 1,41s system 21% cpu 6,717 total
a3-ntb% echo $((1048576000/6.717/1024/1024)) MB/s
148.87598630340926 MB/s
a3-ntb% time dd of=/dev/null if=xx.file bs=1048576
1000+0 vstoupivších záznamů
1000+0 vystoupivších záznamů
1 048 576 000 bajtů (1,0 GB) zkopírováno, 1,59176 s, 659 MB/s
dd of=/dev/null if=xx.file bs=1048576 count=1000  0,00s user 1,20s system 74% cpu 1,597 total
a3-ntb% echo $((1048576000/1.597/1024/1024)) MB/s                 
626.17407639323733 MB/s
a3-ntb% time dd of=/dev/null if=xx.file bs=1048576           
1000+0 vstoupivších záznamů
1000+0 vystoupivších záznamů
1 048 576 000 bajtů (1,0 GB) zkopírováno, 1,14877 s, 913 MB/s
dd of=/dev/null if=xx.file bs=1048576  0,00s user 1,14s system 99% cpu 1,154 total
a3-ntb% echo $((1048576000/1.154/1024/1024)) MB/s   
866.55112651646459 MB/s
Zajímavý pohled na opakované čtení...
Že by překonával rychlost sata...
Nebo Linux skvěle cachuje?