UDMA 100 / PIIX4 question

UDMA 100 / PIIX4 question

[quintaq]

Hi,

This question is much the same as one I posted a couple of months ago, at which time I was using the stock 2.2.18 kernel supplied with my SuSE distro.  Some people suggested that I should upgrade, and since then I have been learning my way around kernel compilation and following this list.  I am now running 2.4.2, but my problem remains, so I thought I might reasonably ask again.

I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), which has a PIIX4 controller.

The drive is properly cabled and correctly recognised.  I have, I think, set the right options in my kernel config (I have quoted the relevant part  below).  Lilo.conf includes append="ide0=ata66.

Boot.msg includes:

<4>PIIX4: chipset revision 1
<4>PIIX4: not 100% native mode: will probe irqs later
<4>PIIX4: ATA-66/100 forced bit set (WARNING)!!
<4>    ide0: BM-DMA at 0xa800-0xa807, BIOS settings: hda:DMA, hdb:pio
<4>    ide1: BM-DMA at 0xa808-0xa80f, BIOS settings: hdc:DMA, hdd:pio
<4>hda: IBM-DTLA-307030, ATA DISK drive
<snip> ...
<6>hda: 60036480 sectors (30739 MB) w/1916KiB Cache, CHS=3737/255/63, UDMA(100)

According to hdparm -i the drive thinks that it is in UDMA mode 5.

My problem is that (according to hdparm -t), I never get a better transfer rate than approximately 15.8 Mb/sec.  I achieve this when DMA is enabled, - without it I fall back to about 5 Mb /sec.  No amount of fiddling with other hdparm settings makes any difference.

I do appreciate that there are some issues involving higher UDMA rates and certain hardware.  I have read a number of relevant posts, including those passing between Linus, Andre Hedrick, Alan Cox and others on the subject last January, but I cannot understand from what I have read whether or not my particular configuration (in particular the PIIX4),is subject to these problems - or if I am simply screwed up.

TIA,

Geoff

CONFIG_BLK_DEV_IDEDISK=y
# CONFIG_IDEDISK_MULTI_MODE is not set
# CONFIG_BLK_DEV_IDEDISK_VENDOR is not set
# CONFIG_BLK_DEV_IDEDISK_FUJITSU is not set
# CONFIG_BLK_DEV_IDEDISK_IBM is not set
# CONFIG_BLK_DEV_IDEDISK_MAXTOR is not set
# CONFIG_BLK_DEV_IDEDISK_QUANTUM is not set
# CONFIG_BLK_DEV_IDEDISK_SEAGATE is not set
# CONFIG_BLK_DEV_IDEDISK_WD is not set
# CONFIG_BLK_DEV_COMMERIAL is not set
# CONFIG_BLK_DEV_TIVO is not set
# CONFIG_BLK_DEV_IDECS is not set
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
# CONFIG_BLK_DEV_CMD640 is not set
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
# CONFIG_BLK_DEV_ISAPNP is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_IDEDMA_PCI_WIP is not set
# CONFIG_IDEDMA_NEW_DRIVE_LISTINGS is not set
# CONFIG_BLK_DEV_AEC62XX is not set
# CONFIG_AEC62XX_TUNING is not set
# CONFIG_BLK_DEV_ALI15X3 is not set
# CONFIG_WDC_ALI15X3 is not set
# CONFIG_BLK_DEV_AMD7409 is not set
# CONFIG_AMD7409_OVERRIDE is not set
# CONFIG_BLK_DEV_CMD64X is not set
# CONFIG_BLK_DEV_CY82C693 is not set
# CONFIG_BLK_DEV_CS5530 is not set
# CONFIG_BLK_DEV_HPT34X is not set
# CONFIG_HPT34X_AUTODMA is not set
# CONFIG_BLK_DEV_HPT366 is not set
CONFIG_BLK_DEV_PIIX=y
CONFIG_PIIX_TUNING=y
# CONFIG_BLK_DEV_NS87415 is not set
# CONFIG_BLK_DEV_OPTI621 is not set
# CONFIG_BLK_DEV_PDC202XX is not set
# CONFIG_PDC202XX_BURST is not set
# CONFIG_BLK_DEV_OSB4 is not set
# CONFIG_BLK_DEV_SIS5513 is not set
# CONFIG_BLK_DEV_SLC90E66 is not set
# CONFIG_BLK_DEV_TRM290 is not set
# CONFIG_BLK_DEV_VIA82CXXX is not set
# CONFIG_IDE_CHIPSETS is not set
CONFIG_IDEDMA_AUTO=y
CONFIG_IDEDMA_IVB=y
# CONFIG_DMA_NONPCI is not set
CONFIG_BLK_DEV_IDE_MODES=y

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: UDMA 100 / PIIX4 question

[Tim Moore]

quintaq@yahoo.co.uk wrote:
> I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), which has a PIIX4 controller.
> ...
> My problem is that (according to hdparm -t), I never get a better transfer rate than approximately 15.8 Mb/sec.  I achieve this when DMA is enabled, - without it I fall back to about 5 Mb /sec.  No amount of fiddling with other hdparm settings makes any difference.
> ...

15MB/s for hdparm is about right.

"...four IDE devices can be supported in Bus Master mode.
 PIIX4 contains support for "Ultra DMA/33" synchronous DMA
 compatible devices."

http://developer.intel.com/design/intarch/techinfo/440BX/PIIX4_intro.htm

--

Re: UDMA 100 / PIIX4 question

[Jeremy Jackson]

Tim Moore wrote:

> quintaq@yahoo.co.uk wrote:
> > I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), which has a PIIX4 controller.
> > ...
> > My problem is that (according to hdparm -t), I never get a better transfer rate than approximately 15.8 Mb/sec.  I achieve this when DMA is enabled, - without it I fall back to about 5 Mb /sec.  No amount of fiddling with other hdparm settings makes any difference.
> > ...
>
> 15MB/s for hdparm is about right.

Yes, since hdparm -t measures *SUSTAINED* transfers... the actual "head rate" of data reads from
disk surface.  Only if you read *only* data that is alread in harddrive's cache will you get a speed
close to the UDMA mode of the drive/controller.  The cache is around 1Mbyte, so for a split-second
re-read of some data....

>
>
> "...four IDE devices can be supported in Bus Master mode.
>  PIIX4 contains support for "Ultra DMA/33" synchronous DMA
>  compatible devices."
>
> http://developer.intel.com/design/intarch/techinfo/440BX/PIIX4_intro.htm
>
> --
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: UDMA 100 / PIIX4 question

[Tim Moore]

Jeremy Jackson wrote:
> 
> Tim Moore wrote:
> > 15MB/s for hdparm is about right.
> 
> Yes, since hdparm -t measures *SUSTAINED* transfers... the actual "head rate" of data reads from
> disk surface.  Only if you read *only* data that is alread in harddrive's cache will you get a speed
> close to the UDMA mode of the drive/controller.  The cache is around 1Mbyte, so for a split-second
> re-read of some data....

Apologies for the too brief answer.  Sustained real world transfer rates for the PIIX4 under ideal
setup conditions and a quiet bus are 14-18MB/s.  Faster disk architecture and forcing ide driver
parameters will not change this.

Here's what you might expect from this disk family with an ATA-66 capable chipset:

[tim@abit tim]# hdparm -i /dev/hda; hdparm -tT /dev/hda

/dev/hda:

 Model=IBM-DTLA-307020, FwRev=TX3OA50C, SerialNo=YH0YHF45553
 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=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=40188960
 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 

/dev/hda:
 Timing buffer-cache reads:   128 MB in  0.81 seconds =158.02 MB/sec
 Timing buffered disk reads:  64 MB in  1.85 seconds = 34.59 MB/sec

Larger sustained transfers are about 75% of the burst/cache influenced hdparm timings.

[tim@abit tim]# time dd if=/dev/hda of=/dev/null bs=1k count=500k
512000+0 records in
512000+0 records out
0.340u 6.780s 0:19.68 36.1%     0+0k 0+0io 115pf+0w
[tim@abit tim]# echo "512000/19.68" | bc -q
26016

-- 
  |  650.390.9613  |  6502247437@messaging.cellone-sf.com

Re: UDMA 100 / PIIX4 question

[quintaq]

On Mon, 19 Mar 2001 12:17:38 -0800
Tim Moore <timothymoore@bigfoot.com> wrote:

> Jeremy Jackson wrote:
> > 
> > Tim Moore wrote:
> > > 15MB/s for hdparm is about right.
> > 
> > Yes, since hdparm -t measures *SUSTAINED* transfers... the actual
> "head rate" of data reads from
> > disk surface.  Only if you read *only* data that is alread in
> harddrive's cache will you get a speed
> > close to the UDMA mode of the drive/controller.  The cache is around
> 1Mbyte, so for a split-second
> > re-read of some data....
> 
> Apologies for the too brief answer.  Sustained real world transfer rates
> for the PIIX4 under ideal
> setup conditions and a quiet bus are 14-18MB/s.  Faster disk
> architecture and forcing ide driver
> parameters will not change this.
> 
> Here's what you might expect from this disk family with an ATA-66
> capable chipset:
> 
> [tim@abit tim]# hdparm -i /dev/hda; hdparm -tT /dev/hda
> 
<snip>

> /dev/hda:
>  Timing buffer-cache reads:   128 MB in  0.81 seconds =158.02 MB/sec
>  Timing buffered disk reads:  64 MB in  1.85 seconds = 34.59 MB/sec
> 
> Larger sustained transfers are about 75% of the burst/cache influenced
> hdparm timings.
> 
> [tim@abit tim]# time dd if=/dev/hda of=/dev/null bs=1k count=500k
> 512000+0 records in
> 512000+0 records out
> 0.340u 6.780s 0:19.68 36.1%     0+0k 0+0io 115pf+0w
> [tim@abit tim]# echo "512000/19.68" | bc -q
> 26016
> 

Hi,

First, many thanks to you both for responding (and Jerry for his further post mentioned below).  Can I throw in the some actual figures just obtained on my system, and ask if these are consistent with what you are saying ?

cat /proc/ide/piix :

                                Intel PIIX4 Ultra 100 Chipset.
--------------- Primary Channel ---------------- Secondary Channel -------------
                 enabled                          enabled
--------------- drive0 --------- drive1 -------- drive0 ---------- drive1 ------
DMA enabled:    yes              no              yes               no 
UDMA enabled:   yes              no              yes               no 
UDMA enabled:   5                X               2                 X
UDMA
DMA
PI

hdparm -tT /dev/hda :

/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.04 seconds =123.08 MB/sec
 Timing buffered disk reads:  64 MB in  4.24 seconds = 15.09 MB/sec


time dd if=/dev/hda of=/dev/null bs=1k count=500k :
512000+0 records in
512000+0 records out

real    0m26.636s
user    0m0.220s
sys     0m8.190s


(d) bonnie -s 1000

              ---Sequential Output (nosync)--- ---Sequential Input-- --Rnd Seek-
              -Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --04k (03)-
Machine    MB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU   /sec %CPU
       1*1000 10532 91.3 17757 11.3  6481  5.2  9604 71.1 20937 12.1  131.7  1.9


I had just written the above when the following post from Jeremy arrived :

"You should be able to get about 30 MB/s at the start of the disk (zone 0) 
so if you were testing say /dev/hda1 which is at the start of the disk it should be faster.

Try hdparm -i /dev/hda (or whatever) .. . note the reported MaxMultSect= value,
and put it in place of X in command:

hdparm -u 1 -d 1 -m X -c 1 /dev/hda

Cheers,

Jeremy

PS - please let me know if this fixed your problem, since I have a system
with the same motherboard."

There is a Win partition - so I do not think I am at the start of the drive.

hdparm -i /dev/hda gives :

/dev/hda:

 Model=IBM-DTLA-307030, FwRev=TX4OA50C, SerialNo=YKDYKLN6151
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=40
 BuffType=3(DualPortCache), BuffSize=1916kB, MaxMultSect=16, MultSect=16
 DblWordIO=no, OldPIO=2, DMA=yes, OldDMA=2
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=60036480
 tDMA={min:120,rec:120}, DMA modes: mword0 mword1 mword2 
 IORDY=on/off, tPIO={min:240,w/IORDY:120}, PIO modes: mode3 mode4 
 UDMA modes: mode0 mode1 mode2 mode3 mode4 *mode5 
 Drive Supports : Reserved : ATA-2 ATA-3 ATA-4 ATA-5 

I therefore tried hdparm -u 1 -d 1 -m 16 -c 1 -X69 /dev/hda :

/dev/hda:
 setting 32-bit I/O support flag to 1
 setting multcount to 16
 setting unmaskirq to 1 (on)
 setting using_dma to 1 (on)
 setting xfermode to 69 (UltraDMA mode5)
 multcount    = 16 (on)
 I/O support  =  1 (32-bit)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)

Then  hdparm -tT /dev/hda

/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.04 seconds =123.08 MB/sec
 Timing buffered disk reads:  64 MB in  4.08 seconds = 15.69 MB/sec

These are, I fear, the figures I usually see.

Bed-time for Brits.

Regards,

Geoff

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: UDMA 100 / PIIX4 question

[Holger Lubitz]

quintaq@yahoo.co.uk wrote:
> 
> On Mon, 19 Mar 2001 12:17:38 -0800
> Tim Moore <timothymoore@bigfoot.com> wrote:
> 
> > Apologies for the too brief answer.  Sustained real world transfer rates
> > for the PIIX4 under ideal
> > setup conditions and a quiet bus are 14-18MB/s.

I dare to disagree. These numbers are from an Asus P2L97-DS (Dual P2,
Intel 440LX chipset with PIIX4) with an IBM DTLA 307045:

/dev/hda5:
 Timing buffer-cache reads:   128 MB in  1.21 seconds =105.79 MB/sec
 Timing buffered disk reads:  64 MB in  2.30 seconds = 27.83 MB/sec

/dev/hda5 is the outermost linux partition, starting at cyl 256.

(if you don't count hdparm measurements as real world transfer rates -
linear read as measured by bonnie is 26.3 MB/s).

> There is a Win partition - so I do not think I am at the start of the drive.
> 
> Then  hdparm -tT /dev/hda
> 
> /dev/hda:
>  Timing buffer-cache reads:   128 MB in  1.04 seconds =123.08 MB/sec
>  Timing buffered disk reads:  64 MB in  4.08 seconds = 15.69 MB/sec

Would your windows partition by any chance be at the beginning of the
disk?
hdparm speed measurements differ by filesystem (i have no idea why,
since they don't go through it - maybe some interaction with the
buffering code).

if you are testing a windows partition, you can expect to see
significantly lower values for hdparm:

/dev/hda1:
 Timing buffer-cache reads:   128 MB in  1.65 seconds = 77.58 MB/sec
 Timing buffered disk reads:  64 MB in  3.48 seconds = 18.39 MB/sec

Remarkably /dev/hda benches slightly better, even though the 64 MB read
are nearly the same as for hda1:

/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.40 seconds = 91.43 MB/sec
 Timing buffered disk reads:  64 MB in  3.06 seconds = 20.92 MB/sec

I also noticed that operations on a lot of files (like scanning for all
files in a filesystem as done by updatedb) got really slow with the 2.4
vfat fs, with a very high percentage (in the 90s) of CPU time attributed
to "system". Has anybody else noticed this?

Holger

Re: UDMA 100 / PIIX4 question

[Jeremy Jackson]

Holger Lubitz wrote:

> quintaq@yahoo.co.uk wrote:
> >
> > On Mon, 19 Mar 2001 12:17:38 -0800
> > Tim Moore <timothymoore@bigfoot.com> wrote:
> >
> > > Apologies for the too brief answer.  Sustained real world transfer rates
> > > for the PIIX4 under ideal
> > > setup conditions and a quiet bus are 14-18MB/s.
>
> I dare to disagree. These numbers are from an Asus P2L97-DS (Dual P2,
> Intel 440LX chipset with PIIX4) with an IBM DTLA 307045:

Yes this is why I originally replied to the post... but he's not using a PIIXx at
all,
but the IDE chip on an Intel 815 motherboard.  I'm not sure if they use the same
driver
, but I don't think so.

>
>
> /dev/hda5:
>  Timing buffer-cache reads:   128 MB in  1.21 seconds =105.79 MB/sec
>  Timing buffered disk reads:  64 MB in  2.30 seconds = 27.83 MB/sec
>
> /dev/hda5 is the outermost linux partition, starting at cyl 256.
>
> (if you don't count hdparm measurements as real world transfer rates -
> linear read as measured by bonnie is 26.3 MB/s).
>
> > There is a Win partition - so I do not think I am at the start of the drive.
> >
> > Then  hdparm -tT /dev/hda
> >
> > /dev/hda:
> >  Timing buffer-cache reads:   128 MB in  1.04 seconds =123.08 MB/sec
> >  Timing buffered disk reads:  64 MB in  4.08 seconds = 15.69 MB/sec
>
> Would your windows partition by any chance be at the beginning of the
> disk?
> hdparm speed measurements differ by filesystem (i have no idea why,

this is false.  They may differ by partition, since different parts (zones) of a
modern disk have different recording densities and therefore transfer rates.
IBM's spec sheet says rates vary from 15MB/sec to 31MB/sec... it he's seeing
15MB/sec, maybe he should try the other end of the disk.  can you verify this?
try hdparm -t /dev/hda1 instead of hda5 (if those are on opposite ends of the
disk)

include output of fdisk so we can see partition layout, and results of hdparm on
different areas.

>
> since they don't go through it - maybe some interaction with the
> buffering code).
>
> if you are testing a windows partition, you can expect to see
> significantly lower values for hdparm:
>
> /dev/hda1:
>  Timing buffer-cache reads:   128 MB in  1.65 seconds = 77.58 MB/sec
>  Timing buffered disk reads:  64 MB in  3.48 seconds = 18.39 MB/sec

please show us your partition table.

>
>
> Remarkably /dev/hda benches slightly better, even though the 64 MB read
> are nearly the same as for hda1:
>
> /dev/hda:
>  Timing buffer-cache reads:   128 MB in  1.40 seconds = 91.43 MB/sec
>  Timing buffered disk reads:  64 MB in  3.06 seconds = 20.92 MB/sec
>
> I also noticed that operations on a lot of files (like scanning for all
> files in a filesystem as done by updatedb) got really slow with the 2.4
> vfat fs, with a very high percentage (in the 90s) of CPU time attributed
> to "system". Has anybody else noticed this?

Re: UDMA 100 / PIIX4 question

[quintaq]

Hi,

First, thank you very much Mark, Tim, Jeremy and Holger for your continuing contributions which, I think, are at last casting some light on my "problem".

> Yes this is why I originally replied to the post... but he's not using a
> PIIXx at
> all,
> but the IDE chip on an Intel 815 motherboard.  I'm not sure if they use
> the same
> driver
> , but I don't think so.
> 

I found a helpful post from Peter Denison on 6th January this year which suggests that it is at least the same driver.

"Description:
Includes new PCI device IDs for the Intel i815E chipset, and corrects some
of the names for the associated parts of the chipset. This has effects in
the EEPro100 network driver and the PCI IDE driver.
Detail & Justification:
The Intel ICH2 (I/O Controller Hub 2) is used in several chipsets, not
just the 820 (Camino) chipset it is accredited to in the PCI ID database.
Nor is the IDE portion of the ICH2 really a PIIX4 chip, though it is very
similar and PIIX driver works on both. These changes are just
internal macro naming and minor user interface tweaks."


> try hdparm -t /dev/hda1 instead of hda5 (if those are on opposite ends
> of the
> disk)
> 
> include output of fdisk so we can see partition layout, and results of
> hdparm on
> different areas.

Here is my fdisk output :

Disk /dev/hda: 255 heads, 63 sectors, 3737 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1       932   7486258+   b  Win95 FAT32
/dev/hda2           933      3737  22531162+   5  Extended
/dev/hda5           933       935     24066   83  Linux
/dev/hda6           936       952    136521   82  Linux swap
/dev/hda7           953      3737  22370481   83  Linux


I also ran hdparm -tT /dev/hda1:
 
Timing buffer-cache reads:   128 MB in  1.28 seconds =100.00 MB/sec
 Timing buffered disk reads:  64 MB in  4.35 seconds = 14.71 MB/sec

Which obviously gives much the same result as my usual hdparm -tT /dev/hda

I then tried hdparm -tT /dev/hda7:

 Timing buffer-cache reads:   128 MB in  1.28 seconds =100.00 MB/sec
 Timing buffered disk reads:  64 MB in  2.12 seconds = 30.19 MB/sec

As you would expect, I get almost identical results with several repetitions.

Does this solve the mystery ?

Regards,

Geoff

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: UDMA 100 / PIIX4 question

[Mark Hahn]

>    Device Boot    Start       End    Blocks   Id  System
> /dev/hda1   *         1       932   7486258+   b  Win95 FAT32
> /dev/hda2           933      3737  22531162+   5  Extended
> /dev/hda5           933       935     24066   83  Linux
> /dev/hda6           936       952    136521   82  Linux swap
> /dev/hda7           953      3737  22370481   83  Linux
> 
> 
> I also ran hdparm -tT /dev/hda1:
>  
> Timing buffer-cache reads:   128 MB in  1.28 seconds =100.00 MB/sec
>  Timing buffered disk reads:  64 MB in  4.35 seconds = 14.71 MB/sec
> 
> Which obviously gives much the same result as my usual hdparm -tT /dev/hda
> 
> I then tried hdparm -tT /dev/hda7:
> 
>  Timing buffer-cache reads:   128 MB in  1.28 seconds =100.00 MB/sec
>  Timing buffered disk reads:  64 MB in  2.12 seconds = 30.19 MB/sec
> 
> As you would expect, I get almost identical results with several repetitions.
> 
> Does this solve the mystery ?

no, it's quite odd.  hdparm -t cannot be effected by the filesystem
that lives in the partition, since hdparm is doing reads that don't
go through the filesystem.  hmm, I wonder if that's it: if you mount
the FS that's in hda1, it might change the block driver configuration
(changing the blocksize, for instance).  that would effect hdparm,
even though its reads don't go through the FS.

prediction: if you comment out the hda1 line in fstab, and reboot,
so that vfat never gets mounted on that partition, I predict that 
hdparm will show >30.19 MB/s on it.

Re: UDMA 100 / PIIX4 question

[quintaq]

On Tue, 20 Mar 2001 16:32:48 -0500 (EST)
Mark Hahn <hahn@coffee.psychology.mcmaster.ca> wrote:

> 
> .... hdparm -t cannot be effected by the filesystem
> that lives in the partition, since hdparm is doing reads that don't
> go through the filesystem.  hmm, I wonder if that's it: if you mount
> the FS that's in hda1, it might change the block driver configuration
> (changing the blocksize, for instance).  that would effect hdparm,
> even though its reads don't go through the FS.
> 
> prediction: if you comment out the hda1 line in fstab, and reboot,
> so that vfat never gets mounted on that partition, I predict that 
> hdparm will show >30.19 MB/s on it.
> 

Hi Mark,

I commented out the line.  Mtab now reported:

/dev/hda7 / ext2 rw 0 0
proc /proc proc rw 0 0
/dev/hda5 /boot ext2 rw 0 0
devpts /dev/pts devpts rw 0 0

The result of hdparm -tT /dev/hda was, however, exactly the same as before (ie circa 15 MB/sec.  The results for /dev/hda7 remain at about 30 MB/sec.

Further, even though the relevant line was commented out of fstab, I could still perform hdparm -tT /dev/hda1 (giving the usual 15 MB/sec).  I suppose that this is because fdisk still showed :

Disk /dev/hda: 255 heads, 63 sectors, 3737 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1       932   7486258+   b  Win95 FAT32
/dev/hda2           933      3737  22531162+   5  Extended
/dev/hda5           933       935     24066   83  Linux
/dev/hda6           936       952    136521   82  Linux swap
/dev/hda7           953      3737  22370481   83  Linux

On the other hand, am I correct in interpreting the bonnie output for the block read (included in my earlier post), of 20937 KB/sec as reasonably healthy for my DTLA (ie consistent with hdparm's 30 MB/sec), when performing more realistic tasks on the linux filesystem ?

Regards,

Geoff

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: UDMA 100 / PIIX4 question

[quintaq]

On Wed, 21 Mar 2001 09:56:56 +0000
quintaq@yahoo.co.uk wrote:

> am I correct in interpreting the bonnie output for
> the block read (included in my earlier post), of 20937 KB/sec as
> reasonably healthy for my DTLA (ie consistent with hdparm's 30 MB/sec),
> when performing more realistic tasks on the linux filesystem ?
> 
I decided to play around a little further.  First, I deleted the "ide0=ata66" from lilo.conf and second I ran bonnie a lot more times.  I found that after the deletion I occasionally (say one time in three or four), saw block reads a little over 30000 KB/sec.  I then tried running bonnie from "/" rather than from a subdirectory.  The result is block reads of better than 30000 KB/sec every time - the record is 37558.  Maybe I should have knowm to run it from root.

Regards,

Geoff

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: UDMA 100 / PIIX4 question

[Mike Dresser]

quintaq@yahoo.co.uk wrote:

> I decided to play around a little further.  First, I deleted the "ide0=ata66" from lilo.conf and second I ran bonnie a lot more times.  I found that after the deletion I occasionally (say one time in three or four), saw block reads a little over 30000 KB/sec.  I then tried running bonnie from "/" rather than from a subdirectory.  The result is block reads of better than 30000 KB/sec every time - the record is 37558.  Maybe I should have knowm to run it from root.

Keep in mind that drives have different transfer rates depending on where on the drive you read from.

mike dresser

Re: UDMA 100 / PIIX4 question

[quintaq]

On Wed, 21 Mar 2001 11:38:47 -0500
Mike Dresser <mdresser@windsormachine.com> wrote:

> 
> Keep in mind that drives have different transfer rates depending on
> where on the drive you read from.
> 
That is something I knew a little about, and am now learning much more.  Even so, I am surprised that there is such an (apparently), tight relationship between the root directory and particular disk zone.

Regards,

Geoff

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: UDMA 100 / PIIX4 question

[Tim Moore]

>    Device Boot    Start       End    Blocks   Id  System
> /dev/hda1   *         1       932   7486258+   b  Win95 FAT32

Try changing to 'c' (fat32+LBA) and check BIOS settings (s/b AUTO or USER,
and LBA).

rgds,
tim.
--

Re: UDMA 100 / PIIX4 question

[Andre Hedrick]

Hello Geoff,

Thanks Mark for doing a great job while I was doing other stuff.

On Wed, 21 Mar 2001 quintaq@yahoo.co.uk wrote:

> The result of hdparm -tT /dev/hda was, however, exactly the same as
> before (ie circa 15 MB/sec.  The results for /dev/hda7 remain at about
> 30 MB/sec.

You may get a burst because of caching prefetch or predictive readahead,
but that is artifical; however, in your case the root directory begins 25%
in the drive.

/sbin/hdparm -t /dev/hda2 /dev/hda5 /dev/hda6 /dev/hda7 /dev/hda8 /dev/hda9 /dev/hda10
/dev/hda2:
 Timing buffered disk reads:  64 MB in  1.80 seconds = 35.56 MB/sec
/dev/hda5:
 Timing buffered disk reads:  64 MB in  1.85 seconds = 34.59 MB/sec
/dev/hda6:
 Timing buffered disk reads:  64 MB in  1.90 seconds = 33.68 MB/sec
/dev/hda7:
 Timing buffered disk reads:  64 MB in  1.95 seconds = 32.82 MB/sec
/dev/hda8:
 Timing buffered disk reads:  64 MB in  1.95 seconds = 32.82 MB/sec
/dev/hda9:
 Timing buffered disk reads:  64 MB in  2.13 seconds = 30.05 MB/sec
/dev/hda10:
 Timing buffered disk reads:  64 MB in  2.13 seconds = 30.05 MB/sec

Disk /dev/hda: 255 heads, 63 sectors, 3737 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1         7     56196   83  Linux
/dev/hda2             8       269   2104515   83  Linux
/dev/hda3           270      3737  27856710    5  Extended
/dev/hda5           270       661   3148708+  83  Linux
/dev/hda6           662       923   2104483+  83  Linux
/dev/hda7           924      1119   1574338+  83  Linux
/dev/hda8          1120      1642   4200966   83  Linux
/dev/hda9          1643      1773   1052226   83  Linux
/dev/hda10         1774      3737  15775798+  83  Linux


> Further, even though the relevant line was commented out of fstab, I
> could still perform hdparm -tT /dev/hda1 (giving the usual 15 MB/sec).
> I suppose that this is because fdisk still showed :
> 
> Disk /dev/hda: 255 heads, 63 sectors, 3737 cylinders
> Units = cylinders of 16065 * 512 bytes
> 
>    Device Boot    Start       End    Blocks   Id  System
> /dev/hda1   *         1       932   7486258+   b  Win95 FAT32
> /dev/hda2           933      3737  22531162+   5  Extended
> /dev/hda5           933       935     24066   83  Linux
> /dev/hda6           936       952    136521   82  Linux swap
> /dev/hda7           953      3737  22370481   83  Linux

First you have the faster portion of the drive using a lame OS, so do not
expect Linux to perform if you put it on the slowest portions of the
device.

> On the other hand, am I correct in interpreting the bonnie output for
> the block read (included in my earlier post), of 20937 KB/sec as
> reasonably healthy for my DTLA (ie consistent with hdparm's 30 MB/sec),
> when performing more realistic tasks on the linux filesystem ?

Yes if you adjust for ZONES.

[root@via DiskPerf-1.0.3]# ./DiskPerf /dev/hda
Device: IBM-DTLA-307030 Serial Number: YKDYKM37674
LBA 0 DMA Read Test                      = 56.53 MB/Sec (4.42 Seconds)
Outer Diameter Sequential DMA Read Test  = 35.47 MB/Sec (7.05 Seconds)
Inner Diameter Sequential DMA Read Test  = 17.74 MB/Sec (14.09 Seconds)

As you can clearly see a single sector v/s outer v/s inner zones produce
different transfer throughputs.

> Regards,
> 
> Geoff

Andre Hedrick
Linux ATA Development

Re: UDMA 100 / PIIX4 question

[Holger Lubitz]

Andre Hedrick wrote:

> You may get a burst because of caching prefetch or predictive readahead,
> but that is artifical; however, in your case the root directory begins 25%
> in the drive.

But still it gives faster transfers than /dev/hda. The question is why.
I do not think that factor 2 can be explained by prefetch or readahead
alone.

> First you have the faster portion of the drive using a lame OS, so do not
> expect Linux to perform if you put it on the slowest portions of the
> device.

:-) But putting it at the beginning at least leaves the linux partitions
together.
Having the root fs in the outermost partition might give slightly faster
transfers, but slightly longer seeks to get there.

> [root@via DiskPerf-1.0.3]# ./DiskPerf /dev/hda

Is that an unreleased version? kernel.org still has 1.0.1.

Holger

Re: UDMA 100 / PIIX4 question

[quintaq]

On Wed, 21 Mar 2001 11:29:00 -0800 (PST)
Andre Hedrick <andre@linux-ide.org> wrote:

> 
> First you have the faster portion of the drive using a lame OS, so do
> not
> expect Linux to perform if you put it on the slowest portions of the
> device.
> 
Hi Andre,

Thanks for responding.  The days of the lame OS are, I hope, numbered.  That is why I am here.  Since assembling this box and getting serious about changing to linux I have got myself 95% M$-free.  I do, however, earn a good deal of my living from stuff I produce on computer, and there are some very specialised apps I need that have not been ported and which won't run under Wine.

> > On the other hand, am I correct in interpreting the bonnie output for
> > the block read (included in my earlier post), of 20937 KB/sec as
> > reasonably healthy for my DTLA (ie consistent with hdparm's 30
> MB/sec),
> > when performing more realistic tasks on the linux filesystem ?
> 
> Yes if you adjust for ZONES.
  
I knew a little about that before, and a lot more now.  Even so, I would not have thought that there would be so close a relationship between a specific zone and "/" as to account for the significantly better performance I see when running bonnie from that directory.

Can I just end with a thanks and a plea ?

The thanks is for all those on the list who have responded, on list and by private email, to my questions.  I am conscious that questions of that kind are not really what this list is for, and I came here only as a last resort.  No-one flamed me.

The plea is that you (or someone), might revise ide.txt to go into a little more detail about UDMA 100 issues, especially with regard to : specific drives and controllers - the use of CONFIG_BLK_DEV_IDE_MODES and append=idex=ataxx.  I know from private emails from people following this thread, and from other lists and newsgroups, that this would be very welcome.

Regards,

Geoff

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: UDMA 100 / PIIX4 question

[Tim Moore]

> >    Device Boot    Start       End    Blocks   Id  System
> > /dev/hda1   *         1       932   7486258+   b  Win95 FAT32
> > ...
> > I also ran hdparm -tT /dev/hda1:
> >
> > Timing buffer-cache reads:   128 MB in  1.28 seconds =100.00 MB/sec
> >  Timing buffered disk reads:  64 MB in  4.35 seconds = 14.71 MB/sec
> >
> > I then tried hdparm -tT /dev/hda7:
> >
> >  Timing buffer-cache reads:   128 MB in  1.28 seconds =100.00 MB/sec
> >  Timing buffered disk reads:  64 MB in  2.12 seconds = 30.19 MB/sec

Change partition type to 'c' (fat32+LBA); check that BIOS is set for
(AUTO or USER) and LBA.


Regarding the PIIX4, I reran basic throughput read tests on a more
recent UDMA5, 5400RPM Maxtor on the PIIX4 and HPT366 (Abit BP6 +
2.2.19p17 + ide.2.2.18.1221.patch) chipsets.

Since pin 30 is plugged on my ATA66 cable, I used an Asus P3B-F as a
ATA66+PIIX4 sanity check.  Neither the Abit or Asus PIIX4 controller
would go higher than UDMA2.  Although hdparm -i reported UDMA4, neither
the -tT or dd tests demonstrated faster results.  The kernel logged
'ide0: Speed warnings UDMA 3/4/5 is not functional' when attempting a
setting higher than UDMA2 on the PIIX4.

Apparently IDE drive technology has improved over the last year,
however real world PIIX4 speeds are still in the 14-19MB/s range.

UDMA2/PIIX4	16-21MB/s
UDMA4/HPT366	19-28MB/s

rgds,
tim.

[tim@asus tim]# lspci
00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
(rev 03)
00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev
03)
00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:0d.0 Ethernet controller: Lite-On Communications Inc LNE100TX (rev20)
00:0f.0 VGA compatible unclassified device: 3DLabs Permedia II 2D+3D (rev
01)
00:13.0 Unknown mass storage controller: Triones Technologies, Inc. HPT366
(rev 01)
00:13.1 Unknown mass storage controller: Triones Technologies, Inc. HPT366
(rev 01)

PIIX4 -----------------------------
[tim@asus tim]# hdparm -iv /dev/hdb

/dev/hdb:
 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     = 2491/255/63, sectors = 40021632, start = 0

 Model=Maxtor 32049H2, FwRev=YAH814Y0, SerialNo=L21R7EKC
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=40021632
 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 

[tim@asus tim]# hdparm -tT /dev/hdb

/dev/hdb:
 Timing buffer-cache reads:   128 MB in  1.47 seconds = 87.07 MB/sec
 Timing buffered disk reads:  64 MB in  3.02 seconds = 21.19 MB/sec

[tim@asus tim]# time dd if=/dev/hdb of=/dev/null bs=1k count=512k
524288+0 records in
524288+0 records out
0.540u 10.520s 0:32.85 33.6%    0+0k 0+0io 115pf+0w
[tim@asus tim]# echo "514288/32.85" | bc -q
15655

HPT366 ----------------------------
[tim@asus tim]# hdparm -iv /dev/hdf

/dev/hdf:
 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     = 2491/255/63, sectors = 40021632, start = 0

 Model=Maxtor 32049H2, FwRev=YAH814Y0, SerialNo=L21R7EKC
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
 BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
 CurCHS=65535/1/63, CurSects=4128705, LBA=yes, LBAsects=40021632
 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 

[tim@asus tim]# hdparm -tT /dev/hdf

/dev/hdf:
 Timing buffer-cache reads:   128 MB in  1.50 seconds = 85.33 MB/sec
 Timing buffered disk reads:  64 MB in  2.28 seconds = 28.07 MB/sec

[tim@asus tim]# time dd if=/dev/hdf of=/dev/null bs=1k count=512k
524288+0 records in
524288+0 records out
0.530u 11.140s 0:27.45 42.5%    0+0k 0+0io 115pf+0w
[tim@asus tim]# echo "524288/27.45" | bc -q
19099


--

Re: UDMA 100 / PIIX4 question

[quintaq]

On Wed, 21 Mar 2001 11:14:53 -0800
Tim Moore <timothymoore@bigfoot.com> wrote:

> Change partition type to 'c' (fat32+LBA); check that BIOS is set for
> (AUTO or USER) and LBA.
> 
Hi Tim,

I am afraid that I do not know how to change my partition type.  I can confirm. however, that the BIOS is set to Auto / LBA and that BIOS confirms UDMA 5 is set (and cannot be set unless the correct cabling is detected).

> 
> Regarding the PIIX4, I reran basic throughput read tests on a more
> recent UDMA5, 5400RPM Maxtor on the PIIX4 and HPT366 (Abit BP6 +
> 2.2.19p17 + ide.2.2.18.1221.patch) chipsets.

<snip>

But is my controller, though detected as a PIIX4 (and described as such in the Asus manual), really a PIIX4?  lspci :

00:00.0 Host bridge: Intel Corporation: Unknown device 1130 (rev 02)
00:01.0 PCI bridge: Intel Corporation: Unknown device 1131 (rev 02)
00:1e.0 PCI bridge: Intel Corporation: Unknown device 244e (rev 01)
00:1f.0 ISA bridge: Intel Corporation: Unknown device 2440 (rev 01)
00:1f.1 IDE interface: Intel Corporation: Unknown device 244b (rev 01)
00:1f.2 USB Controller: Intel Corporation: Unknown device 2442 (rev 01)
00:1f.3 SMBus: Intel Corporation: Unknown device 2443 (rev 01)
00:1f.4 USB Controller: Intel Corporation: Unknown device 2444 (rev 01)
01:00.0 VGA compatible controller: Matrox Graphics, Inc. MGA G400 AGP (rev 04)
02:0a.0 Ethernet controller: Winbond Electronics Corp W89C940
02:0c.0 Multimedia audio controller: Creative Labs SB Live! EMU10000 (rev 04)
02:0c.1 Input device controller: Creative Labs SB Live! (rev 01)
02:0d.0 Multimedia video controller: Brooktree Corporation Bt848 TV with DMA push (rev 12)
02:0e.0 SCSI storage controller: Adaptec AHA-7850 (rev 03)

On the other hand, cat /proc/ide/piix :

                               Intel PIIX4 Ultra 100 Chipset.
--------------- Primary Channel ---------------- Secondary Channel -------------
                 enabled                          enabled
--------------- drive0 --------- drive1 -------- drive0 ---------- drive1 ------
DMA enabled:    yes              no              yes               no 
UDMA enabled:   yes              no              yes               no 
UDMA enabled:   5                X               2                 X
UDMA
DMA
PI

Regards,

Geoff

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: UDMA 100 / PIIX4 question

[Tim Moore]

> I am afraid that I do not know how to change my partition type.  I can confirm. however, that the BIOS is set to Auto / LBA and that BIOS confirms UDMA 5 is set (and cannot be set unless the correct cabling is detected).

[tim@abit tim]# fdisk /dev/hdc

Command (m for help): t
Partition number (1-4): 1
Hex code (type L to list codes): c
Changed system type of partition 1 to c (Win95 FAT32 (LBA))
...

> But is my controller, though detected as a PIIX4 (and described as such in the Asus manual), really a PIIX4?  lspci :
> 
> 00:00.0 Host bridge: Intel Corporation: Unknown device 1130 (rev 02)
> 00:01.0 PCI bridge: Intel Corporation: Unknown device 1131 (rev 02)
> 00:1e.0 PCI bridge: Intel Corporation: Unknown device 244e (rev 01)
> 00:1f.0 ISA bridge: Intel Corporation: Unknown device 2440 (rev 01)
> 00:1f.1 IDE interface: Intel Corporation: Unknown device 244b (rev 01)
> 00:1f.2 USB Controller: Intel Corporation: Unknown device 2442 (rev 01)
> ...
> 
> On the other hand, cat /proc/ide/piix :
> 
>                                Intel PIIX4 Ultra 100 Chipset.
> --------------- Primary Channel ---------------- Secondary Channel -------------
>                  enabled                          enabled
> --------------- drive0 --------- drive1 -------- drive0 ---------- drive1 ------
> DMA enabled:    yes              no              yes               no
> UDMA enabled:   yes              no              yes               no
> UDMA enabled:   5                X               2                 X
> UDMA
> DMA
> PI

ICH2 is marked '80821BA' and is rated ATA/100 by intel, PIIX4 is '82371AB'
so you can look on your motherboard.  Andre is the one to say if the driver
is compatible.  I can't find a single reference to the 80821 in
drivers/block/*.c for 2.2.19pre17 + ide.2.2.18.1221.

Here's what a PIIX4 looks like.

[tim@smp ide]# cat /proc/ide/ide0/config
pci bus 00 device 39 vid 8086 did 7111 channel 0
86 80 11 71 05 00 80 02 01 80 01 01 00 20 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
01 f0 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
07 a3 00 80 00 00 00 00 01 00 02 00 00 00 00 00
...
00 00 00 00 00 00 00 00 30 0f 00 00 00 00 00 00

[tim@smp ide]# cat /proc/ide/piix

                                Intel PIIX4 Ultra 33 Chipset.
--------------- Primary Channel ---------------- Secondary Channel
-------------
                 enabled                          enabled
--------------- drive0 --------- drive1 -------- drive0 ---------- drive1
------
DMA enabled:    yes              no              no                no 
UDMA enabled:   yes              no              no                no 
UDMA enabled:   2                X               X                 X
UDMA
DMA
PIO

[tim@smp tim]# lspci | grep IDE
00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
[tim@smp tim]# lspci -n | grep 7.1
00:07.1 Class 0101: 8086:7111 (rev 01)

--

Re: UDMA 100 / PIIX4 question

[Holger Lubitz]

Jeremy Jackson wrote:

> Yes this is why I originally replied to the post... but he's not using a PIIXx at
> all,
> but the IDE chip on an Intel 815 motherboard.  I'm not sure if they use the same
> driver
> , but I don't think so.

I only know i810 systems from experience, but they use a 82801AA which
is still reported as PIIX4 in /proc/ide/piix (so probably is quite
similar, apart from supporting UDMA/66). I assumed that might be the
same for i815.

> > hdparm speed measurements differ by filesystem (i have no idea why,
> 
> this is false.  They may differ by partition, since different parts (zones) of a

i know. i found it hard to believe myself, but the numbers are
consistently lower even on the same partition. i used to have a spare
partition for things like this (hda6 below), unfortunately i cannot
repeat the tests right
now because it is currently in use.

but if it were a matter of different disk zones, only the buffered disk
reads should get slower, not the buffer-cache reads.

> include output of fdisk so we can see partition layout, and results of hdparm on
> different areas.

Disk /dev/hda: 255 heads, 63 sectors, 5606 cylinders
Units = cylinders of 16065 * 512 bytes

   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1       255   2048256    6  FAT16
/dev/hda2           256      5606  42981907+   5  Extended
/dev/hda5           256       511   2056288+  83  Linux
/dev/hda6           512       767   2056288+  83  Linux
/dev/hda7           768      1023   2056288+  83  Linux
/dev/hda8          1024      1089    530113+  82  Linux swap
/dev/hda9          1090      5606  36282771   83  Linux

/dev/hda:
 Timing buffer-cache reads:   128 MB in  1.41 seconds = 90.78 MB/sec
 Timing buffered disk reads:  64 MB in  3.04 seconds = 21.05 MB/sec

/dev/hda1:
 Timing buffer-cache reads:   128 MB in  1.66 seconds = 77.11 MB/sec
 Timing buffered disk reads:  64 MB in  3.51 seconds = 18.23 MB/sec

/dev/hda5:
 Timing buffer-cache reads:   128 MB in  1.20 seconds =106.67 MB/sec
 Timing buffered disk reads:  64 MB in  2.32 seconds = 27.59 MB/sec

/dev/hda6:
 Timing buffer-cache reads:   128 MB in  1.20 seconds =106.67 MB/sec
 Timing buffered disk reads:  64 MB in  2.37 seconds = 27.00 MB/sec

/dev/hda7:
 Timing buffer-cache reads:   128 MB in  1.20 seconds =106.67 MB/sec
 Timing buffered disk reads:  64 MB in  2.33 seconds = 27.47 MB/sec

/dev/hda8:
 Timing buffer-cache reads:   128 MB in  1.21 seconds =105.79 MB/sec
 Timing buffered disk reads:  64 MB in  2.31 seconds = 27.71 MB/sec

/dev/hda9:
 Timing buffer-cache reads:   128 MB in  1.21 seconds =105.79 MB/sec
 Timing buffered disk reads:  64 MB in  2.30 seconds = 27.83 MB/sec

the kernel is 2.4.2ac18 btw. i know its not the most recent, but that
shouldn't matter. this behaviour has been there for a long time. i am
not even sure if this was ever any different.

holger

Re: UDMA 100 / PIIX4 question

[Mark Hahn]

> > > I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), which has a PIIX4 controller.
> > > ...
> > > My problem is that (according to hdparm -t), I never get a better transfer rate than approximately 15.8 Mb/sec....
> >
> > 15MB/s for hdparm is about right.

it's definitely not right: this disk sustains around 35 MB/s.

> Yes, since hdparm -t measures *SUSTAINED* transfers... the actual "head rate" of data reads from
> disk surface.  Only if you read *only* data that is alread in harddrive's cache will you get a speed
> close to the UDMA mode of the drive/controller.  The cache is around 1Mbyte, so for a split-second
> re-read of some data....

nonsequitur: the controller and disk are both quite capable of 
sustaining 20-35 MB/s (depending on zone.)  here's hdparm output
for a disk of the same rpm and density as the DTLA's:

 Timing buffer-cache reads:   128 MB in  1.07 seconds =119.63 MB/sec
 Timing buffered disk reads:  64 MB in  2.02 seconds = 31.68 MB/sec

(maxtor dm+45, hpt366 controller)
regards, mark hahn.

Re: UDMA 100 / PIIX4 question

[Tim Moore]

Mark Hahn wrote:
> 
> > > > I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), which has a PIIX4 controller.
> > > > ...
> > > > My problem is that (according to hdparm -t), I never get a better transfer rate than approximately 15.8 Mb/sec....
> > >
> > > 15MB/s for hdparm is about right.
> 
> it's definitely not right: this disk sustains around 35 MB/s.

The 815e does not use a PIIX4 chipset.  My references were to PIIX4
chipsets.

> nonsequitur: the controller and disk are both quite capable of
> sustaining 20-35 MB/s (depending on zone.)  here's hdparm output
> for a disk of the same rpm and density as the DTLA's:
> 
>  Timing buffer-cache reads:   128 MB in  1.07 seconds =119.63 MB/sec
>  Timing buffered disk reads:  64 MB in  2.02 seconds = 31.68 MB/sec
> 
> (maxtor dm+45, hpt366 controller)
> regards, mark hahn.

Again, this is not a PIIX4 chipset.

rgds,
tim.
--

Re: UDMA 100 / PIIX4 question

[Jeremy Jackson]

Tim Moore wrote:

> quintaq@yahoo.co.uk wrote:
> > I have an IBM DTLA 307030 (ATA 100 / UDMA 5) on an 815e board (Asus CUSL2), which has a PIIX4 controller.
> > ...
> > My problem is that (according to hdparm -t), I never get a better transfer rate than approximately 15.8 Mb/sec.  I achieve this when DMA is enabled, - without it I fall back to about 5 Mb /sec.  No amount of fiddling with other hdparm settings makes any difference.
> > ...
>
> 15MB/s for hdparm is about right.

You should be able to get about 30 MB/s at the start of the disk (zone 0) according to IBM's datasheet at

http://ssdweb01.storage.ibm.com/techsup/hddtech/prodspec/dtla_spw.pdf

so if you were testing say /dev/hda1 which is at the start of the disk it should be faster.

Try hdparm -i /dev/hda (or whatever) .. . note the reported MaxMultSect= value,
and put it in place of X in command:

hdparm -u 1 -d 1 -m X -c 1 /dev/hda

Cheers,

Jeremy

PS - please let me know if this fixed your problem, since I have a system
with the same motherboard.

Re: UDMA 100 / PIIX4 question

[Tim Moore]

> You should be able to get about 30 MB/s at the start of the disk (zone 0) according to IBM's datasheet at
> 
> http://ssdweb01.storage.ibm.com/techsup/hddtech/prodspec/dtla_spw.pdf
> 
> so if you were testing say /dev/hda1 which is at the start of the disk it should be faster.

"should be" is yes and yes, but you will not see 30MB/s and there is no actual difference between
/dev/hda and /dev/had1.

> Try hdparm -i /dev/hda (or whatever) .. . note the reported MaxMultSect= value,
> and put it in place of X in command:
> 
> hdparm -u 1 -d 1 -m X -c 1 /dev/hda

I've spent more time with real world data transfer testing than god, both PIIX4-based motherboards
and network based (Network Appliance <-> linux).  The only hdparm parameter that makes any
measurable, significnat difference for most modern drive and chipset combinations is -d1 and the
correct UDMA mode.

Try partitioning your disk in 4 equal segments and run multiple tests in runlevel1 on /dev/hda[1-4]
for '/usr/bin/time hdparm -tT' plus permutations of -a[0248]c[013]m[024816]u[01],
and /usr/bin/time dd if=/dev/hda[1-4] of=/dev/null bs=1k count={32,64,128,256,512,1024}k.

rgds,
tim.
--