szybkosc operacji dyskowych

[dylon]

Witam.
Mam problem z szybkoscia dyskow ktore mimo ze hdparm twierdzi ze pracuja w dma to przy kopiowaniu obciazenie procka wynosi 100%
Mam plyte ecs z sis-em 5513 i zrobilem wszystko wg opisow i dalej nic.
I w zasadzie dalem sobie juz z tym spokoj obciazajac wina plyte glowna ale ostatnio zobaczylem nienormalne, jak dla mnie, zachowanie.
O ile przy jakimkolwiek kopiowaniu miedzy partycjami ext3, na tym samym lub osobnych dyskach, wynosi srednio 2-3MB/s a na fat32 ok 1MB/s to dla odmiany przy kopiowaniu z fat-a na ext3 (osobne dyski) transfer wynosi ok 12MB/s !
Dla odmiany kopiowanie w odwrotna strone ext3->fat32 wynosi juz standartowe 1MB/s

Zawsze sadzilem ze przy kopiowaniu na "partycje linuksowe" transfery sa nizsze ze wzgledu na ustawianie praw etc. i ze przy kopiowaniu na fat trwa to zawsze szybciej...

Dlaczego tak jest?

pozdrawiam

[Aktyn]

tak jednoznacznie sie stwierdzić nie da:

1. Kwestia poprawności samych dysków, czasem dyski źle pracują jak są razem na tym samym ide, albo nielubią jak są master a jest na pierwszej łączce a nie ostatniej, albo są w trybie samowykrywania. A wiec dyski i podłączenie

2. Kwestia samego kontrolera na płycie (jakość), ustawienie UDMA w biosie. Dobra tasiemka do dysków.

3. Poprawnie sformatowny dysk, (widziełem już kilka dysków które kaszaniły z dziwnych powodów), często inne ustawienie w biosie np LBA a potem przestawione na CHS, naprawde czasem działa ale własnie dziwnie.

4. hdparm i poprawnie skonfigurowane kernel.

5. Kwestia systemu plików, ext3 jest w miare, jak masz system 32bitowy to spróbuj dla testu stworzyć partycjie jfs, xfs, reiserfs.

Obciążenie proca u mnie też jest zawsze max przy kopiowaniu przy 2Ghz procu, ale to jest takie troche pozorne, bo przy spowolnieniu proca o połowe, czas kopiowania jest ten sam. Tzn w kde tyle pokazuje, ale to może być wynikiem oczekiwania przez kernel, wiec troche takie pozorne jest to obciążenie

No i co czym kopiujesz, też pewnie ma jakieś znaczenie. A jak to jest u ciebie, musisz poszukać.

[martin.k]

Oprócz problemów ze sprzętem pozostaje jeszcze jeden, aczkolwiek znaczący aspekt: KERNEL
Ext3 jest bardzo szybkim systemem plików, więc problem pewnie jest w czymś innym. Eventualnie możesz w /etc/fstab dodać przy opcjach montowania parametr noatime.
Bardzo wiele zależy od tzw. schedulera I/O (po polsku: planista wejścia/wyjścia)
Domyślnie jądro parametryzowane jest z CFQ I/O scheduler. Możesz wypróbować inne schedulery I/O.
Wystarczy w GRUB'ie dopisać w linijce kernel, jeden z poniższych i zbootować kompa. Wtedy będziesz miał ustawiony wybrany scheduler dla wszystkich napędów w kompie:

Code: Select all

elevator=anticipatory

Code: Select all

elevator=deadline

Code: Select all

elevator=noop

Możesz też dynamicznie zmieniać planistę I/O podczas pracy kompa, dla wybranego dysku:
Z konsoli, z roota daj:

Code: Select all

 echo anticipatory > /sys/block/hda/queue/scheduler

Oczywiście po echo dajesz wybrany scheduler (anticipatory, deadline, noop) a w miejsce hda odpowiednie urządzenia (dysk).

Osobiście mam anticipatory i jestem zadowolony Ale nie do wszystkich zadań się nadaje. Pozostaje metoda prób i błędów. Od czasu do czasu, testowo, kompiluje sobie kernela ze wsparciem algorytmów genetycznych. Ale to już inna bajka

Polecam również śledzenie od czasu do czasu http://www.lkml.org i aktualizację jądra do nowszych wersji. Był pewien okres, kiedy CFQ działał szpetnie. Teraz jest lepiej.

A co do 100% zajętości CPU, to też idzie sobie z tym poradzić, ale to już kwestia schedulera CPU. Poczytaj tutaj: http://cpuse.sf.net

[dylon]

Dzieki za rady. Niestety malo pomogly
1. Dyski polaczone dobrze.
2. systemy plikow - nie mam jak sprawdzic innych niz wspomniane ext3 i fat32
3. kernel - obsluda dma dyskow poprawnie wlaczona (wg roznych howto etc)
scheduller-y - tu kombinowalem z kazdym i na moim sprzecie roznice sa minimalne ze wskazaniem na anticipatory, ktory aktualnie uzywam.

W zasadzie pozostaja mi dwie mozliwosci: w jakis sposob walniety kontroler na plycie (chociaz jak sprawdzalem windowsowi nie szkodzi) i (moj typ) ze cos skopalem w konfiguracji kernela co nie ma bezsposredniego wplywu na napedy a spowalnia system w calosci.

p.s. czy na porownywalnym sprzecie jak moj (duron 700 + ecs k7s5a +512MB ram ) wybor schedulera ma minimalny wplyw na prace systemu jak u mnie czy moze tu jest pies pogrzebany?

Pozdrawiam

[martin.k]

W zasadzie pozostaja mi dwie mozliwosci: w jakis sposob walniety kontroler na plycie (chociaz jak sprawdzalem windowsowi nie szkodzi) i (moj typ) ze cos skopalem w konfiguracji kernela co nie ma bezsposredniego wplywu na napedy a spowalnia system w calosci.

p.s. czy na porownywalnym sprzecie jak moj (duron 700 + ecs k7s5a +512MB ram ) wybor schedulera ma minimalny wplyw na prace systemu jak u mnie czy moze tu jest pies pogrzebany?

Pozdrawiam

Na tej płytce jest pewnie kontroler SIS'a. Nie wiem jak się SIS sprawuje, bo od zawsze mam VIA albo nForca. Może też masz kiepskiej jakości taśmę do podłączenia HDD.
A co do konfiguracji kernela i jej poprawności, to nic nie wydukamy bez wersji kernela i pliku .config. Jeśli masz gdzieś wolny plac, tak by wrzucić .config na świat, to będzie łatwiej. Jeśli nie to wklej go tutaj, ale to już kiepskie rozwiązanie

Co do schedulera I/O:
1) skoro anticipatory działa ci w miarę dobrze to tak zostaw.

Co do schedulera CPU:
1) nie oczekuj cudów po wymianie schedulera CPU na inny niż domyślny na duronie 700, ale zawsze można spróbować.
2) polecam PlugSched. Pozwala na przećwiczenie kilku schedulerów CPU. Szczególnie polecam wybór staircase od dr Cona Kolivasa. Możesz zyskać na poziomie interaktywności. Ale będziesz musiał już sobie sam jądro połatać. Potem wystarczy w grubi'e dodać odpowiedni wpis i testować. Niestety schedulera CPU nie można wymieniać dynamicznie podczas pracy kompa. Potrzebny reboot. A jeśli chcesz tylko staircase, to w portage jest ck-sources. Więc wystarczy emerge ck-sources. Potem parametryzacja kernela i kompilacja.