[Gllug] IDE issues

Stephen Harker steve at pauken.co.uk
Tue Apr 16 17:22:56 UTC 2002


On Mon, 2002-04-15 at 18:27, Christian Smith wrote:
> On Mon, 15 Apr 2002, Stephen Harker wrote:
> 
> >On Mon, 15 Apr 2002, Bruce Richardson wrote:
> >
> >> On 15/04/02, 11:26:30, Kim Hawtin <kim at aldigital.co.uk> wrote regarding Re: 
> >> [Gllug] IDE issues:
> >> 
> >> 
> >> > this may sound like a silly question, but have used the new fangled
> >> > high density cables?
> >> 
> >> Aye, if you use a standart IDE cable then it falls back to slower UDMA 
> >> settings.  The new cables are distinctive, being round and colour coded 
> >> to show which end goes where.  
> >> 
> >> http://www.cablesnmor.com/images/round-ide-cables.jpg
> >> 
> >> 
> >Yep I used the new-fangled fancy-coloured IDE cable. I tried to plug a DVD 
> >drive into the second IDE channel with a regular cable and it wouldn't 
> >even boot! So I had no choice on that one. I haven't fiddled with the DMA 
> >modes yet in BIOS so I'll try that.
> 
> When doing the update, do you have excessively high system usage. If so, 
> then this would indicate that the drive is in PIO mode, which I believe 
> generates an interrupt for each byte transferred! DMA is generally not 
> turned on by default.
> 
> To check, run:
> # hdparm -d /dev/hd?
> 
> If it comes back with:
> /dev/hd?:
>  using_dma    =  0 (off)
> 
> Turn it on with:
> # hdparm -d1 /dev/hd?
> 
> You might also want to use 32bit transfers, and multicount sector 
> transfer.
> 
> # hdparm -d1 -c1 -m16 /dev/hd?
> 
> This should set multi-sector to 16, which most drives appear to support in 
> my experience. Maybe even try 32.
> 
> Finally, before and after doing the above mods, try 'benchmarking' the 
> drive using the -T and -t options to hdparm. In unoptimised PIO mode, 
> you'll maybe get 3-8 MB/s with a modern drive. With DMA, 32bit IO and 
> multi-sector transfer, that should go up to ~40 MB/s, a substantial 
> improvement, and with MUCH less overhead on the CPU.
> 
> # hdparm -Tt /dev/hd?
> /dev/hd?:
>  Timing buffer-cache reads:   128 MB in  0.49 seconds =261.22 MB/sec
>  Timing buffered disk reads:  64 MB in  1.70 seconds = 37.65 MB/sec

[root at abe steve]# hdparm -d0 -c0 -m0 /dev/hda

/dev/hda:
 setting 32-bit I/O support flag to 0
 setting multcount to 0
 setting using_dma to 0 (off)
 HDIO_SET_DMA failed: Operation not permitted
 multcount    =  0 (off)
 I/O support  =  0 (default 16-bit)
 using_dma    =  0 (off)
[root at abe steve]# hdparm -Tt /dev/hda

/dev/hda:
 Timing buffer-cache reads:   128 MB in  0.46 seconds =278.26 MB/sec
 Timing buffered disk reads:  64 MB in 20.68 seconds =  3.09 MB/sec
[root at abe steve]# hdparm -d1 -c1 -m16 /dev/hda

/dev/hda:
 setting 32-bit I/O support flag to 1
 setting multcount to 16
 setting using_dma to 1 (on)
 HDIO_SET_DMA failed: Operation not permitted
 multcount    = 16 (on)
 I/O support  =  1 (32-bit)
 using_dma    =  0 (off)
[root at abe steve]# hdparm -Tt /dev/hda

/dev/hda:
 Timing buffer-cache reads:   128 MB in  0.48 seconds =266.67 MB/sec
 Timing buffered disk reads:  64 MB in 10.47 seconds =  6.11 MB/sec
[root at abe steve]#

For some reason, I can't enable DMA mode at all :-/
And the buffered disk read rate is terrible. It's better than it was
admittedly. But it should be a lot better! Maybe the kernel doesn't
recognise the ATA133 chipset and can't see the DMA part. It works fine
under *cough* XP :-/

Do I put this in rc.local or something to reactivate at boot or what?

Steve




-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug




More information about the GLLUG mailing list