# Odd Hard Drive Performance with Epia ME-6000

## tintax

I'm having trouble with the performance of my hard drives. AFAIK I've got them configured correctly (I'm definately not an experienced linux user) but they feel like they're operating in pio mode. Try to move files between them and it thrashes the CPU and takes far too long; plus I'm getting low "cached reads" with hdparm -tT.

Hardware: Via EPIA ME-6000 motherboard with Via VT8235 IDE controller (Samsung UDMA33 DVD-ROM [hda] on ide0, Hitachi UDMA100 HDD [hdc] and Western Digital UDMA100 HDD [hdd] on ide1) onboard plus Silicon Image Sil680 ATA133 IDE PCI controller (Western Digital UDMA100 HDD [hde] on ide2).

hdparm -tT

```

/dev/hdc:

 Timing cached reads:   256 MB in  2.00 seconds = 128.02 MB/sec

 Timing buffered disk reads:   74 MB in  3.02 seconds =  24.52 MB/sec

/dev/hdd:

 Timing cached reads:   260 MB in  2.03 seconds = 128.22 MB/sec

 Timing buffered disk reads:   94 MB in  3.00 seconds =  31.31 MB/sec

/dev/hde:

 Timing cached reads:   256 MB in  2.02 seconds = 126.88 MB/sec

 Timing buffered disk reads:  108 MB in  3.01 seconds =  35.91 MB/sec

```

hdparm

```

/dev/hdc:

 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 = 82348277760, start = 0

/dev/hdd:

 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     = 24321/255/63, sectors = 200049647616, start = 0

/dev/hde:

 multcount    = 16 (on)

 IO_support   =  0 (default 16-bit)

 unmaskirq    =  0 (off)

 using_dma    =  1 (on)

 keepsettings =  0 (off)

 readonly     =  0 (off)

 readahead    = 256 (on)

 geometry     = 24321/255/63, sectors = 200049647616, start = 0

```

(part of) lspci

```

0000:00:00.0 Host bridge: VIA Technologies, Inc. VT8623 [Apollo CLE266]

0000:00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP]

0000:00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)

0000:00:14.0 RAID bus controller: Silicon Image, Inc. PCI0680 Ultra ATA-133 Host Controller (rev 02)

```

(part of) kernel configuration

```

Device Drivers -->

  ATA/ATAPI/MFM/RLL support -->

    <*> ATA/ATAPI/MFM/RLL support

    <*> Enhanced ATA/ATAPI/MFM/RLL disk/cdrom/floppy/tape support

    <*> Include IDE/ATA-2 DISK support

    [*]   Use multi-mode by default

    <*> Include IDE/ATAPI CDROM support

    < > generic/default IDE chipset support

    [*] PCI IDE chipset support

    [*]   Sharing PCI IDE interrupts support

    < >   Generic PCI IDE chipset support

    [*] Generic PCI bus-master DMA support

    [*]   Use PCI DMA by default when available

    <*>   Silicon Image chipset support

    <*>   VIA82CXXX chipset support 

```

dmesg | grep ide

```

BIOS-provided physical RAM map:

Kernel command line: root=/dev/hdc3 video=vesa:ywrap,mtrr vga=0x314

CPU: After generic identify, caps: 00803035 80803035 00000000 00000000 00000000 00000000 00000000

ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx

    ide0: BM-DMA at 0xd000-0xd007, BIOS settings: hda:DMA, hdb:pio

    ide1: BM-DMA at 0xd008-0xd00f, BIOS settings: hdc:DMA, hdd:pio

Probing IDE interface ide0...

ide0 at 0x1f0-0x1f7,0x3f6 on irq 14

Probing IDE interface ide1...

ide1 at 0x170-0x177,0x376 on irq 15

    ide2: MMIO-DMA , BIOS settings: hde:pio, hdf:pio

    ide3: MMIO-DMA , BIOS settings: hdg:pio, hdh:pio

Probing IDE interface ide2...

ide2 at 0xce810080-0xce810087,0xce81008a on irq 10

Probing IDE interface ide3...

```

I'm concerned that the BIOS settings indicate hdd and hde are in pio mode but since hdparm indicates that dma is turned on, and I get a relatively decent buffered cached read, I assume it is. I don't seem to have an option in the mboard BIOS to switch on dma explicitly and can't do much with the PCI card either (apart from turning RAID on or not which wouldn't make much sense with a single disk!).

I'm intrigued that cached reads are almost exactly the same for each disk and very low. My assumption would be that something in the hardware path common to both IDE controllers is causing the problem but don't have a clue what.

I've tried removing the PCI card, the DVD-ROM, and just leaving hdc. Didn't help. I've booted with knoppix and that gave me (about) the same values for hdparm -tT.

I'd be very grateful if anyone could help. I'm sure I'm missing something obvious so please feel free to point it out whilst rolling your eyes at my stupidity.  :Smile: 

----------

## NeddySeagoon

tintax,

Tell us about your entire disk drive set up - all your IDE drives.

Tell about the ribbon cables used to connect them too. are they 40 or 80 wire?

Transferring from /dev/hdc to /dev/hdd will always be slow because IDE commands cannot be overlapoed.

The data flows over the same cable twice and one drive must complete a command before a command to the other drive is issued. Transfers from one IDE bus to another are much faster.

I suspect you are only getting UDMA2 from your numbers

----------

## tintax

Neddy,

Thanks for your comments.

My IDE setup is:

Onboard VIA VT8235 Controller

ide0:hda Samsung SD-616Q DVD-ROM

ide0:hdb no_device

ide1:hdc Hitachi IC35L080AVVA07-0 HDD

ide1:hdd WD2000JB-00GVA0

PCI Silicon Image Sil680 ATA133 IDE Controller

ide2:hde WD2000BB-00GUA0 HDD

ide2:hdf no_device

ide3:hdg no_device

ide3:hdh no_device

I assume that my ribbon cables are 80 wire; they're rounded cables so my only clue is that they are labelled as ATA/133. I've tried swapping one of them (hde) out for the only spare cable I have that I know is 80 wire and it makes no difference. I use the same cables (got a batch) in other machines without problem.

It was transfering data from one controller to the other (hdd to hde) that originally flagged the problem when I was initially configuring the machine.

----------

## NeddySeagoon

tintax,

If the cables are marked ATA133, they will support that data rate - so thats OK.

Some chipsets don't detect the 80 wire cable properly. It may be in dmesg somewhere.

Adding 

```
ide1=ata66
```

to the kernel line will force the assumption of 80 wire cables on ide1, regardless of whats fitted or actually detected. Its worth a shot.

----------

## tintax

NeddySeagoon,

Nope  :Sad:  I'm afraid that didn't help. Thanks for taking the time to help me though  :Smile: 

Since it seems to be affecting both controllers, could there be some hardware common to both that I'm not configuring properly (some sort of bus?)? I know enough to build a machine (i.e. enough to be dangerous) but I get a bit lost at this level.

----------

## NeddySeagoon

tintax,

Can you post the output of 

```
hdparm -iI /dev/hdd
```

One if the Is tells you what the drive advertised itself as, the other tells how its actually being operated. The two can be different.

----------

## tintax

Here you go, hope it makes more sense to you than it does to me!

hdparm -iI /dev/hdd

```

/dev/hdd:

 Model=WDC WD2000JB-00GVA0, FwRev=08.02D08, SerialNo=WD-WCAL81634160

 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }

 RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=74

 BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=16

 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455

 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

 AdvancedPM=no WriteCache=enabled

 Drive conforms to: device does not report version:

 * signifies the current active mode

ATA device, with non-removable media

        Model Number:       WDC WD2000JB-00GVA0

        Serial Number:      WD-WCAL81634160

        Firmware Revision:  08.02D08

Standards:

        Supported: 6 5 4 3

        Likely used: 6

Configuration:

        Logical         max     current

        cylinders       16383   65535

        heads           16      1

        sectors/track   63      63

        --

        CHS current addressable sectors:    4128705

        LBA    user addressable sectors:  268435455

        LBA48  user addressable sectors:  390721968

        device size with M = 1024*1024:      190782 MBytes

        device size with M = 1000*1000:      200049 MBytes (200 GB)

Capabilities:

        LBA, IORDY(can be disabled)

        bytes avail on r/w long: 74     Queue depth: 1

        Standby timer values: spec'd by Standard, with device specific minimum

        R/W multiple sector transfer: Max = 16  Current = 16

        Recommended acoustic management value: 128, current value: 254

        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5

             Cycle time: min=120ns recommended=120ns

        PIO: pio0 pio1 pio2 pio3 pio4

             Cycle time: no flow control=120ns  IORDY flow control=120ns

Commands/features:

        Enabled Supported:

           *    READ BUFFER cmd

           *    WRITE BUFFER cmd

           *    Host Protected Area feature set

           *    Look-ahead

           *    Write cache

           *    Power Management feature set

                Security Mode feature set

           *    SMART feature set

           *    FLUSH CACHE EXT command

           *    Mandatory FLUSH CACHE command

           *    Device Configuration Overlay feature set

           *    48-bit Address feature set

                Automatic Acoustic Management feature set

                SET MAX security extension

           *    DOWNLOAD MICROCODE cmd

           *    SMART self-test

           *    SMART error logging

Security:

                supported

        not     enabled

        not     locked

        not     frozen

        not     expired: security count

        not     supported: enhanced erase

HW reset results:

        CBLID- above Vih

        Device num = 1 determined by CSEL

Checksum: correct

```

hdparm -iI /dev/hde

```

/dev/hde:

 Model=WDC WD2000BB-00GUA0, FwRev=08.02D08, SerialNo=WD-WCAL81792022

 Config={ HardSect NotMFM HdSw>15uSec SpinMotCtl Fixed DTR>5Mbs FmtGapReq }

 RawCHS=16383/16/63, TrkSize=57600, SectSize=600, ECCbytes=74

 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=16

 CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=268435455

 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

 AdvancedPM=no WriteCache=enabled

 Drive conforms to: device does not report version:

 * signifies the current active mode

ATA device, with non-removable media

        Model Number:       WDC WD2000BB-00GUA0

        Serial Number:      WD-WCAL81792022

        Firmware Revision:  08.02D08

Standards:

        Supported: 6 5 4 3

        Likely used: 6

Configuration:

        Logical         max     current

        cylinders       16383   65535

        heads           16      1

        sectors/track   63      63

        --

        CHS current addressable sectors:    4128705

        LBA    user addressable sectors:  268435455

        LBA48  user addressable sectors:  390721968

        device size with M = 1024*1024:      190782 MBytes

        device size with M = 1000*1000:      200049 MBytes (200 GB)

Capabilities:

        LBA, IORDY(can be disabled)

        bytes avail on r/w long: 74     Queue depth: 1

        Standby timer values: spec'd by Standard, with device specific minimum

        R/W multiple sector transfer: Max = 16  Current = 16

        Recommended acoustic management value: 128, current value: 254

        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5

             Cycle time: min=120ns recommended=120ns

        PIO: pio0 pio1 pio2 pio3 pio4

             Cycle time: no flow control=120ns  IORDY flow control=120ns

Commands/features:

        Enabled Supported:

           *    READ BUFFER cmd

           *    WRITE BUFFER cmd

           *    Host Protected Area feature set

           *    Look-ahead

           *    Write cache

           *    Power Management feature set

                Security Mode feature set

           *    SMART feature set

           *    FLUSH CACHE EXT command

           *    Mandatory FLUSH CACHE command

           *    Device Configuration Overlay feature set

           *    48-bit Address feature set

           *    Automatic Acoustic Management feature set

                SET MAX security extension

           *    DOWNLOAD MICROCODE cmd

           *    SMART self-test

           *    SMART error logging

Security:

                supported

        not     enabled

        not     locked

        not     frozen

        not     expired: security count

        not     supported: enhanced erase

HW reset results:

        CBLID- above Vih

        Device num = 0 determined by CSEL

Checksum: correct

```

----------

## NeddySeagoon

tintax,

Hmm,

 *Quote:*   

> Recommended acoustic management value: 128, current value: 254 

 

Fiddling with this number changes the drive head seeking behaviour, it gets quieter at the expense of increased head movement times.

use hdparm to set it to 128 (see man hdparm) then run thge speed tests 

```
hdparam -tT /dev/... 
```

again.

I can't rememeber which way round the scale is - if higher numbers are louder (and faster) or not.

Everything else looks good.  What does your /proc/interupts show? Ideally the HDDs should be on their own.

ide0 is IRQ 14

ide1 is IRQ 15

Any IDE controllers in PCI slots may have to share IRQs. That can slow things down.

----------

## tintax

NeddySeagoon

Sorry for delay in getting back to you; I've been a bit under the weather.

Changing the acustic management hasn't made any difference:

```

spike ~ # hdparm -tT /dev/hdd

/dev/hdd:

 Timing cached reads:   228 MB in  2.00 seconds = 113.85 MB/sec

 Timing buffered disk reads:   98 MB in  3.05 seconds =  32.17 MB/sec

spike ~ # hdparm -tT /dev/hde

/dev/hde:

 Timing cached reads:   264 MB in  2.01 seconds = 131.04 MB/sec

 Timing buffered disk reads:  118 MB in  3.05 seconds =  38.72 MB/sec

spike ~ # hdparm -tT /dev/hdc

/dev/hdc:

 Timing cached reads:   264 MB in  2.01 seconds = 131.23 MB/sec

 Timing buffered disk reads:   96 MB in  3.04 seconds =  31.63 MB/sec

```

My PCI based IDE card is sharing an IRQ but the onboard controller is not:

```

spike ~ # cat /proc/interrupts

           CPU0

  0:   85534013          XT-PIC  timer

  1:        903          XT-PIC  i8042

  2:          0          XT-PIC  cascade

  5:          0          XT-PIC  uhci_hcd, VIA8233

  9:          0          XT-PIC  acpi

 10:       1970          XT-PIC  ide2, ohci1394, uhci_hcd

 11:       2119          XT-PIC  ehci_hcd, uhci_hcd, eth0

 12:      30149          XT-PIC  i8042

 14:     768988          XT-PIC  ide0

 15:      44468          XT-PIC  ide1

NMI:          0

LOC:          0

ERR:          1

```

[/quote]

----------

## NeddySeagoon

tintax,

Hmm. Does your CPU have an APIC ?

Check in /proc/cpuinfo for the flag apic.

If its there enable Local APIC support on uniprocessors and IO-APIC support on uniprocessors in the Processor type and features menu. Rebuild and install you kernel. It gets you more IRQs, which may help.

/proc/interrupts will change from XT-PIC to IO-APIC if it works. You may need to add lapic to you kernel command line in grub.conf.

----------

## tintax

NeddySeagoon,

The CPU does not have an APIC. Given this, I changed Local APIC (and IO-APIC) suppport to disabled and re-compiled; it didn't help matters any.

I have now found a series of posts (http://forums.viaarena.com/messageview.aspx?catid=28&threadid=60131&STARTPAGE=1&FTVAR_FORUMVIEWTMP=Linear) that indicates the 8235 chipset on the EPIA-M may have severe problems with DMA bursts. Using DMA to transfer MPEG to the chip may lockup up the system when other DMA transfers are active, such as harddisk dma data transfers and data transfers to/from the network card.

I'm not having lockups and I haven't seen anything in the thread yet about slow transfer speeds (only half way through) but it does point at a known hardware issue with the chipset which might explain my situation.

Regards,

Matt

----------

