Kopieeren tussen HD's traag

[easydisk]

Heb een KT133 mobo en op hda en hdc 2 hd's hangen:

VP_IDE: VIA vt82c686a (rev 22) IDE UDMA66 controller on pci00:07.1
ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:DMA
hda: MAXTOR 6L060J3, ATA DISK drive
hdc: IBM-DTLA-307045, ATA DISK drive
hdd: IOMEGA ZIP 100 ATAPI, ATAPI FLOPPY drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: 117266688 sectors (60041 MB) w/1819KiB Cache, CHS=7299/255/63, UDMA(66)
hdc: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63, UDMA(66)

Als ik echter iets van hda naar hdc kopieeren (vooral grote bestanden, ca 600 a 700 MB) dan gaat dit met ca 3 Mbyte/sec !
de load stijgt naar 3 a 4

[/home/alfred]$ uptime
12:41:41 up 4 days, 18:51, 2 users, load average: 3.15, 3.79, 2.60

en dat terwijl de hdparm settings goed zijn (DMA, etc)

[/home/alfred]# hdparm /dev/hdc

/dev/hdc:
multcount = 16 (on)
I/O support = 3 (32-bit w/sync)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 5606/255/63, sectors = 90069840, start = 0
busstate = 1 (on)
[/home/alfred]# hdparm /dev/hda

/dev/hda:
multcount = 16 (on)
I/O support = 3 (32-bit w/sync)
unmaskirq = 1 (on)
using_dma = 1 (on)
keepsettings = 0 (off)
nowerr = 0 (off)
readonly = 0 (off)
readahead = 8 (on)
geometry = 7299/255/63, sectors = 117266688, start = 0
busstate = 1 (on)

Waar zit de fout ? Of is dit normaal (voor hd's die toch minimaal 20 MByte/sec moeten kunnen verwerken) ?
Kan ik ze beter op 1 IDE kabel zetten ?
hda en hdb ? moeten ze wel de 66 MB/sec delen maar zitten ze wel opdezelfde irq.

Soms is het zo erg dat mp3tjes stoppen met spelen, op een 900 MHz machine !

[update]
Als er alleen van gelezen wordt gaat het prima,
4432 MByte in 2m47.774s
Dat is een ruimte 25 MByte/sec.

[Ronald]

Wat krijg je als output van

code:

hdparm -tT /dev/hda
hdparm -tT /dev/hdc

beide hd's op 1 kabel is in theorie trager, omdat de slave drive altijd plaats moet maken op de bus als je de master wil aanspreken. van hd>hd kopy zal dan altijd traag zijn.

[Verwijderd]

heb je DMA aanstaan en support in kernel gecompiled?

edit: owja zie het sorry

[moto-moi]

Op zaterdag 09 februari 2002 12:45 schreef easydisk het volgende:

/dev/hda:
multcount = 16 (on)
I/O support = 3 (32-bit w/sync)

Zet deze laatste eens op 1, dus hdparm -c1 /dev/hda & hdparm -c1 /dev/hdc

En daarna eens hdparm -Tt /dev/hda en dit herhalen voor /dev/hdc.. Zit er dan verschil in ?

Waar zit de fout ? Of is dit normaal (voor hd's die toch minimaal 20 MByte/sec moeten kunnen verwerken) ?
Kan ik ze beter op 1 IDE kabel zetten ?

Nee, samen op de kabel zijn ze langzamer, van /dev/hda naar /dev/hdc is het snelste wat je kunt bereiken

[easydisk]

Dit zijn de hdpram waardes met I/O support = 3 (32-bit w/sync)

[/home/alfred]# hdparm -tT /dev/hda

/dev/hda:
Timing buffer-cache reads: 128 MB in 1.09 seconds =117.43 MB/sec
Timing buffered disk reads: 64 MB in 2.30 seconds = 27.83 MB/sec
[/home/alfred]# hdparm -tT /dev/hdc

/dev/hdc:
Timing buffer-cache reads: 128 MB in 1.10 seconds =116.36 MB/sec
Timing buffered disk reads: 64 MB in 1.80 seconds = 35.56 MB/sec


[/home/alfred]# hdparm -c1 /dev/hda

/dev/hda:
setting 32-bit I/O support flag to 1
I/O support = 1 (32-bit)
[/home/alfred]# hdparm -tT /dev/hda

/dev/hda:
Timing buffer-cache reads: 128 MB in 1.10 seconds =116.36 MB/sec
Timing buffered disk reads: 64 MB in 2.42 seconds = 26.45 MB/sec
[/home/alfred]# hdparm -c1 /dev/hdc

/dev/hdc:
setting 32-bit I/O support flag to 1
I/O support = 1 (32-bit)
[/home/alfred]# hdparm -tT /dev/hdc

/dev/hdc:
Timing buffer-cache reads: 128 MB in 1.10 seconds =116.36 MB/sec
Timing buffered disk reads: 64 MB in 1.79 seconds = 35.75 MB/sec




Weer even gestet met een groot bestand, het begin gaat lekker, 18 MB/sec maar dat is waarschijnlijk omdat ie het in een buffer schrijft, daarna zakt het terug naar 3 a 4 Mbyte/sec.
De load is wel ietsjes lager, net boven de 2 en de mp3 bleef minder hangen.

Ik denk dat het een (on)volkomenheid van de kt133 chipset is.

[Ronald]

de buffer-cache is allemachtig traag. ik heb 180MB/s (vraag niet hoe) en een vriend van mij haalt dat ook met 686a + DTLA's

de normale buffer read lijkt me in orde.

maar dat lost je probleem niet op. Wat voor settings heb je in de kernel wat betreft ata driverspul?

Ik heb ook een Kt133 bord (MSI k7t pro2)

[easydisk]

Die buffer read is al meer dan mogelijk is, maximaal zou er 66 Mbyte/sec over die kabel kunnen.
Maar dat is ook niet zo belangrijk.


Qua kernel opties heb ik aanstaan dat UDMA bij default moet worden aangezet.

CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_BLK_DEV_ADMA=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y

CONFIG_IDEDMA_AUTO=y

en dat werkt want dmesg zegt:
hda: 117266688 sectors (60041 MB) w/1819KiB Cache, CHS=7299/255/63, UDMA(66)
hdc: 90069840 sectors (46116 MB) w/1916KiB Cache, CHS=89355/16/63, UDMA(66)

(het zinn respectievelijk UDMA 133 en 100 HD's, maar heb maar een UDMA 66 controller.

En ik heb reiserfs als filesysteem, is snel dus daar zou het niet aan kunnen liggen (het kan namelijk ook 25 MByte/sec lezen)

[easydisk]

Nog meer info

[/home/alfred]# hdparm -i /dev/hda

/dev/hda:

Model=MAXTOR 6L060J3, FwRev=A93.0500, SerialNo=663240610136
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=32256, SectSize=21298, ECCbytes=4
BuffType=DualPortCache, BuffSize=1819kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=117266688
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 udma0 udma1 udma2 udma3 *udma4 udma5 udma6
AdvancedPM=no WriteCache=enabled
Drive Supports : ATA/ATAPI-5 T13 1321D revision 1 : ATA-1 ATA-2 ATA-3 ATA-4 ATA-5

[/home/alfred]# hdparm -i /dev/hdc

/dev/hdc:

Model=IBM-DTLA-307045, FwRev=TX6OA50C, SerialNo=YMDYMLF3687
Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
BuffType=DualPortCache, BuffSize=1916kB, MaxMultSect=16, MultSect=16
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=90069840
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 udma0 udma1 udma2 udma3 *udma4 udma5
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive Supports : ATA/ATAPI-5 T13 1321D revision 1 : ATA-2 ATA-3 ATA-4 ATA-5



Ook hier staat dat ze beide in UDMA4 draaien

[ACM]

Op zaterdag 09 februari 2002 15:15 schreef moto-moi het volgende:
Nee, samen op de kabel zijn ze langzamer, van /dev/hda naar /dev/hdc is het snelste wat je kunt bereiken

Aangezien de beide disks hooguit 30MB/sec halen maakt dat voor copieren niet zo veel uit gok ik

De kabel/poort kan toch wel meer aan.



Antwoord op je vraag heb ik alleen helaas niet, hooguit het "het zou moeten werken" antwoord, maar daar schiet je niks mee op
Je kan eventueel nog bonnie++ opzoeken en daarmee kijken hoe snel die je schijven vindt.

[moto-moi]

Op zaterdag 09 februari 2002 16:26 schreef ACM het volgende:
Aangezien de beide disks hooguit 30MB/sec halen maakt dat voor copieren niet zo veel uit gok ik
De kabel/poort kan toch wel meer aan.

De schijven waren ATA100 & ATA133 , en de controller was ATA66. Mij is altijd verteld, dat je het beste zoiets kun doen van /dev/hda (c.q. /dev/hdb) naar /dev/hdc (c.q./dev/hdd).
Hmm, als ik het verkeerd heb, dan moet ik maar eens in HW de FAQ gaan lezen ofzo, ik hou er niet van om foute antwoorden te geven

Antwoord op je vraag heb ik alleen helaas niet, hooguit het "het zou moeten werken" antwoord, maar daar schiet je niks mee op

Daarom ben jij ook HGM Devschuur, en niet HGM Hardware

[Ronald]

hmms

enige wat ik nog kan bedenken is dat de IDE driver beetje brak is. Ik las dat er hier en daar wat problemen zitten in bepaalde releases kernel, maar het fijne weet ik er echt niet van.

[ACM]

Op zaterdag 09 februari 2002 16:38 schreef moto-moi het volgende:
De schijven waren ATA100 & ATA133 , en de controller was ATA66.

Dat de schijven ata100/133 spreken maakt helemaal niets uit voor de daadwerkelijk gehaalde snelheid

De meeste schijven zitten nu zo tussen de 20 en 35MB/sec kwa performance geloof ik.
2 samen trekken hooguit net aan de ata66 vol, maar ata100 al helemaal niet.

Uiteraard is er altijd wat protocol overhead, maar zelfs dan moet je nog makkelijk met zo'n 20MB/sec files van de ene naar de andere disk sturen. Daarbij komt trouwens nog dat disks over het algemeen een stuk slomer zijn met schrijven (bijvoorbeeld maar 15-20MB/sec) waardoor je nog weer wat meer ruimte overhoudt.

Mij is altijd verteld, dat je het beste zoiets kun doen van /dev/hda (c.q. /dev/hdb) naar /dev/hdc (c.q./dev/hdd).
Hmm, als ik het verkeerd heb, dan moet ik maar eens in HW de FAQ gaan lezen ofzo, ik hou er niet van om foute antwoorden te geven

Echt veel zal het niet uitmaken, zodra je beide schijven samen sneller (dus de ene leest op 40MB/sec de andere schrijft op 25MB/sec merk je het nog niet, pas als de schrijver over de helft van de 'bussnelheid' zit) zijn dan de 'bus' maakt het uit, tot die tijd niets

Daarom ben jij ook HGM Devschuur, en niet HGM Hardware

Achja
Maar die opmerking had niet zozeer met de hardware te maken, dat zal wel gewoon goed zijn...

Het kan natuurlijk ook zo zijn dat er een extreem zwaar gefragmenteerd filesystem aanwezig is...

[Verwijderd]

Gebruik je toevallig ReiserFS ? Toen ik ReiserFS gebruikte viel mij de snelheid ook op in negatieve zin. Later met ext3 nog een keer dezelfde actie gedaan en toen bleek de kopieeractie zeker 3 keer zo snel. Sinds die tijd heb ik ReiserFS afgeschaft.

[easydisk]

ja en nee, ik heb Reiserfs, maar het gaat hier om 2 fat32 partities.

Ik ga eens kijken op google of er mischien problemen zijn met fat32 en Linux (denk het niet, want lezen gaat prima en schrijven gaat volgens mij ook goed.)

[update]

gestest onder Windhoos (daar ging m'n uptime)
650 MByte in 90 seconde, 2x zo snel als Linux, maar toch niet de verwachte resultaten, dus het zal wel een zwaar irq probleem op de kt133 zijn

[deadinspace]

Er zat toch een bug in die VIA chipset die zware data-corruptie opleverde als je van de ene naar de andere schijf kopieerde? En dat de Linux kernel hier nu een workaround voor had? Het kan zijn dat deze workaround wat drastisch is en daardoor meer performance verlies veroorzaakt dan de Windows drivers...

[Ronald]

Op zaterdag 09 februari 2002 19:47 schreef deadinspace het volgende:
Er zat toch een bug in die VIA chipset die zware data-corruptie opleverde als je van de ene naar de andere schijf kopieerde? En dat de Linux kernel hier nu een workaround voor had? Het kan zijn dat deze workaround wat drastisch is en daardoor meer performance verlies veroorzaakt dan de Windows drivers...

Het gaat hier over een 686a, die het bekende corruptie/sb life probleem niet heeft.