Bug 81889 - harddisk transfer speed varies alot
Summary: harddisk transfer speed varies alot
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 8.0
Hardware: athlon
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2003-01-14 22:26 UTC by Steffan Olesen
Modified: 2007-04-18 16:49 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2003-06-05 14:16:43 UTC

Attachments (Terms of Use)

Description Steffan Olesen 2003-01-14 22:26:56 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830

Description of problem:
The speed of my harddisk varies alot. I have tuned the disk (in
In the test I did file1 is 232Mb and file2 is 216Mb.
When I do "cat file1 > /dev/null" it takes 6.6 seconds with CPU utilisation 17%
When I do "cat file2 > /dev/null" it takes 30.6 seconds with CPU utilisation 3%
I get the same result every time. It is always file2 thats slow. It's the same
with other files. Reading some are very fast, and other very slow.
The two files is on the same partition.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
See description.    

Additional info:

The harddisk is an seagate model ST380021A (80Gb) and the motherboard a Soltek
SL-75KAV (Via Apollo KT133A Series). CPU: Duron

Kernel: 2.4.18-19.8.0 on RH 8.0

The output from:

hdparm -i /dev/hda
 Model=ST380021A, FwRev=3.75, SerialNo=3HV3DFQ6
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=2048kB, MaxMultSect=16, MultSect=16
 CurCHS=4047/16/255, CurSects=16511760, LBA=yes, LBAsects=156301488
 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
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: device does not report version:  1 2 3 4 5

hdparm /dev/hda
 multcount    = 16 (on)
 IO_support   =  3 (32-bit w/sync)
 unmaskirq    =  1 (on)
 using_dma    =  1 (on)
 keepsettings =  0 (off)
 readonly     =  0 (off)
 readahead    =  8 (on)
 geometry     = 155061/16/63, sectors = 156301488, start = 0

hdparm -tT /dev/hda
 Timing buffer-cache reads:   128 MB in  0.77 seconds =165.92 MB/sec
 Timing buffered disk reads:  64 MB in  1.59 seconds = 40.35 MB/sec

Comment 1 Michael Lee Yohe 2003-01-15 17:27:19 UTC
There could be various factors that result in your findings.  A better method in
comparing the two processes is prepending "time" to your commands.  Time shows
the resource usage consumed by the command during the period of time it was
running.  For example,

$ ls -laF /usr/download/isos/phoebe/
total 1918092
drwxr-xr-x    2 myohe    myohe        4096 Dec 27 10:03 ./
drwxr-xr-x    4 myohe    myohe        4096 Jan  3 10:52 ../
-rw-r--r--    1 myohe    myohe         339 Dec 20 18:54 MD5SUMS
-rw-r--r--    1 myohe    myohe    652115968 Dec 20 18:31 phoebe-i386-disc1.iso
-rw-r--r--    1 myohe    myohe    673218560 Dec 20 18:35 phoebe-i386-disc2.iso
-rw-r--r--    1 myohe    myohe    636846080 Dec 20 18:39 phoebe-i386-disc3.iso

$ time cat /usr/download/isos/phoebe/phoebe-i386-disc1.iso > /dev/null

real	0m24.048s
user	0m0.125s
sys	0m1.051s

$ time cat /usr/download/isos/phoebe/phoebe-i386-disc2.iso > /dev/null

real	0m25.023s
user	0m0.121s
sys	0m1.156s

From this data: My throughput (bytes per second) for disc 1 was ( 652115968 /
24.048 ), which equals 25.861MB/s.  My throughput for disc 2 was ( 673218560 /
25.023 ), which equals 25.658MB/s.

The difference is negligible, largely because this machine does virtually
nothing except provide a display for me to type this comment to this bug on. 
Time tells you "real" (meaning how much time has passed), "user" (meaning how
much time on the CPU your command took to process), and "sys" (meaning how much
overhead was incurred on the CPU for the command - examples of overhead usually
mean I/O and wait-states).

The CPU utilization you see in top (or another monitoring application) is really
an approximation at the time the listing was refreshed.  "time" gives you more
accurate results.  So, if for the first file that you run incurs little "sys"
time, but the second file incurs a much higher "sys" time - then there is more
I/O overhead attempting to read the file from disk _or_ (less likely) more
overhead incurred by the kernel in receiving data from the /dev/null device.

Finally, you should check your kernel messages to make sure nothing is being
reported by the EIDE driver.  To see these messages, type "dmesg" after you get
finished running these simple benchmarks.  If you see messages with regards to
your hard drive device, you should investigate further.

Comment 2 Alan Cox 2003-06-05 14:16:43 UTC
There are a zillion possible reasons for this - disk performance varies by
location, also bad blocks will cause extra seeks for the remappings

Note You need to log in before you can comment on or make changes to this bug.