[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: 7200 RPM udma33 same speed as 5400 PIO mode 4



On Thu, Feb 10, 2000 at 08:40:29AM -0700, Rick Macdonald generated a stream of 1s and 0s:
> 
> I added a Maxtor 27GB 7200rpm ATA66 drive to my P200MMX when I upgraded to
> potatos and kernel 2.2.14.
> 
> My motherboard (ASUS TX97-E) only supports udma mode 2 (33MB/sec), but I
> find that this drive and my old WD 4GB (no UDMA) both show the same speed
> of about 9.4MB/sec with hdparm -t. Even if the new drive is the only drive
> on the primary IDE interface.
> 
> All the boot messages and hdparm info seems to indicate that the UDMA-2 is
> recognized, but why don't I see any speed difference?
> 
> Here is the output of hdparm -v -i for both drives:
> 
> /dev/hda: (MAXTOR 27GB, UDMA)
> 
>  multcount    =  0 (off)
>  I/O support  =  0 (default 16-bit)
>  unmaskirq    =  0 (off)
>  using_dma    =  1 (on)
>  keepsettings =  0 (off)
>  nowerr       =  0 (off)
>  readonly     =  0 (off)
>  readahead    =  8 (on)
>  geometry     = 3322/255/63, sectors = 53369568, start = 0
> 

You can't expect any improvents unless you turn multcount to 16 or to
whatever your drive supports, and switch I/O into 32bit mode. Just with
those two turned on, my WD goes from 6 to 12 MB/s without using DMA.
Also I recommend setting unmaskirq to on, because that frees up your CPU
when it does disk transfer; the multcount setting saves you the number
of interrupts per transfer the size of this setting (i.e. 1 interrupt per 16 blocks instead of 16 interrupts per 16 blocks) that you set it to, so it's very important, so is 32 bit transfer mode. The 16 bit mode is really an archaic setting
dating back to early Pentium and 486 machines, this issue really needs
to be addressed on distribution level, since most people don't bother
playing with hdparm at all, they're always SLOW. What's ironic, is you
can configure your kernel to enable DMA, but can't enable 32 bit I/O.
-- 
Get the truth or risc frying your brains! --> www.truthinlabeling.org <--


Reply to: