I WROTE THE Western Digital Data Lifeguard Utilities to a floppy disk:
tested my WD400BB-32CXA0 No errors.
Changed with the Ultra Management utility the UDMA setting on the
disk itself from UDMA5 (100) TO UDMA2 (33):
ML9.0 and ML8.2 report in dmesg: UDMA(33)
Win XP reports also UDMA2.
I tested in ML8.2:
hdparm /dev/hda: using_dma=1(on)
hdparm -Tt /dev/hda: 27,23 MB/s
hdparm -I /dev/hda: DMA ... *udma2
cycle time: min=120ns recommended=120ns
Changed back from UDMA2 (33) to UDMA5 (100)
Now I got these results:
hdparm -Tt /dev/hda: 27 MB/s
HUH? SAME AS UDMA2 ??
hdparm -I /dev/hda: DMA ... *udma5
cycle time: min=120ns recommended=120ns
HUH? 120ns??????????????????
SEE http://www.pcguide.com/ref/hdd/if/ide/modes.htm UDMA:
"
This table shows all of the current Ultra DMA modes, along with
their cycle times and maximum transfer rates:
Ultra DMA Cycle Time Maximum Transfer
Mode (nanoseconds) Rate (MB/s)
Mode 0 240 16.7
Mode 1 160 25.0
Mode 2 120 33.3
Mode 3 90 44.4
Mode 4 60 66.7
Mode 5 40 100.0
The cycle time shows the speed of the interface clock; the clock's
frequency is the reciprocal of this number (see here for more on
clocking.) The maximum transfer rate is four times the reciprocal of
the cycle time--double transition clocking means each cycle has two
transfers, and each transfer moves two bytes (16 bits). "
UDMA5 should have cycle time: 40ns
Why does hdparm -I /dev/hda report
"cycle time: min=120ns recommended=120ns" ?
Is this a bug of hdparm?
Or does the cycle time in hdparm means something else?
Or could it be that the UDMA5 of my hard drive gives the same speed as
UDMA2?
Then I found on viaarena.com this patch for ML8.2:
VIA ML8.2 ATA133-100 Patch 686B-8231-8233x-8235 ver 0.91A.gz
contains a patch file mdk8.2-patch-2.4.18-vpide.gz date: 20/9/02
and a readme.pdf:
VIA ML8.2 ATA133-100 Patch Readme.pdf:
"hdparm -t /dev/hda: sustained transfer rate of the disk reads:
VT8233 Original Kernel 23,7 MB/sec
rebuilt kernel with 39,75 MB/sec
Patch IDE
Success of kernel patching: dmesg:
"VP_IDE: VIA vt8233 (rev 00) IDE UDMA100 controller on pci00:11.1
Note the data transfer for VT8233 has changed from 33 to 100"
HUH???? MY dmesg already states UDMA100 but
hdparm -t /dev/hda on my ML8.2 is only 26,67 MB/sec !!!!!!!!
Hm, I remember that my ML8.2 has no original kernel, I installed a new
one from cooker during the summer.
So either my kernel is already patched and for some other reason only
manages 26,67 MB/sec for sustained transfer rate or it isn't patched
yet and incorrectly states that I have a UDMA100 driver.
hdparm on my ML9.0 shows the same speeds. Does ML9.0 has this patch from
VIA already included?
How in Linux can I test the burst speed which should come close to
the UDMA speed: 100 MB/sec (in article below: +/- 87 MB/sec) ?
In this article they tested speeds in Windows
"http://www.tecchannel.de/hardware/817/index.html: Client / Komponenten
/ VIA Chipsets slow down PCI cards: Vom 21.12.2001, Update am 04.02.2002
VIA Chipsets slow down PCI cards: a driver patch is available to boost
burst speed closer to 100 MB/sec
...
The speed while doing sequential transfers from the hard drive media
itself is actually much lower than that. High end IDE drives max out at
about 40 MBytes/s currently. >>>>AHA BUT I ONLY GET
>>>> 26,67 MB/sec
If you consider the overhead, these drives
can only push older Ultra-ATA/66-controllers to their limits."
What is a normal sustained transfer rate for UDMA5 in Linux ( what does
"hdparm -t /dev/hda" return on your computer)?
How in Win XP can I test the sustained transfer rate like in Linux with
the command "hdparm -t /dev/hda" ? Would it be the same speed as in
Linux ?
vatbier
Want to buy your Pack or Services from MandrakeSoft?
Go to http://www.mandrakestore.com