Strona 2 z 2
: 03 marca 2010, 23:29
autor: grapeli23
Hej, nie oczekuj cudów od kontrolera działającego na płycie głównej z innej "epoki".
Mam ja sobie podpięty dysk do płyty głównej z procesorem na socket7 (amd k6-3D 450MHz), jego liniowy maksymalny transfer to 16-17 MB/sec. Ten sam dysk wpięty do płyty innej generacji (procesor na AM2+) ma transfer liniowy 65 MB/sec. Przepaść. To są ograniczenia płyty i jej architektury. Tego się w żaden sposób nie przeskoczy.
Nic nie wspomniałeś, że na pierwszym kontrolerze masz podpięty adapter CF, dwa jak na tej klasy płytę jest tam dużo podłączonych rzeczy. Coś się ze sobą gryzie? Możliwe, że tu zaczynają się problemy z przerwaniami.
Zacznij od chwilowego pozbycia się kart, wyłączenia nie używanych portów - USB, równoległego, szeregowego. Zostawić kartę graficzną, klawiaturę a dysk podpiąć pod pierwszy kontroler jako jedyne urządzenie.
Porównać jak wygląda transfer, jak zachowuje się po dłuższym działaniu.
Podstawa to aby kontroler miał wolne przerwanie i dysk korzystał z kanału DMA.
: 05 marca 2010, 18:26
autor: aque
¯adnych cudów nie oczekuje od tej płyty, no chyba ze transfer 2MB/s to są jakieś cuda, jak na płytę obsługującą DMA33.
Kontrolera CF już nie ma, został on zastąpiony zwykłym dyskiem ATA 3.5" który jest podłączony jako jedyne urządzenie.
Co do faktu że jest podłączonych dużo rzeczy, to się zgodzę, no ale niestety wszystko jest wykorzystywane.
Teraz pytanie jak sprawdzić jakie urządzenie wykorzystuje dane przerwanie? I czy da się to przypisać na stałe?
Jak sobie teraz tak myślę o tych przerwaniach, to przypomniało mi się że miałem problem po podłączeniu karty USB na PCI i musiałem ładować kernel z opcją irqpoll , bo inaczej sypały się błędy związane z przerwaniami USB i system chodził niestabilnie. Może przyczyną jest ta opcja irqpoll?
: 05 marca 2010, 20:45
autor: grapeli23
Oczywiście 2MB/s, to żenująco niski wynik, tylko w tym problem, że nie masz punktu odniesienia.
Tu jest lista przerwań z których korzysta system i jak wygląda rozkład.
Kartom PCI przerwanie możesz przydzielić z poziomu ustawień BIOSU. Czasem zamiana kart miejscami potrafi przynieść dobry skutek.
irqpoll bardzo możliwe, że to przyczyna kłopotów. Wyjmij kartę i się przekonasz.
Do testowania transferu z dysku możesz wykorzystać dd
Kod: Zaznacz cały
time dd if=/dev/zero of=testfile bs=8K count=20000
z tym, że rozmiar pliku dobierz wedle własnych potrzeb
Kod: Zaznacz cały
sync;
time dd if=testfile of=/dev/null bs=8k
Do monitorowania systemu vmstat. Zobaczysz jak wygląda obciążenie CPU oraz co się dzieje z przerwaniami podczas testów.
: 06 marca 2010, 09:53
autor: aque
No to chyba znaleźliśmy Panowie przyczynę problemu:
Kod: Zaznacz cały
debian:~# cat /proc/interrupts
CPU0
0: 58183540 XT-PIC-XT timer
1: 2 XT-PIC-XT i8042
2: 0 XT-PIC-XT cascade
3: 50213 XT-PIC-XT serial
4: 366158 XT-PIC-XT serial
5: 1 XT-PIC-XT soundblaster
6: 2 XT-PIC-XT floppy
7: 0 XT-PIC-XT parport0
8: 0 XT-PIC-XT rtc0
10: 1424329 XT-PIC-XT ohci_hcd:usb2, eth0
11: 85173 XT-PIC-XT ohci_hcd:usb1
12: 1 XT-PIC-XT ehci_hcd:usb3
14: 2582 XT-PIC-XT ide0
15: 0 XT-PIC-XT ohci_hcd:usb4, ide1
NMI: 0 Non-maskable interrupts
LOC: 0 Local timer interrupts
TRM: 0 Thermal event interrupts
SPU: 0 Spurious interrupts
ERR: 0
MIS: 0
usb2 i eth0 oraz usb4 i ide1 mają takie same przerwania, spróbuję wyłączyć w biosie kartę dźwiękową i stację dyskietek. Zobaczymy czy to pomoże.
EDIT
Jak zmusić eth0 do korzystania z przerwania 5 a ide1, 6?
: 17 marca 2010, 10:10
autor: wladeczek
Ja tak przy okazji proponowałbym zajrzenie do informacji ze S.M.A.R.T-a, polecenie:
Ten dysk może mieć swoje lata i może kończyć żywot. Chociaż nie mówię, że tak musi być ale nie zaszkodzi sprawdzić.
: 19 marca 2010, 20:22
autor: life
Z tego co widzę to dysk nie działa w 32 bitach, wyłączone multisektory i nie ma maskowania.
Proponuje na początek:
sprawdź czy będzie lepiej jak tak to:
żeby zapamiętać ustawienia albo dać do skryptu przy starcie
Ewentualnie możesz spróbować podnieść parametr dla
Multcount, czyli dać -m32 ewentualnie -m64