[Gllug] IDE issues

[Formi]

 Have you cheked the -u setting? It doesnt make any difference on
 the throutput my laptop, even though it is a standard Intel MX disk 
 controller,  I have never been able to activate the dma. 

 6.5 mb/s on a 3GB laptop harddisk is not that bad, but I suspect
 that when I boot w98 to access the bios, with the ibm provided
 drivers it "feels" somewhat faster than on linux. 
 
 

       -u     Get/set  interrupt-unmask  flag  for  the drive.  A
              setting of u permits the  driver  to  unmask  other
              interrupts  during  processing of a disk interrupt,
              which greatly improves Linux's  responsiveness  and
              eliminates  "serial port overrun" errors.  



 Hoping that what I have said is accurate, ...

						Formi.



On 16 Apr 2002, Stephen Harker wrote:

> 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