Bug 242123 - hdparm -T 2 times slower on FC7/FC8 (compared to FC6)
Summary: hdparm -T 2 times slower on FC7/FC8 (compared to FC6)
Alias: None
Product: Fedora
Classification: Fedora
Component: hdparm
Version: 8
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeff Garzik
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2007-06-01 20:23 UTC by Doncho Gunchev
Modified: 2013-07-03 02:33 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2009-01-09 04:37:25 UTC

Attachments (Terms of Use)
lspci, dmesg... from my laptop (16.31 KB, application/octet-stream)
2007-06-01 20:23 UTC, Doncho Gunchev
no flags Details
dmesg (24.20 KB, text/plain)
2007-06-01 21:13 UTC, Ronald Warsow
no flags Details
lspci (2.31 KB, text/plain)
2007-06-01 21:15 UTC, Ronald Warsow
no flags Details
lspci output (14.78 KB, text/plain)
2007-11-25 20:13 UTC, Brian Rademacher
no flags Details

Description Doncho Gunchev 2007-06-01 20:23:56 UTC
Description of problem:
hdparm -T is 2 times slower on F7 (compared to FC6) on Acer Aspire 5610. I
observe this from F7t3 or F7t4 at least.

Version-Release number of selected component (if applicable):
any kernel up to 2.6.21-1.3209.fc7

How reproducible:

Steps to Reproduce:
1. install FC6
2. install F7 or get a live CD/DVD
3. try 'hdparm -T /dev/your_hard_disk'
Actual results:

=== FC6 ===
 Timing cached reads:   4504 MB in  2.00 seconds = 2252.79 MB/sec
 Timing buffered disk reads:  100 MB in  3.00 seconds =  33.33 MB/sec

=== FC7 ===
 Timing cached reads:   2376 MB in  2.00 seconds = 1188.60 MB/sec
 Timing buffered disk reads:  102 MB in  3.03 seconds =  33.64 MB/sec
 Timing cached reads:   1814 MB in  2.00 seconds = 908.37 MB/sec
 Timing buffered disk reads:  102 MB in  3.06 seconds =  33.34 MB/sec
 Timing cached reads:   1806 MB in  2.00 seconds = 903.80 MB/sec
 Timing buffered disk reads:  102 MB in  3.03 seconds =  33.66 MB/sec

Expected results:
Should have cached disk transfers faster in F7 than in FC6 or at least as fast
as before /"We feel the need, the need for speed", right? ;-)/.

Additional info:
  hw profile: e121f58f-2418-479e-9683-defc088c2168
  All tests were done in init level 1 (single user)
  I'll attach a tarball with lspci and dmesg as asked from Dave Jones plus
hdparm, lsmod and /proc/cpuinfo. '.fc6' files are from Fedora Core 6 and .f7 are
from Fedora 7.

Comment 1 Doncho Gunchev 2007-06-01 20:23:56 UTC
Created attachment 155934 [details]
lspci, dmesg... from my laptop

Comment 2 Ronald Warsow 2007-06-01 21:07:24 UTC
same for me:

under F7:
 Timing cached reads:   1254 MB in  2.00 seconds = 627.26 MB/sec
 Timing buffered disk reads:  236 MB in  3.03 seconds =  77.98 MB/sec

 Timing cached reads:   1668 MB in  2.00 seconds = 833.99 MB/sec
 Timing buffered disk reads:  174 MB in  3.00 seconds =  57.97 MB/sec

under FC6:
 Timing cached reads:   2548 MB in  2.00 seconds = 1273.86 MB/sec
 Timing buffered disk reads:  234 MB in  3.02 seconds =  77.52 MB/sec

 Timing cached reads:   2080 MB in  2.00 seconds = 1039.47 MB/sec
 Timing buffered disk reads:  174 MB in  3.00 seconds =  57.95 MB/sec


Comment 3 Ronald Warsow 2007-06-01 21:13:25 UTC
Created attachment 155939 [details]

Comment 4 Ronald Warsow 2007-06-01 21:15:56 UTC
Created attachment 155940 [details]

Comment 5 Doncho Gunchev 2007-06-06 21:09:15 UTC
Why 'SATA_NV'? I have Intel notebook, no SATA nor nvidia chips inside!!!

00:1f.1 IDE interface: Intel Corporation 82801G (ICH7 Family) IDE Controller 
(rev 02)

PS: the hw uuid I typed first is maybe the one I got from the LiveCD. The real 
one is 

Comment 6 Doncho Gunchev 2007-07-19 07:54:24 UTC
Still the same results with kernel-2.6.23-0.30.rc0.git6.fc8 :(

Comment 7 Doncho Gunchev 2007-08-05 20:11:55 UTC
I compiled 2.6.23-rc2 myself (with .config based on FC7's kernels) and old IDE 
support (/dev/hda, not /dev/sda) and hdparm still shows the same 2 times lower 

Comment 8 Piergiorgio Sartor 2007-08-09 12:54:49 UTC
I noticed the same on two completely different machines, one is a nVidia based
(sata_nv), the other is an intel one (ata_piix).
In both cases the cached read test (-T) takes twice the time (half speed)
compared to the old FC6 situation.
Note that the the disk read (-t) is still the same for F7 and FC7.
This might lead to suspect some "redundant" memcpy within the new libata layer
(common to the above machines).
I guess the disk read (-t) would be more critical, if slower.

In any case, it not nice this set back of performances.

Comment 9 Piergiorgio Sartor 2007-08-09 12:56:30 UTC
(In reply to comment #8)
> In both cases the cached read test (-T) takes twice the time (half speed)
> compared to the old FC6 situation.

Actually, it takes the same time, it just transfer half the data...

Comment 10 Piergiorgio Sartor 2007-08-10 07:52:43 UTC
I just updated the kernel of a FC6 machine to, more or less in line
with the one in F7.
The tests are identical (maybe even a bit better) to ones with the old kernel,
So, either there is different patch between the FC6 and F7 kernel or the problem
is somewhere else, eventually in hdparm itself... This one is 6.9-3 in F7 and
6.6-2 in FC6...
And in fact, installing the FC6 one in a F7 machine gives the old (good) results...

Comment 11 Doncho Gunchev 2007-08-10 12:26:58 UTC
Thank you Piergiorgio Sartor, I can confirm this:

[root@mr700 ~]# uname -r

[root@mr700 ~]# hdparm -T /dev/sda

 Timing cached reads:   2206 MB in  2.00 seconds = 1103.90 MB/sec
[root@mr700 ~]# /mnt/old/sbin/hdparm -T /dev/sda

 Timing cached reads:   4388 MB in  2.00 seconds = 2197.15 MB/sec

So it's hdparm's problem after all! If someone is having this problem even 
with hdparm from FC6 please reassign to kernel (or should we clone it?).

Comment 12 Doncho Gunchev 2007-11-10 16:07:11 UTC
Removing SATA_NV from the title because it's misleading - I have no sata nor 
nvidia components and it is hdparm version specific problem (in fc8 too, see 
Comment #10).

Comment 13 Brian Rademacher 2007-11-25 20:13:20 UTC
Created attachment 268321 [details]
lspci output

Comment 14 Brian Rademacher 2007-11-25 20:15:53 UTC
Comment on attachment 268321 [details]
lspci output

You can add me to this list, using F8 Kernel and sata_mv (NOT
nv).  My buffered disk reads are the same as FC6, but cached speeds have been
cut in half (around 2000MB/sec in FC6, now 1000 or less).  I even tried
kernel-2.6.24-0.42.rc3.git1.fc9.x86_64 just for fun, and same results.

Comment 15 Brian Rademacher 2007-11-25 20:22:12 UTC
Comment on attachment 268321 [details]
lspci output

I can also confirm that installing an FC6 version of hdparm creates similar
results, so this must be hdparm related...

Comment 16 Doncho Gunchev 2008-03-05 00:56:49 UTC
Comment on attachment 155934 [details]
lspci, dmesg... from my laptop

lspci and dmesg have nothing to do with the problem.

Comment 17 Bug Zapper 2008-11-26 07:16:26 UTC
This message is a reminder that Fedora 8 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 8.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '8'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 8's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 8 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 

Comment 18 Bug Zapper 2009-01-09 04:37:25 UTC
Fedora 8 changed to end-of-life (EOL) status on 2009-01-07. Fedora 8 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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