|
TwojePC.pl © 2001 - 2025
|
 |
A R C H I W A L N A W I A D O M O Ś Ć |
 |
| |
|
Kontroler HDD SiS - wydajnosc pod Linuksem , gorky 15/08/05 19:23
to jest w zasadzie odpowiedz na posta davera i kontynuacja watku, ktory juz znika nisko i za chwile bym o nim zapomnial...
pytanie zostalo zadane tutaj: http://twojepc.pl/boardPytanie98198.htm#14
Problemow nie zauwazylem (tj. nie narzekam na szybkosc/obciazenie procesora).
Ale zapodalem maly tescik. Wszystkie programy i kernel instalowane z rpm'ow PLD (optymalizacja dla Athlona, jadro bardzo silnie patchowane).
Na poczatek informacje ogolne:
mam dwa dyski:
hda to Seagate Barracuda IV 40GB, 2 MB cache,
hdb to Samsung SpinPoint 160GB z cache 8MB
hdparm /dev/hda:
multcount = 16 (on)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 65535/16/63, sectors = 78165360, start = 0
hdparm /dev/hdb
multcount = 16 (on)
IO_support = 0 (default 16-bit)
unmaskirq = 0 (off)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 19457/255/63, sectors = 312581808, start = 0
Teraz pare suchych testow:
hdparm -t /dev/hda
/dev/hda:
Timing buffered disk reads: 120 MB in 3.05 seconds = 39.36 MB/sec
hdparm -T /dev/hda
/dev/hda:
Timing cached reads: 1012 MB in 2.00 seconds = 505.32 MB/sec
hdparm -t /dev/hdb
/dev/hdb:
Timing buffered disk reads: 160 MB in 3.00 seconds = 53.32 MB/sec
hdparm -T /dev/hdb
/dev/hdb:
Timing cached reads: 1044 MB in 2.01 seconds = 520.00 MB/sec
Dla testow przekopiowalem plik o rozmiarze 438 MB najpierw w obrebie jednego i drugiego dysku, potem z pierwszego na drugi i z drugiego na pierwszy (partycje w okolicach srodka dysku, wszystkie na ext3).
W tym czasie dzialalo odpalone KDE, amarok, przegladarka - innymi slowy pare zwyklych aplikacji, obciazenie procesora przed testami nie przekraczalo 4.0%.
kopiowanie z hda na hda
czas:
real 0m23.234s (18.9MB/s)
user 0m0.023s
sys 0m3.761s
obciazenie procesora przez cp srednio 15% (skakalo miedzy 7 a 24)
kopiowanie z hdb na hdb
czas:
real 0m18.062s (24.3 MB/s)
user 0m0.029s
sys 0m3.733s
obciazenie procesora przez cp srednio 20% (miedzy 10 a 30)
kopiowanie z hda na hdb
czas:
real 0m18.393s (23.8 MB/s)
user 0m0.037s
sys 0m3.821s
obciazenie procesora przez cp okolo 20% (w miare stale)
kopiowanie z hdb na hda
czas:
real 0m14.261s (30.8 MB/s)
user 0m0.036s
sys 0m3.930s
obciazenie procesora przez cp okolo 25% (w miare stale)
Jak widzisz, generalnie jest przyzwoicie. Jakby te dyski byly na osobnych tasmach to mysle ze kopiowanie z jednego na drugi poszloby jeszcze szybciej i mniej obciazaloby procesor.
Z drugiej strony, zwazywszy na to ze moj Samsung jest szybszy niz twoj Maxtor, to te 24 MB/s z hdb na hdb nie odstaja jakos strasznie od twoich 20...
Myslisz ze powinno byc szybciej?
Natomiast jak chodzi o obciazenie procesora to nie bardzo mam idee co to moze byc. Nawet te 20% to u mnie duzo, ale tlumacze to sobie tym, ze za kazdym razem mamy do czynienia z kopiowaniem albo z tego samego dysku na siebie, albo z dyskow na tej samej tasmie.
Chetnie porownalbym to z wynikami na innych kontrolerach. Jak znajdziesz cos takiego (ja teraz nie bardzo mam czas) to daj znac...
Tak czy inaczej, jezeli rzeczywiscie masz 50% przy kopiowaniu w konsoli przy uzyciu cp to _raczej_ jest to cos z ustawieniem flag przy kompilacji czegos_tam, albo w ustawieniach hdparm (taki link np. znalazlem: http://www.narf.shl.pl/art/hdparm.html ).
No i ostatnia rzecz: w sumie to poza wlaczeniem DMA nigdy nie bawilem sie w tuningowanie ustawien dyskow, bo bardziej zalezy mi na bezpieczenstwie (na kompie mam sporo waznych danych, robi tez za serwer). No i czasu jakos tez zawsze za malo :)
Ale troche mnie zainspirowales, moze przy tym pogrzebie...- thx , daver 15/08/05 19:46
Czyli mniej/wiecej podobnie. Wine za moje zanizone wyniki zrzucam na barki sfragmentowanych plikow. Bede dalej szukal problemu. W miare mozliwosci zainstaluje linuksa na kompie brata (abit av8) i sprawdze zachowanie kontrolera, by wykluczyc slaba obsluge sisowego przez kernel. Sprawdze rowniez na jajku 2.4 (gdzies czytalem o problemach I/O - chyba kernela 2.6.9).
Jest o co walczyc, gdyz na window$ieXP ten sam sprzet uzyskuje wyniki ~2x lepsze.I use arch btw - to czekam na relacje :) , gorky 16/08/05 12:16
jezeli cos ci sie uda wyszarpac- to moze potrwac ;( , daver 16/08/05 12:45
Dostep do innego kompa, na ktorym bede mogl zainstalowac linuksa bede mial pod koniec tygodnia. Do tego szukam problemu niemal po omacku - jestem od niedawna uzyszkodnikiem pingwinka.I use arch btw - problem byl bardziej trywialny, niz sie spodziewalem , daver 16/08/05 18:51
Wyglada na to, ze zmiana opcji ksiegowania z ordered na writeback zalatwila sprawe. Jest juz prawie tak, jak oczekuje.I use arch btw - powaznie? , gorky 17/08/05 14:57
duzego kopa to dalo?- jesli powiesz mi... , daver 17/08/05 15:24
jak czyscic pamiec podreczna :) to podam dokladne wyniki. Inaczej musialbym resetowac kompa po kazdym kopiowaniu. Ponowne kopiowanie tego samego pliku (ok 300Mb) trwa ~3sek (przynajmniej wg time cp)I use arch btw - PS. , daver 17/08/05 15:25
moze wylaczyc tmpfs ?I use arch btw - huh? , gorky 17/08/05 18:50
pierwszy raz slysze ;)
sprobuj chociaz raz, z wiekszym plikiem, jestem ciekaw chocby rzedu wielkosci...- wyniki , daver 17/08/05 19:15
hda - Maxtor 6Y160P0 - 160GB 8MB c
Timing cached reads: 1096 MB in 2.00 seconds = 546.72 MB/sec
Timing buffered disk reads: 172 MB in 3.02 seconds = 57.02 MB/sec
hdb - Maxtor 6Y080L0 - 80GB 2MB c
Timing cached reads: 1100 MB in 2.00 seconds = 549.26 MB/sec
Timing buffered disk reads: 170 MB in 3.01 seconds = 56.47 MB/sec
Plik 699.8MB
===============
hda2->hda2
real 0m29.320s (23.86MB/s)
user 0m0.055s
sys 0m5.732s
hda2->hdb1
real 0m18.044s (38.79MB/s)
user 0m0.048s
sys 0m6.014s
hda1->hdb2
real 0m18.117s (38.64MB/s)
user 0m0.036s
sys 0m5.786s
Plik 290.1MB
===============
drugie kopiowanie tego samego pliku
hda2->hda2
real 0m6.311s (45.97MB/s)
user 0m0.021s
sys 0m2.210s
trzecie kopiowanie tego samego pliku
hda2->hda2
real 0m2.532s (114.66MB/s)
user 0m0.010s
sys 0m2.279s
Jestem przekonany, ze mozna jeszcze wycisnac ok 20%. Sam fakt, ze kopiowanie hda2->hdb1 i hda1->hdb2 niemal sie nie rozni (ba nawet szybszy hdd zapisywal wolniej) swiadczy, ze nadal jest zapas (byc moze ograniczeniem jest sam system plikow - nie testowalem jeszcze reiser4)I use arch btw - whoah , gorky 17/08/05 21:24
rzeczywiscie - o ile tymi hda2->hda2 bym sie nie przejmowal za bardzo, o tyle to 40MB/s miedzy dyskami daje do myslenia.
Bede musial kiedys jednak sprobowac przepiac swoje na osobne tasmy, to tez mysle ze jest nie bez znaczenia.
Jak chodzi o Reiser4 to juz od jakiegos czasu czekam az jego obsluga pojawi sie w stabilnym jadrze, to co o nim czytam dodatkowo ostrzy mi apetyt.
Tak czy inaczej do SiSa nie mozna sie chyba doczepiac ;)- jutro przepne , daver 17/08/05 21:51
swoje dyski na osobne tasmy, ale nawet na jednej powinno dac sie wycisnac odpowiednio: obreb jednego dysku (160GB) ~28MB/s i dysk -> dysk ~45-50MB/s. Nie ma z tym problemu na ntfs i XP.
Mnie do reisera4 zniechecaja opinie, jakoby mocno obciazal proca i nie byl zbyt responsywny. No coz, trzeba przetestowac i obalic/potwierdzic 'plotki' :)
PS. w wynikach wkradl sie blad. Zamiast:
hda1->hdb2
real 0m18.117s (38.64MB/s)
user 0m0.036s
sys 0m5.786s
Powinno byc:
hdb1->hda2
real 0m18.117s (38.64MB/s)
user 0m0.036s
sys 0m5.786sI use arch btw
|
|
|
|
 |
All rights reserved ® Copyright and Design 2001-2025, TwojePC.PL |
 |
|
|
|
