Niska pr

grapeli23 · Post autor: **grapeli23** » 03 marca 2010, 23:29

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.

aque · Post autor: **aque** » 05 marca 2010, 18:26

¯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?

grapeli23 · Post autor: **grapeli23** » 05 marca 2010, 20:45

Oczywiście 2MB/s, to żenująco niski wynik, tylko w tym problem, że nie masz punktu odniesienia.

Kod: Zaznacz cały

cat /proc/interrupts

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.

aque · Post autor: **aque** » 06 marca 2010, 09:53

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?

wladeczek · Post autor: **wladeczek** » 17 marca 2010, 10:10

Ja tak przy okazji proponowałbym zajrzenie do informacji ze S.M.A.R.T-a, polecenie:

Kod: Zaznacz cały

smartctl

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ć.

life · Post autor: **life** » 19 marca 2010, 20:22

Z tego co widzę to dysk nie działa w 32 bitach, wyłączone multisektory i nie ma maskowania.
Proponuje na początek:

Kod: Zaznacz cały

hdparm -d1 -u1 -m16 -c1 -X udma5 /dev/hdb

sprawdź czy będzie lepiej jak tak to:

Kod: Zaznacz cały

hdparm -k1 /dev/hdb

żeby zapamiętać ustawienia albo dać do skryptu przy starcie
Ewentualnie możesz spróbować podnieść parametr dla Multcount, czyli dać -m32 ewentualnie -m64