drobny problem s prenosem dat v ramci pevneho disku pres DMA - problem s XMMS

Uz od zacatku pouzivani fc6 pozoruju nedokonaly chovani pri intenzivni praci pevnyho disku - prestoze mam zaply DMA, vzroste mi zatizeni CPU priblizne o 20%. Samozrejme to neni nic hroznyho, ale teoreticky by prace disku pri zapnutym DMA nemela procesor zatezovat skoro vubec. Zatez asi nesouvisi treba se zpracovanim opravneni k prenasenym souborum, projevuje se stejne i napr. pri kopirovani 1 velkyho souboru. Druha vec je, ze pri intenzivni praci disku se snad veskery IO potencial disku venuje jen te 1 intenzivni operaci - ostatni operace museji pockat - coz se pro me neprijemne projevuje pozastavenim prehravani pomoci XMMS.

Pevny disk je ATA 133 Samsung 250GB (8MB cache) - ale je detekovan FC6 jen jako ATA 100 - planuju to spravit pomoci hdparm. Zakladni deska ma chipset ati 9100 igp - ted nevim jaky southbridge na desce je. V hardware jako takovym by problem byt nemel - ve win xp vse pracuje dobre. Oddily maji filesystem ext3, jsou dle fstab pripojeny s parametrem “defaults” - takze snad vcetne async.

Uvitam jakykoliv napad, jak tento drobny problem spravit.

Systemovy scheduler prepokladam pouzivate defaultni


# dmesg | grep sche
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)

Zkuste sem dat vypis hdparm -i /dev/hda a lspci.

Predem dekuju za zajem. Tady to je :

vystup “dmesg | grep sche” je uplne stejny, defaultni konfigurace.

hdparm -i /dev/hda

/dev/hda:

Model=SAMSUNG SP2514N, FwRev=VF100-41, SerialNo=XXXXXXXXXXXX :slight_smile:
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:240,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: unknown: ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7

lspci

00:00.0 Host bridge: ATI Technologies Inc Radeon 9100 IGP Host Bridge (rev 02)
00:01.0 PCI bridge: ATI Technologies Inc Radeon 9100 IGP AGP Bridge
00:13.0 USB Controller: ATI Technologies Inc OHCI USB Controller #1 (rev 01)
00:13.1 USB Controller: ATI Technologies Inc OHCI USB Controller #2 (rev 01)
00:13.2 USB Controller: ATI Technologies Inc EHCI USB Controller (rev 01)
00:14.0 SMBus: ATI Technologies Inc ATI SMBus (rev 18)
00:14.1 IDE interface: ATI Technologies Inc ATI Dual Channel Bus Master PCI IDE Controller
00:14.3 ISA bridge: ATI Technologies Inc Unknown device 434c
00:14.4 PCI bridge: ATI Technologies Inc Unknown device 4342
00:14.5 Multimedia audio controller: ATI Technologies Inc IXP150 AC’97 Audio Controller
01:05.0 VGA compatible controller: ATI Technologies Inc RV350 AS [Radeon 9550]
01:05.1 Display controller: ATI Technologies Inc RV350 AS [Radeon 9550] (Secondary)
02:09.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)

Co z toho vidim - MultSect mate nastaveny na maximum 16, nastavovat mensi hodnoty je doporuceno pouze u disku WD (viz man hdparm) takze to asi problem nebude. Skutecne mate udma nastavene na udma5 (udma 100), proc to nevim, muzete zkusit dat udma6 ale v tom v zasade problem nebude. Trochu me mate to Driver conforms to “unknown”. V dmesg jste zadnou informaci o problemu v kombinaci disku/radice nenasel?

Co muzete zkusit je snizit hodnotu read-ahead. Parametr -a pro hdparm. Drive to celkem pomahalo prave na tyto situace.

MMCH: zkuste jeste hdparm -v /dev/hda jesli to dma je skutecne zapnute…


# hdparm -v /dev/hda

/dev/hda:
 multcount    = 16 (on)
 IO_support   =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    = 256 (on)

podobne sa fc6 chova ja mne pri praci s diskom sa system viditelne spomali

hdparm -v /dev/hda

/dev/hda:
multcount = 16 (on)
IO_support = 0 (default 16-bit) -> 1 (32-bit)
unmaskirq = 0 (off) -> 1
using_dma = 1 (on)
keepsettings = 0 (off) -> 1
readonly = 0 (off)
readahead = 256 (on) -> 192
geometry = 30401/255/63, sectors = 488397168, start = 0

Toto je konfigurace disku a zmeny ktere jsem provedl - doufam ze to masinka vydrzi, kdyz ne, skoro vsechny data mam zazalohovany. Zjistil jsem, ze disk nemuzu prinutit pouzivat udma6 - hdparm potvrdi provedeni zmeny, ale konfigurace disku se nezmeni. Ocekaval bych aspon chybu, oznameni ze chci dosahnout nepodporovane konfigurace.
V dmesg jsem nenasel nic, co by se dalo nazvat problem - jen ze vubec neni detekovana moznost pouzit udma6.
Bohuzel ani po prenastaveni konfigurace pomoci hdparm neni problem vyresen. Ale za to jsem nemohl najit hdparm.conf - tak jsem ho vytvoril jak v /etc tak v /etc/sysconfig - bohuzel, je ignorovan. Mozna bych mohl jeste snizit readahead - na podstatne nizsi hodnotu - to zkusim zitra.

Pro funtomase : snad tu najdes neco co tobe pomuze. Zkus si taky pohrat s nastavenim hdparm - treba to u tebe zabere. Ale pomohlo by, kdybys napsal vic detailu o sve masine - treba mame podobnou konfiguraci. Nemas taky chipset od Ati?

[root@roof tomas]# /sbin/hdparm -i /dev/hda

/dev/hda:

Model=Maxtor 6Y080P0, FwRev=YAR41BW0, SerialNo=Y240AY5E
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=7936kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=160086528
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5 udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: ATA/ATAPI-7 T13 1532D revision 0: ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7

  • signifies the current active mode

[root@roof tomas]# /sbin/lspci
00:00.0 Host bridge: Advanced Micro Devices [AMD] AMD-760 [IGD4-1P] System Controller (rev 13)
00:01.0 PCI bridge: Advanced Micro Devices [AMD] AMD-760 [IGD4-1P] AGP Bridge
00:07.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
00:07.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:07.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a)
00:07.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 1a)
00:07.4 SMBus: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:09.0 Ethernet controller: 3Com Corporation 3c905 100BaseTX [Boomerang]
00:0b.0 Multimedia audio controller: Creative Labs SB Live! EMU10k1 (rev 07)
00:0b.1 Input device controller: Creative Labs SB Live! Game Port (rev 07)
00:0f.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 50)
00:0f.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 50)
00:0f.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51)
01:05.0 VGA compatible controller: nVidia Corporation NV28 [GeForce4 Ti 4200 AGP 8x] (rev a1)

[root@roof tomas]# /sbin/hdparm -v /dev/hda

/dev/hda:
multcount = 16 (on)
IO_support = 1 (32-bit)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
readonly = 0 (off)
readahead = 256 (on)
geometry = 65535/16/63, sectors = 160086528, start = 0

mne ta doska 133 neda ale asi je to zanedbatelne oproti 100

pro funtomase : koukam toho moc spolecnyho nemame - jen nam oboum neni dovoleno pouzivat udma6 - zrejme nedokonala podpora chipsetu. Zkusil bych ovladace od vyrobce, kdyby nejaky Ati nabizela. Jak je na tom Via, nevim.

Dnes jsem zkusil provoz s readahead = 32 - bez ucinku. Ale diky za podnet, Covexi - aspon vim, kudy cesta nevede a trochu vic jsem se seznamil s hdparm.

Jen tak pro zajimavost co vypise hdparm -tT /dev/hda?

Na testovani tohodle problemu jsem driv pouzival
cp nejakyvelkysoubortreba.iso /dev/null
tak se read operace disku dostane na max. Zatez procesoru je na PIII 800, i815 taky asi 20%, prenosova rychlost asi 30MB/s.

Pokud by vam vadilo jen to sekani (pokud se to teda neodmlci uplne) xmms tak mu muzete pomoci “nice” zkusit zvednou prioritu , pripadne v nastaveni zkusit realtime (ale to asi nebude fungovat). Jinak ja pri kopirovani ani na pomerne historickem stroji zadne zasadni zpomaleni prace ani sekani nezaznamenavam.

[root@roof tomas]# /sbin/hdparm -tT /dev/hda

/dev/hda:
Timing cached reads: 1088 MB in 2.01 seconds = 542.29 MB/sec
Timing buffered disk reads: 162 MB in 3.11 seconds = 52.15 MB/sec

pri kopirovani na null mi top ukaze pri cp okolo 20% max (na zaciatku aj 35 ale klesne to na 20 kde sa drzi)

To vypada v celku normalne… vic me nenapda…:frowning:

/sbin/hdparm -tT /dev/hda

/dev/hda:
Timing cached reads: 1460 MB in 2.00 seconds = 729.09 MB/sec
Timing buffered disk reads: 186 MB in 3.02 seconds = 61.60 MB/sec

vytizeni cpu (2,4GHz celeron) pri kopirovani do null mi vzroste o 15% (12->27) ale pokud jde o realne kopirovani (treba : cp foo bar), zatizeni se pohybuje kolem 45% s chvilkovymi spickami 80%. Bohuzel, pozastaveni XMMS neni jen chvilkovy vypadek - prehravani se zastavi, lze pokracovat od mista preruseni pomoci dvojnasobne pauzy : prvni pauza uvede XMMS do regulerniho pozastaveni, druha pauza prehravani obnovi. Bez ucasti uzivatele se prehravani neobnovi. Samozrejme jsem zkusil zvetsit vyrovnavaci pamet ALSA v nastaveni XMMS - zvolil jsem 10s, coz by melo pokryt kazdy vypadek prenosu dat. Bez ucinku. Ted me jeste napadlo zpomalit disk - nechat ho jen na udma4, nebo min.

Chcete rict ze to nezacne prehravat ani kdyz se to dokopiruje?!

Presne tak :frowning:

To jsem este neslysel. A skoro mi tedy prijde ze to nesouvisi s harddiskem. Zkousel jste jiny prehravac (napr. audacity je v podstate stejne jako xmms)?

Ano, tady je ten problem! XMMS. Audacious zvlada prehravat hudbu bez preruseni i behem intenzivni cinnosti disku. Mrzi me ze sem az tak chybne urcil zdroj problemu. Vlastne me ani nenapadlo zkouset jiny program nez xmms. “Problem” vyresen, dekuju. (to vytizeni procesoru behem prenosu me az tak nepali)

XMMS uz je dnes prehravaci dedecek a existuje mnoho jeho nahrad (doporucuji http://www.abclinuxu.cz/clanky/recenze/prehravace-hudby-pro-gtk-a-gnome), presto je hodne pouzivan. Duvod ke vzniku takoveho problemu mi ale stale vrta hlavou…