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
[email protected] 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
--
Tim Moore wrote:
> [email protected] 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 [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Tim Moore wrote:
> [email protected] 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.
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 | [email protected]
> > > 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.
> 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.
--
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.
--
On Mon, 19 Mar 2001 12:17:38 -0800
Tim Moore <[email protected]> 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
[email protected] wrote:
>
> On Mon, 19 Mar 2001 12:17:38 -0800
> Tim Moore <[email protected]> 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
Holger Lubitz wrote:
> [email protected] wrote:
> >
> > On Mon, 19 Mar 2001 12:17:38 -0800
> > Tim Moore <[email protected]> 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?
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
> 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.
On Tue, 20 Mar 2001 16:32:48 -0500 (EST)
Mark Hahn <[email protected]> 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
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
On Wed, 21 Mar 2001 09:56:56 +0000
[email protected] 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
[email protected] 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
> > 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
--
> 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.
--
Hello Geoff,
Thanks Mark for doing a great job while I was doing other stuff.
On Wed, 21 Mar 2001 [email protected] 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
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
On Wed, 21 Mar 2001 11:38:47 -0500
Mike Dresser <[email protected]> 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
On Wed, 21 Mar 2001 11:14:53 -0800
Tim Moore <[email protected]> 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
On Wed, 21 Mar 2001 11:29:00 -0800 (PST)
Andre Hedrick <[email protected]> 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
> 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)
--