Slow SATA performance

Bug #119730 reported by Dan Walker
212
This bug affects 22 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Invalid
Medium
Unassigned

Bug Description

Hi

This issue has been discussed over at http://ubuntuforums.org/showthread.php?t=447474, and seems to affect a number of us.

File copy speed is very slow (roughly 5-10MBps) on SATA hard drives. Copying within the same physical drive is just as slow as copying to another physical drive. The issue occurs with GUI tools (Nautilus, Krusader) as well as at the terminal using the CP command. This has occured since upgrading to Feisty; Edgy was fine.

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote : Re: Slow SATA HDD performance on Intel 82801G (ICH7 Family) chipset

Thank you for your bug report.

Dan:
Can you check to see whether you are running by posting the output of
uname -a
dmesg | head
?

Revision history for this message
Dan Walker (dwalker109) wrote :

Here's the output of uname -a:
Linux Panoramix 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

The output of dmesg | head is attached to this post.

Thanks!

Revision history for this message
Dan Walker (dwalker109) wrote :

This doesn't seem to be limited to Intel chipsets - it also seems to affect nForce based systems, as per the discussion at the previously quoted thread.

Revision history for this message
montag (montag-fire) wrote : Re: Slow SATA HDD performance on Intel 82801G (ICH7 Family) & nForce chipsets

Same problem here, but my motherbord is ALi based.

My Sata controller (lspci)
SATA controller: ALi Corporation ULi M5288 SATA

uname -a:
Linux kubuvic 2.6.20-16-generic #2 SMP Thu Jun 7 20:19:32 UTC 2007 i686 GNU/Linux

Many people on the forum are experiencing slow sata...

An other problem with mi Sata disk (I don't know if it's related to this one or not):
sudo smartctl -i /dev/sda
smartctl version 5.36 [i686-pc-linux-gnu] Copyright (C) 2002-6 Bruce Allen
Home page is http://smartmontools.sourceforge.net/

Device: ATA ST3320620AS Version: 3.AA
Serial number: 3QF0M1ZP
Device type: disk
Local Time is: Sun Jun 24 20:28:22 2007 CEST
Device does not support SMART

And it sounds strange...

Revision history for this message
Dan Walker (dwalker109) wrote :

Users of Intel, nForce, ALi, ATI and Silicon Image SATA controllers have all reported this issue - it does not seem limited to any one manufacturer.

description: updated
description: updated
description: updated
Revision history for this message
joyolee (joyolee15) wrote :

some problem~~~~
any solutions?

Revision history for this message
Sitsofe Wheeler (sitsofe) wrote :

Dan:
Do you know if the problem has persisted into Gutsy (is it possible to test a LiveCD)?

Revision history for this message
Dan Walker (dwalker109) wrote :

I have heard anecdotal evidence that this is resolved in Gutsy. I will try and give it a test and report back.

Revision history for this message
Reptile (adam-reptilianshapeshifter) wrote :

This seemed to be resolved in Tribe 3 beta at least (cant remember the kernel version) but since the last few kernel updates I am back to the old transfer speeds again so I am going to find the old kernel that worked and test it. I am very disappointed that this appeared to be fixed and now it is a problem again.

Using Tribe 3 is getting up to 50mb/s (it took less than 15 seconds to transfer a 700mb file from one physical disk to another) and now it is taking 2 minutes to transfer!

I have an AG8 motherboard for Pentium 4 and the chipset is an intel ICH6-R 915P.

Revision history for this message
Reptile (adam-reptilianshapeshifter) wrote :

Ok this gets weirder. I installed the Gutsy RC from scratch and now file transfers are back to normal. What the hell could it be?

Revision history for this message
lefty.crupps (eljefedelito) wrote :

I am not sure if it is related or not, but my SATA2 DVD-r drive jumps around in speed but settles on burning at 4x after about 30-50% od a DVD, and then stays at that 4x for the remainder of the burning time. The DVD-R drive itself is *supposed* to burn at 18x...

Let me know if I can provide more info, or if I am on the wrong bug report...

Revision history for this message
lefty.crupps (eljefedelito) wrote :

sorry, that is with a fresh install of Gutsy final.

Revision history for this message
mrmiranda (marcio-inf) wrote :

I have same problem (slow transfers). I installed the gutsy RC and and the transfer continue slow.

I have an Laptop v6000 series compaq, semprom 3500+ and the chipset is an nvidia.

Any solutions?

Revision history for this message
Dan Walker (dwalker109) wrote :

Having upgraded to Gutsy, transfer speed is a lot faster for me, but I'm not certain the issue is fully resolved yet - I got between 20 and 40 MBps when copying this evening, so I will test further and report back. It is a definite improvement though, no question.

Revision history for this message
Fungyo (sites07) wrote :

Clean install of Gutsy final. copy a 350mb avi file at times is slow but can also start transferring at 120+mbs, then within seconds it drops to around 50mbs which by this time it has finished copying. I have noted it going as slow as 14mbs from 122mbs.
Transferring a large avi file of 900mb always starts at about 11mbs, drops as low as 6mbs but increases to 20mbs as the copying nears 100% complete.

copying from an ext usb hdd stays at about 25mbs from start to finish, i believe this would be about max due to the usb limited bandwidth.

> sudo hdparm -tT /dev/sda
Timing cached reads: 856 MB in 2.00 seconds = 427.16 MB/sec
Timing buffered disk reads: 190 MB in 3.00 seconds = 63.25 MB/sec

wd 320gb 7200 16mb

asus p5p800-mx
865G PE/P
ICH5/ICH5R

Revision history for this message
pinepain (pinepain) wrote :
Download full text (3.3 KiB)

Hi. i have or actually had the same problem, average speed from IDE to SATA was 5mbps. Then i tries to tune with hdparm and sdparm - nothing. But i noticed that I coudn't set to use UDMA mode (yeah, hdd support it), so i tried to set it in BIOS. BIOS saz that all settings is auto and it use the fastest mode, udma5 on segate(5yrs old) an udma6 on hitachi (a few month ago). But after switchin from auto to udma5 and udma6 i get min 20mbps from ide to sata =) Dunno why, but it helps. Actually I have average speed from ide to sata ~30mbps, but I just mv 2gb, I should make some serius tests in it... later =) BTW, self-copy, move from one partition to another (on sata hdd) goes with the similar speed.

Yeah, one more thing, speed is very various, starts from 60-80 and goes down to 50 - 40 still there and goes ~17-25. Dunno why. Maybe my IDE is to slow for SATA.

Here is some data about my
#sda = IDE, sdb-sata.
#motherboard ASROCK P4DUAL 915GL (nop, it is old 1-cpu mb =)), 1024 + 256 DDR1(tuned to 2.5-3-3-4, IIRC=)),

#CELERON D 2.4 (works on 2.7, I've overclock bus from 133 to 150)

root@lhome:~# lspci |grep IDE
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 05)
00:1f.2 IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA Controller (rev 05)

root@lhome:~# uname -a
Linux lhome 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux

root@lhome:~# hdparm -i /dev/sda

/dev/sda:

 Model=ST340810A , FwRev=3.99 , SerialNo=5FBBPX4Y
 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=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=78165360
 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 udma3 udma4 *udma5
 AdvancedPM=yes: unknown setting WriteCache=enabled
 Drive conforms to: Unspecified: ATA/ATAPI-1 ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6

 * signifies the current active mode

root@lhome:~# hdparm -i /dev/sdb

/dev/sdb:

 Model=Hitachi HDT725050VLA360 , FwRev=V56OA7EA, SerialNo= VFK401R41K57XK
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=52
 BuffType=DualPortCache, BuffSize=15315kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
 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
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
 AdvancedPM=yes: disabled (255) WriteCache=enabled
 Drive conforms to: ATA/ATAPI-7 T13 1532D revision 1: ATA/ATAPI-2 ATA/ATAPI-3 ATA/ATAPI-4 ATA/ATAPI-5 ATA/ATAPI-6 ATA/ATAPI-7

 * signifies the current active mode

root@lhome:~# hdparm -tT /dev/sda

/dev/sda: #yeah. it really slow
 Timing cached reads: 1624 MB in 2.00 seconds = 811.40 MB/sec
 Timing buffered disk reads: 82 MB in 3.06 seconds = 26.79 M...

Read more...

Revision history for this message
Fungyo (sites07) wrote :

gave pinepain suggestions a try and set dma settings manually in bios. I have increased speed from 3 mb/s to 20-25mb/s. still not optimal but an improvement.

Revision history for this message
Alexey Borzenkov (snaury) wrote :

I've just measured my drive reading time and found out that it's 3.5-4.9MB/s (measured in Midnight Commander by copying a not yet cached file to /dev/null). Then I plugged a USB drive (an HDD box) and tried checking, it's 15-20MB/s, this isn't funny! I have ASUS F3Jp laptop (I have no settings in my BIOS) and now I see this was the reason of of bug #126274 and bug #131094 at least in my case.

dragonfox@kitsuden:~$ sudo hdparm -i /dev/sda

/dev/sda:

 Model=Hitachi HTS541612J9SA00 , FwRev=SBDOC70P, SerialNo= SB3D00E5G0D07A
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=DualPortCache, BuffSize=7516kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=234441648
 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
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
 AdvancedPM=yes: mode=0x80 (128) WriteCache=enabled
 Drive conforms to: ATA/ATAPI-7 T13 1532D revision 1: ATA/ATAPI-2,3,4,5,6,7

 * signifies the current active mode

I don't understand this, since I see udma5 marked as active in hdparm's output. (?)

Revision history for this message
Alexey Borzenkov (snaury) wrote :

Update. I've just tried copying files from my ntfs-3g partition and got 35MB/s. Then I started trying other files on my ext3 partition and found that some big files actually get read at 15-20MB/s. Most of big files are 5MB/s though. Seems like very heavy fragmentation. :(

Revision history for this message
pinepain (pinepain) wrote :

rtfm. copying a lot of small files takes more time than copying large with the same size. ntfs? its a stone age, use ext or raiser. also notice that copyng to /dev/null is different than copying to hdd or other media. btw, it's very interesting you don't have hdd options in bios. do u have the latest BIOS version? if no try to update it.

oh, one more fun thing. IIRC, there are pure SATA and emulation SATA via IDE on old MB =). also there are primary and secondary SATA connectors, try both of them, it may helps, i hope,

ps: maybe there are some jumpers to set io mode or sata1-sata2 ? but i'm not pro in such thing as hdd so it just IMHO

Revision history for this message
lefty.crupps (eljefedelito) wrote : Re: [Bug 119730] Re: Slow SATA performance

I could be wrong on this, but I thought the point (or, a part of it at
least) of DMA was to bypass the CPU when moving files; last night I copied
200GB of files and it totally ate the CPU during the processes. ext3 to
ext3, both SATA (from SATA2 to SATA1)...

Revision history for this message
pinepain (pinepain) wrote :

yupp, dma mustn't make heavy cpu load, for sure, but r u sure your hdd
use dma?

Revision history for this message
Alexey Borzenkov (snaury) wrote :

Pinepain, it's very kind of you to rtfm me without actually reading my comment, thank you very much. First of all there were no 'a lot of small files' not in any single of my tests. I always used large files, 250-350MB in size. And ntfs is not stone age, it is currently used by my windows partition, and the big file for testing was pagefile.sys (surprising, no? it's also not heavily fragment there). Also never in my tests I actually used to copy to hdd, because then it would be read+write speed (minus a delta because some data would stay in cache), writing data to /dev/null can have a small delta (dependent on buffer size though), but still, difference between 5MB/s and 20MB/s [on the same system with different files, one was downloaded with ktorrent (heavily fragmented and slow), another downloaded with wget (shows excellent throughput, supposedly it's not fragmented)] is not imaginary, don't you think? And I doubt I have a spare connector in my laptop's hard drive bay.

My experience with gutsy (after dist-upgrading from feisty) was extremely crawling and painful under even slightest disk load for past two months (and not just mine I assume, reading relevant bug reports), heavy fragmentation can also explain why people stop experiencing performance problems after they do clean reinstall.

P.S. Yes, I upgraded my bios and found that I do have those options in there, but I don't know if that would help at all, because I wiped my ubuntu installation, sorry. But seeing hdparm -i that I attached above I doubt it, because it shows udma5 is already currently selected mode.

Revision history for this message
pinepain (pinepain) wrote :

=) yeah, rtfm i thought u have not read man hdparm (sdparm), sry. about file size it was just in case, you know it's better to say it one more time than somebody will try to get 50mbps with 4gb of 4kb pics =)

ntfs in gnu is stone age. its a proprietary standard ant its support is limited so it's better to test your speed on full supported fs.

yeah, u r right with delay while copying to native hdd partition, but i think with copying to /dev/null you'll not get right results =) try to bkup / to /dev/null =) yeah, it takes more than io operations =)

5 and 20?? man, i have here 5 and 60 !!! it starts with 60 than drop down than up to 27-32 and stay there, but the average is ~27
i think hdd caching makes such differences. anyway, only hdparm -tT give you real result. other vudu is still vudu, nothing more.
experience of GNU/Linux saz that you _must_ experiment! who saz "heavy fragmentation"? there is fsck =) it will helps you to prevent fragmentation, i hope =)

about bios, i dunno, but it helps me (and Fungyo, thx for feedback) and i write here to help other ppl. btw, my hdd sad he use udma6 but speed was under 5 mbps before tune hdd mode in bios from auto to udma6. but u can try and see results.

truly you, pinepain

Revision history for this message
pinepain (pinepain) wrote :

[sorry] yeah, i was totally wrong. copying to /dev/null is much faster than to fs. dunno why did i sad that sh*t =).

i just tried to switch my hdd from primary sata connector to secondary and it is a little slower than on primary. so read your MB manual to know where is primary sata connector and where is secondary =). sorry one more time for /dev/null

Revision history for this message
NiklasW (falken) wrote :

I think my drives also act very slow. I do not know what preformance I could expect, here is some infor:

SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA

sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads: 1746 MB in 2.00 seconds = 873.15 MB/sec
 Timing buffered disk reads: 232 MB in 3.03 seconds = 76.61 MB/sec
nwaren@amanda:~$ sudo hdparm -tT /dev/sdb

/dev/sdb:
 Timing cached reads: 1248 MB in 2.00 seconds = 624.23 MB/sec
 Timing buffered disk reads: 162 MB in 3.03 seconds = 53.55 MB/sec

uname -r
2.6.22-14-generic

Processor: AMD X2 +4400
Moderboard: MSI K9AG NEO-F, AMD 690V+SB600, ATX, Socket-AM2, DDR2, GbLAN, VGA

Revision history for this message
NiklasW (falken) wrote :

My drives:

/dev/sda:

 Model=SAMSUNG HD501LJ , FwRev=CR100-10, SerialNo=XXXXXXXXXXXXXX
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
 BuffType=DualPortCache, BuffSize=16384kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
 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
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: unknown: ATA/ATAPI-3,4,5,6,7

 * signifies the current active mode

/dev/sdb:

 Model=ST3160812AS , FwRev=3.AAE , SerialNo= XXXXXXXXX
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
 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: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode

Revision history for this message
Dan Walker (dwalker109) wrote :

Just checking in the keep the thread "alive" - problem still exists for me in Gutsy. I average 5 - 10MBps during file copies.

Revision history for this message
pinepain (pinepain) wrote :

Hi,

Maybe the problem is in motherboard (chipset, etc.)? I've notice that
ASUS motherboards (as well as it subsidiary, ASRock) doesn't work
clearly under linux (problems with ACPI, slow hdd performance). So I
think it would be nice to get statistic on MB models (also notice BIOS
version) and vendors we got problem with.

Revision history for this message
slinger (slinger-to) wrote :

Same Problem here on Gutsy 2.6.22-14-generic.

Got a Thinkpad X60 with:

PCI bridge : Intel Corporation 82801 Mobile PCI Bridge
ISA bridge : Intel Corporation 82801GBM
IDE interface : Intel Corporation 82801G
SATA controller : Intel Corporation 82801GBM/GHM
SMBus : Intel Corporation 82801G

Slow performance with SATA HDD, i am just getting 34,04MB/sec and copying a 700MB file on same HDD takes just 5 MINUTES...no background tasks that can slower performance.

Tried Hardy Alpha 6 Live CD - same poor performance here. Why isn't there a fix since one year?

Revision history for this message
Pelle van der Scheer (pellesimon) wrote :

Same problem here on Hardy 2.6.24-12-generic,

Speeds vary between 5-10MB/s on a sata hard drive and Asus A8N-E motherboard copying large files (700mb) with nautilus

Speed reported by hdparm:

/dev/sda:
 Timing cached reads: 1418 MB in 2.00 seconds = 708.60 MB/sec
 Timing buffered disk reads: 204 MB in 3.02 seconds = 67.56 MB/sec

Revision history for this message
pltxtra (pltxtra) wrote :

I have the same problems, but I have two machines, both running 7.10, the first is AMD the other is Intel.

The problem for me seems to be the hard-drive itself. I have three SAMSUNG HD161HJ disks and one Maxtor.
No UDMA mode is enabled for any of the samsung disks, independently of which machine it is connected to.
The AMD has a VIA-SATA RAID controller, the Intel board has a controller from Intel.

The Maxtor disk has UDMA 5 enabled.

Conclusion: The differences on the disks have impact.

I also have a question: can it be that the samsung disks themselves do not support any UDMA/DMA mode?

Revision history for this message
Dan Walker (dwalker109) wrote :

Since my last comment, I have done some more testing. While performance is generally much better than it was a year ago, it still isn't quite as fast as it should be on two of my drives, and these drives don't appear to be running in any UDMA mode. The other one seems to perform a bit better, and has udma5 enabled. Here's the relevant output of hdparm -i and hdparm -tT on each of my three drives (the full output is attached):

# Maxtor 80GB SATA
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
 Timing buffered disk reads: 170 MB in 3.01 seconds = 56.39 MB/sec

# Seagate 80GB SATA
 UDMA modes: udma0 udma1 udma2 udma3 udma4 *udma5
 Timing buffered disk reads: 224 MB in 3.01 seconds = 74.42 MB/sec

# Western Digital 500GB SATA
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
 Timing buffered disk reads: 206 MB in 3.02 seconds = 68.15 MB/sec

Copying a 700MB ISO image between each of these drives takes between 11 and 20 seconds, with the mean average being about 15 seconds; the faster the transfer, the higher the CPU usage (up to 30% in some cases, much higher than I would expect considering DMA is supposed to be in use). I have attached details of this test as well (9 copy operations in all), in case this is of any use.

Of course, I don't really know what speeds I'm supposed to get on these drives - I have never paid much attention to copy speed until this problem occured. It's possible that these speeds are normal (they're certainly quick enough that this isn't as big an issue as it was), though the fact that UDMA still seems to be disabled on two drives makes me think something is still not working as it should.

Revision history for this message
Dan Walker (dwalker109) wrote :
Revision history for this message
joosters (x-launchpad-slimyhorror-com) wrote :

I hit (what I think was) this problem with a fresh install of Hardy AMD64. My SATA controller is:

00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a3) (prog-if 85 [Master SecO PriO])
        Subsystem: Hewlett-Packard Company Unknown device 1714

I found that only my *second* hard drive (sdb) was slow, and only for writes. It turned out that the sata_nv driver, for whatever reason, did not enable the write cache on the second hard disk. 'hdparm -W 1 /dev/sdb' fixed the slow speed problems for me. Maybe that will help others on here?

It's not clear why the write cache doesn't get enabled on the second drive...

Revision history for this message
NiklasW (falken) wrote :
Download full text (3.7 KiB)

I have write cashe on all my drives (3 drives, diffrent brand):

/dev/sdc:

 Model=ST3160812AS , FwRev=3.AAE , SerialNo= 4LS1VZ17
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
 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: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode
/dev/sdb:

 Model=SAMSUNG HD501LJ , FwRev=CR100-10, SerialNo=S0MUJ1NP502182
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
 BuffType=DualPortCache, BuffSize=16384kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
 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
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: unknown: ATA/ATAPI-3,4,5,6,7

 * signifies the current active mode

/dev/sda:

 Model=ST380817AS , FwRev=3.42 , SerialNo= 4MR07TJJ
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, 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: ATA/ATAPI-6 T13 1410D revision 2: ATA/ATAPI-1,2,3,4,5,6

 * signifies the current active mode

Output of lspci:
 lspci
00:00.0 Host bridge: ATI Technologies Inc RS690 Host Bridge
00:01.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (Internal gfx)
00:07.0 PCI bridge: ATI Technologies Inc RS690 PCI to PCI Bridge (PCI Express Port 3)
00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA
00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0)
00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1)
00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2)
00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3)
00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4)
00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI)
00:14.0 SMBus: ATI Technologies Inc SBx00 SMBus Controller (rev 14)
00:14.1 IDE interface: ATI Technologies Inc SB600 IDE
00:14.2 Audio device: ATI Technologies Inc SBx00 Azalia
00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge
00:14.4 PCI bridge: ATI Technologies Inc SBx00 PCI to PCI Bridge
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] HyperTransport Technology Co...

Read more...

Revision history for this message
NiklasW (falken) wrote :

I did a copy between 2 diffrent disk

FileSize: 680M

Time:
real 0m54.372s
user 0m0.036s
sys 0m3.752s

Revision history for this message
SirLancelot (lukaszgraczyk) wrote :

Hi

I have exactly the same problem on my MSI VR610 new laptop with:

ATI Technologies Inc SB600 Non-Raid-5 SATA

100% same situation as it was descripted above!

Everything on my Ubuntu 7.10 32bit looks OK but the speed of copy and system performance is definitely not OK!

Coping 700MB of data between same disc prtitions gets too much time! Burning DVDs with higher speed than x2 is theoretic possible but jumping buffers and time of burning tells that disc works too slow to make a copy in less than 20 minutes!

I strongly suggest to change this bug priority to High! Many of new laptops will work slowest than the old ones on Ubuntu and that's sucks!

Revision history for this message
SirLancelot (lukaszgraczyk) wrote :

PS.:

Exactly same situation with Ubuntu 7.10 amd64!

Revision history for this message
Léa GRIS (lea-gris) wrote :
Download full text (3.5 KiB)

Same here with Ubuntu 7.10 in a Shuttle SN25P Nforce4 chiipset and Seagate ST3160023AS 160GB,
CPU AMD Athlon(tm) 64 X2 Dual Core Processor 4200+:

hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads: 1954 MB in 2.00 seconds = 977.58 MB/sec
 Timing buffered disk reads: 36 MB in 3.51 seconds = 10.27 MB/sec

uname -a
Linux meumeu 2.6.22-14-generic #1 SMP Tue Feb 12 07:42:25 UTC 2008 i686 GNU/Linux

lspci | grep ATA
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev f3)

lsmod | grep sata
sata_nv 20612 3
libata 125168 2 sata_nv,ata_generic

hdparm -i /dev/sda

/dev/sda:

 Model=ST3160023AS , FwRev=3.18 , SerialNo=3JS2LVQH
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
 BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
 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: ATA/ATAPI-6 T13 1410D revision 2: ATA/ATAPI-1,2,3,4,5,6

 * signifies the current active mode

hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
        Model Number: ST3160023AS
        Serial Number: 3JS2LVQH
        Firmware Revision: 3.18
Standards:
        Used: ATA/ATAPI-6 T13 1410D revision 2
        Supported: 6 5 4
Configuration:
        Logical max current
        cylinders 16383 16383
        heads 16 16
        sectors/track 63 63
        --
        CHS current addressable sectors: 16514064
        LBA user addressable sectors: 268435455
        LBA48 user addressable sectors: 312581808
        device size with M = 1024*1024: 152627 MBytes
        device size with M = 1000*1000: 160041 MBytes (160 GB)
Capabilities:
        LBA, IORDY(can be disabled)
        Standby timer values: spec'd by Standard
        R/W multiple sector transfer: Max = 16 Current = 16
        Recommended acoustic management value: 254, current value: 0
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=240ns IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           * SMART feature set
                Security Mode feature set
           * Power Management feature set
           * Write cache
           * Look-ahead
           * Host Protected Area feature set
           * WRITE_BUFFER command
           * READ_BUFFER command
           * DOWNLOAD_MICROCODE
                SET_MAX security extension
           * 48-bit Address feature set
           * Device Configuration Overlay feature set
           * Mandatory FLUSH_CACH...

Read more...

Changed in linux:
status: New → Incomplete
Changed in linux-source-2.6.20:
status: New → Won't Fix
Changed in linux-source-2.6.22:
status: New → Won't Fix
Changed in linux:
status: Incomplete → Fix Released
Dan Walker (dwalker109)
Changed in linux:
status: Fix Released → In Progress
Changed in linux:
importance: Undecided → Medium
status: In Progress → Triaged
81 comments hidden view all 161 comments
Revision history for this message
Kristleifur Daðason (kristleifur) wrote :

> Can we be sure about that? The Ubuntu forums would have me believe that it is a kernel issue..
> http://ubuntuforums.org/showthread.php?t=1150108&page=4

> If it is Ubuntu specific, I'll make the change. In fact, I have already downloaded Fedora.

Well, installing a kernel without the Ubuntu patchset fixed things for me. So I'd hazard a guess that it was an Ubuntu issue.

Revision history for this message
Kristleifur Daðason (kristleifur) wrote :

Hi,

Bump.

I've now installed the mainline kernel on at least four machines: One Core 2 Duo, one Core 2 Quad and an i7 machine. 64-bit Ubuntu versions 8.10 and 9.04. In all cases, the broken I/O has been fixed by the mainline kernel install.

Revision history for this message
andre (andre-compufu) wrote :

which version?
2.6.30 doesn't work for me =(

On Mon, Jul 6, 2009 at 1:04 PM, Kristleifur
Daðason<email address hidden> wrote:
> Hi,
>
> Bump.
>
> I've now installed the mainline kernel on at least four machines: One
> Core 2 Duo, one Core 2 Quad and an i7 machine. 64-bit Ubuntu versions
> 8.10 and 9.04. In all cases, the broken I/O has been fixed by the
> mainline kernel install.
>
> --
> Slow SATA performance
> https://bugs.launchpad.net/bugs/119730
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Kristleifur Daðason (kristleifur) wrote :

> which version?
> 2.6.30 doesn't work for me =(

2.6.27.x works for me on on Ubuntu 8.10,
also 2.6.28 and 2.6.29 and 2.6.30 all work on 9.04.

Revision history for this message
Mante (mante) wrote :

I'm using jaunty 64 bit.
Unfortunately I've install a mainline kernel
Linux xxx-desktop 2.6.29-02062906-generic #02062906 SMP Fri Jul 3 10:17:03 UTC 2009 x86_64 GNU/Linux
but speed problem persists. Speed transfer between hard disks below 5Mb/sec.

Below hard disks info.

/dev/sda:

 Model=SAMSUNG SP2504C , FwRev=VT100-50, SerialNo=S09QJ1PP321450
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
 BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=?0?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=488397168
 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
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: unknown: ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode
--------------------------------------------------------------------------------------------------
/dev/sdb:

 Model=SAMSUNG HD753LJ , FwRev=1AA01113, SerialNo=S13UJDWQ801281
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
 BuffType=DualPortCache, BuffSize=32767kB, MaxMultSect=16, MultSect=?0?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=1465149168
 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
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
 AdvancedPM=yes: disabled (255) WriteCache=enabled
 Drive conforms to: unknown: ATA/ATAPI-3,4,5,6,7

 * signifies the current active mode

Singular Hard disk performance is standard/
sudo hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads: 3872 MB in 2.00 seconds = 1936.29 MB/sec
 Timing buffered disk reads: 194 MB in 3.01 seconds = 64.54 MB/sec

/dev/sdb:
 Timing cached reads: 5664 MB in 2.00 seconds = 2833.85 MB/sec
 Timing buffered disk reads: 286 MB in 3.02 seconds = 94.67 MB/sec

Revision history for this message
germulvey (gerardmulvey) wrote :

I am noticing that the problem is directional also.
Copying from sdb to sda was about 37.5 MB/s and the other direction sda to sdb was 11.8 MB/s for the same 1.6 GB file.

Revision history for this message
germulvey (gerardmulvey) wrote :
Download full text (5.9 KiB)

additional info for #127
nForce 560 - gigabyte motherboard
amd athlon 64 x2 4400+
ubuntu 9.04 64 bit - update status ~ current

/dev/sda:

 Model=SAMSUNG SP2504C , FwRev=VT100-41, SerialNo=S09QJ1WL915408
 Config={ Fixed }
 RawCHS=16383/16/63, TrkSize=34902, SectSize=554, ECCbytes=4
 BuffType=DualPortCache, BuffSize=8192kB, MaxMultSect=16, MultSect=?16?
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=488397168
 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
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
 AdvancedPM=no WriteCache=enabled
 Drive conforms to: unknown: ATA/ATAPI-1,2,3,4,5,6,7

 * signifies the current active mode

root@linger-ger:/home/ger# hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
 Model Number: SAMSUNG SP2504C
 Serial Number: S09QJ1WL915408
 Firmware Revision: VT100-41
Standards:
 Used: ATA/ATAPI-7 T13 1532D revision 4a
 Supported: 7 6 5 4 & some of 8
Configuration:
 Logical max current
 cylinders 16383 16383
 heads 16 16
 sectors/track 63 63
 --
 CHS current addressable sectors: 16514064
 LBA user addressable sectors: 268435455
 LBA48 user addressable sectors: 488397168
 device size with M = 1024*1024: 238475 MBytes
 device size with M = 1000*1000: 250059 MBytes (250 GB)
Capabilities:
 LBA, IORDY(can be disabled)
 Queue depth: 32
 Standby timer values: spec'd by Standard, no device specific minimum
 R/W multiple sector transfer: Max = 16 Current = 16
 Recommended acoustic management value: 254, current value: 128
 DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 udma7
      Cycle time: min=120ns recommended=120ns
 PIO: pio0 pio1 pio2 pio3 pio4
      Cycle time: no flow control=120ns IORDY flow control=120ns
Commands/features:
 Enabled Supported:
    * SMART feature set
      Security Mode feature set
    * Power Management feature set
    * Write cache
    * Look-ahead
    * Host Protected Area feature set
    * WRITE_BUFFER command
    * READ_BUFFER command
    * NOP cmd
    * DOWNLOAD_MICROCODE
      SET_MAX security extension
    * Automatic Acoustic Management feature set
    * 48-bit Address feature set
    * Device Configuration Overlay feature set
    * Mandatory FLUSH_CACHE
    * FLUSH_CACHE_EXT
    * SMART error logging
    * SMART self-test
    * General Purpose Logging feature set
    * Segmented DOWNLOAD_MICROCODE
    * SATA-I signaling speed (1.5Gb/s)
    * SATA-II signaling speed (3.0Gb/s)
    * Native Command Queueing (NCQ)
    * Host-initiated interface power management
    * Phy event counters
      DMA Setup Auto-Activate optimization
      Device-initiated interface power management
    * Software settings preservation
    * SMART Command Transport (SCT) feature set
    * SCT Long Sector Access (AC1)
    * SCT LBA Segment Access (AC2)
    * SCT Error Recovery Control (AC3)
    * SCT Features Control (AC4)
    * SCT Data Tables (AC5)
Security:
 Master password revision code = 65534
  supported
 not enabled
 not locked
 not frozen
 not expired: security count
  sup...

Read more...

Revision history for this message
Kristleifur Daðason (kristleifur) wrote :

Hi all,

I was moving disks around on my motherboard because the SATA cables blocked a video card. Two disks were placed on a secondary SATA controller on the motherboard which I hadn't used before. This has caused the slowness to resurface, with the mainline kernel.

Previously, all the disks were on an "82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA AHCI Controller", using driver "ahci", capabilities "storage msi pm bus_master cap_list emulated", configuration "driver=ahci latency=0 module=ahci". According to lshw.

In the rearrangement, two disks were placed on a "JMicron 20360/20363 AHCI Controller", also using driver "ahci", capabilities "storage pm pciexpress bus_master cap_list emulated", configuration "driver=ahci latency=0 module=ahci".

Before installing mainline, there was both IO and overall system lag with the Intel controller. With mainline, the Intel behaves fine, but the JMicron turns out to be slow. (To the point where I personally consider it broken.)

I hope this info helps!

Revision history for this message
andre (andre-compufu) wrote :

Hello guys,

some news? performance is still awfull, I don't know what to do. This way,
linux's no more an option.

On Fri, Aug 28, 2009 at 8:25 AM, Kristleifur Daðason
<email address hidden>wrote:

> Hi all,
>
> I was moving disks around on my motherboard because the SATA cables
> blocked a video card. Two disks were placed on a secondary SATA
> controller on the motherboard which I hadn't used before. This has
> caused the slowness to resurface, with the mainline kernel.
>
> Previously, all the disks were on an "82801IR/IO/IH (ICH9R/DO/DH) 6 port
> SATA AHCI Controller", using driver "ahci", capabilities "storage msi pm
> bus_master cap_list emulated", configuration "driver=ahci latency=0
> module=ahci". According to lshw.
>
> In the rearrangement, two disks were placed on a "JMicron 20360/20363
> AHCI Controller", also using driver "ahci", capabilities "storage pm
> pciexpress bus_master cap_list emulated", configuration "driver=ahci
> latency=0 module=ahci".
>
> Before installing mainline, there was both IO and overall system lag
> with the Intel controller. With mainline, the Intel behaves fine, but
> the JMicron turns out to be slow. (To the point where I personally
> consider it broken.)
>
> I hope this info helps!
>
> --
> Slow SATA performance
> https://bugs.launchpad.net/bugs/119730
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Petter (pettno) wrote :

This bug with proposals for fix seems very interesting:
https://bugs.launchpad.net/bugs/427210

Revision history for this message
Gremlyn1 (gremlyn1) wrote :

Might as well chime in as one more affected. Running an AMD Phenom with a 1TB SATA and have AWFUL speeds for data transfer like everyone else. :(

Revision history for this message
Petter (pettno) wrote :

Using the deadline scheduler had no significant effect on my problems (ref the 427210 bug). I give up. AFAIK the Asus P5B and P5QL SE mainboards are not compatible with Ubuntu (and/or the kernel or some I/O stuff used by Ubuntu). I will install Ubuntu on another hopefully compatible box, as I really need to use a linux distro.

BTW: My most recent working Ubuntu version was 6.10. The scheduler stuff seems to help some.

Revision history for this message
lefty.crupps (eljefedelito) wrote :

> This way, linux's no more an option.

This bug only seems to affect Ubuntu; there are other Linux options out there.

Revision history for this message
andre (andre-compufu) wrote :

Hi,

not so sure...
the same behavior happened when I installed slack 13, fedora and macosx.

On Mon, Sep 14, 2009 at 10:43 AM, lefty.crupps <email address hidden>wrote:

> > This way, linux's no more an option.
>
> This bug only seems to affect Ubuntu; there are other Linux options out
> there.
>
> --
> Slow SATA performance
> https://bugs.launchpad.net/bugs/119730
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
lefty.crupps (eljefedelito) wrote :

> > This bug only seems to affect Ubuntu; there are other Linux options out
> > there.

> the same behavior happened when I installed slack 13, fedora and macosx.

Then it may possibly be a larger issue, as I've not come across this on any other distro, and Mac OSX has completely different technology for kernel and drive access.

Revision history for this message
Mindaugas (mindedie) wrote :

https://bugs.launchpad.net/bugs/427210 didn't helped nor others proposals (some just made more problems :D). Live-cd not effected, anyone tested it?

Revision history for this message
andre (andre-compufu) wrote :

I tested here too, with no sucess.
Live cd and pen drive performace are ok.

On Mon, Sep 14, 2009 at 12:30 PM, mindedie <email address hidden> wrote:

> https://bugs.launchpad.net/bugs/427210 didn't helped nor others
> proposals (some just made more problems :D). Live-cd not effected,
> anyone tested it?
>
> --
> Slow SATA performance
> https://bugs.launchpad.net/bugs/119730
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
Tom (tna5000) wrote :

I guess I'm just adding my two cents here, trying to get this bug noticed. I'm having the same issue, and so is a co-worker who runs pretty much the same setup. If I run windows on my current setup, no problem. Jaunty just seems to be very slow when copying large files between the internal SATA drives and another USB drive.

Revision history for this message
The GuiGuy (linux-finalfiler) wrote :

Some good news. In part, at least.

ASUS M2N-VN-DH mobo, Ubuntu Jaunty (9.04) AMD64.

This syste, had been unusable. If I enabled AHCI the system would lock up on the grub loading message. This meant I had to tune down to IDE mode. SATA transfers were awful and general file transfers to USB where even worse.

I'm pleased to report that after the latest kernel updates - 2.6.28-15-generic #52-Ubuntu SMP Wed Sep 9 10:48:52 UTC 2009 x86_64 GNU/Linux" the system now boots with AHCI enabled and xfer speeds are right up there where we'd expect them to be. Importantly high xfer rates are maintained on extended large file transfers. All in all, it's a relief.

Unfortunately the problem persists on another system with an ASUS M3A mobo when running Ubuntu Jaunty (9.04) AMD64m kernel 2.6.28-15. No problem with Fedora, however.

Revision history for this message
hessmo (hessmo) wrote :

I am having the exact same issue. It has gone away, and then come back several times since I installed jaunty. I am running the amd64 kernel on a MSI motherboard with ATI graphics. The primary hard disk works great, all the secondary ones I can read from at full speeds, but writes max out the cpu (quad phenom II) and top out at about 6 Mb/s. Very very frustrating. Problem isn't there in windows, and doesn't change if I force the drives into udma 6.

Revision history for this message
jlelusz@gmail.com (jlelusz) wrote :

I'm having the same problem. Jaunty server (32bits version) with Zotac IONITX-A and one sata hdd. During large file copy CPU load goes to the roof and transfer rate drops down. Tested with cp, mc and samba. With samba (and gigabit ethernet) it starts from 65MB/s and drops down to 8-10MB/s within 2-3 seconds (at the same time cpu load goes up). It would be nice to have it sorted, otherwise I'm going to end up with Windows Home Server, because file transfer speed is unacceptable with this bug - and the machine was built to be a file server ;-(
I'm willing to try different things - if someone is willing to point me in the right direction.

Revision history for this message
meuns (sylvainmeunier26) wrote :

I have the same problem using Karmic Koala. The first disk works finely but my second hard drive is very slow (~3MB/s).

The uname result :
Linux Void 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux

My computer :
Intel Core i7 920
Gigabyte GA-EX58-UD4 (Intel X58 Express)
Seagate Barracuda 7200.12 SATA 3Gb/s - 500 Go 7200 RPM 16 Mo Serial ATA II (1st disk)
Seagate Barracuda 7200.11 SATA 3Gb/s - 1 To 7200 RPM 32 Mo Serial ATA II (2nd disk)

I hope this issue will be solved.

Revision history for this message
franck (franck-fleurey) wrote :

Same problem here also with Karmic Koala.
uname : Linux AMD64 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux
My sata disks show ok performances if tested with hdparm:

/dev/sdb:
 Timing cached reads: 1912 MB in 2.00 seconds = 956.43 MB/sec
 Timing buffered disk reads: 224 MB in 3.01 seconds = 74.47 MB/sec

/dev/sdc:
 Timing cached reads: 1892 MB in 2.00 seconds = 945.87 MB/sec
 Timing buffered disk reads: 332 MB in 3.00 seconds = 110.64 MB/sec

But if I try to copy a file from one place to another (same disk, same or different partition or different disk) I get steady really poor performances of between 2 and 4 MB/sec.
In addition, the whole system becomes really slow while copying.
This is both using cp in a console or using Gnome and has been for a while.
All my disks/partitions are formated ext3.

My SATA controller is :
00:05.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2)

I hope this problem will get a solution, it is quite difficult to work with big file in the current situation. I would be glad to provide any additional info if it can help.

Franck

Revision history for this message
The GuiGuy (linux-finalfiler) wrote :

franck and others, some of us have seen improvement by enabling the proposed ubuntu repositories, especially kernel version 2.6.31-15-generic.

The downside of this approach would be, of course, that something else will break.

Revision history for this message
Charles Whittle (napau) wrote :

Howdy! I tried enabling the proposed ubuntu repositories, downloaded and installed all updates; no joy.
Even rebooted computer and did clean remount of external drives. Currently getting a transfer speed
of 70.5 kbs. Have observed that if I cut and paste just a few folders the speed will rise to about 1.2 Mbs.
I am trying to move a large folder that contains around 9,000 folders with about 1.5 million files; total size
is approximately 40 gigabytes. Takes over an hour just to start moving files and the speed is at first
only 100 bytes per second and gradually increases as the number of files left to be moved decreases.
If I move around 1,000 files the move also begins slowly and then speeds up, but never faster than 1.2 Mbs.
I am running Karmic Koala, but have had this problem since Hearty Heron. If someone would be kind
enough to give me the commands I will send additional system information. My computer is a Dell
Optiplex 280 . Thanks!

Revision history for this message
Gus (wallace-angus) wrote :

I have what I think is the same problem, and I think I've solved it by installing the mainline kernel:

System:
AMD X2 3800+, 1GB RAM,
/dev/sda 1 TB
/dev/sdb 500 GB
/dev/sdc 500 GB

Symptoms:
Very slow reads (in particular) and writes to/from /dev/sda
hdparm -Tt reported /dev/sda as buffered reads at 50 - 60 MB/sec, however a cp from /dev/sda to /dev/sdb occured at about 6 MB/sec, and a cp to USB occured at 1-2 MB/sec - during which the system was almost non-responsive - top showed iowait at about 60%. Paging in/out of RAM is glacial.
I also tried adding various params to fstab (noatime, etc) and changing the scheduler, to little effect.

Solution (please note, I'm running Ubuntu AMD64 with the nvidia driver blob!! - your mileage may vary):
As recommended by guiguy (thanks!), I downloaded the mainline kernel. I also needed nvidia drivers, so I followed the procedure here (post by Zeroth Eksaz on 2009-06-12):
https://bugs.launchpad.net/ubuntu/+source/nvidia-common/+bug/384639

In a nutshell, I went here
http://archive.ubuntu.com/ubuntu/pool/restricted/n/nvidia-graphics-drivers-180/
and downloaded
nvidia-180-kernel-source_185.18.36-0ubuntu9_amd64.deb
nvidia-180-libvdpau-dev_185.18.36-0ubuntu9_amd64.deb
nvidia-glx-180-dev_185.18.36-0ubuntu9_amd64.deb
nvidia-glx-180_185.18.36-0ubuntu9_amd64.deb
and installed them all with
sudo dpkg -i nvidia*185.18.36*

then I went here
http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.32.2/
and downloaded
linux-headers-2.6.32-02063202-generic_2.6.32-02063202_amd64.deb
linux-headers-2.6.32-02063202_2.6.32-02063202_all.deb
linux-image-2.6.32-02063202-generic_2.6.32-02063202_amd64.deb
linux-source-2.6.32_2.6.32-02063202_all.deb
and installed them with
sudo dpkg -i linux*2.6.32*

I watched this process via iotop, and had disk reads and writes generally less than 1-2 Mb/sec, with iowaits around 60% and the system almost non-responsive. Booting into the new kernel (with nvidia still working), I can now cp from /dev/sda to /dev/sdb at about 40 MB/sec (though I've yet to extensively test it - it feels a lot more responsive)

Now, I realise I'm running a newer kernel to that from before, so it's not a like-for-like comparison, but I still think it's likely that guiguy's theory (about the problem being with an Ubuntu kernel patch) is likely to be correct. If people can suggest some tests for me to do that might help, I'll try and be of assistance, but this is the main PC in my house, and is needed!
I'm certainly going to be wary about applying future ubuntu kernel upgrades! (might try and stick with the mainline kernel - what a pain!)

Hope this is helpful, and Merry Christmas :-)

Revision history for this message
Andy Whitcroft (apw) wrote :

On Wed, Dec 23, 2009 at 10:48:22AM -0000, Gus wrote:

> Now, I realise I'm running a newer kernel to that from before, so it's not a like-for-like comparison, but I still think it's likely that guiguy's theory (about the problem being with an Ubuntu kernel patch) is likely to be correct. If people can suggest some tests for me to do that might help, I'll try and be of assistance, but this is the main PC in my house, and is needed!
> I'm certainly going to be wary about applying future ubuntu kernel upgrades! (might try and stick with the mainline kernel - what a pain!)

You could trivially confirm whether this is an Ubuntu patch by picking the
mainline kernel which the Ubuntu kernel you have is based on. Your full
Ubuntu kernel version can be found with 'cat /proc/version_signature',
and you can map that to a mainline kernel version via the table at the
URL below:

    http://kernel.ubuntu.com/~kernel-ppa/info/kernel-version-map.html

So if you have 2.6.31-16.51 then you would want to test with mainline
2.6.31.4. As before the mainline kernel can be found at the URL below:

    https://wiki.ubuntu.com/KernelTeam/MainlineBuilds

Please do report any testing you do back here, please include full version
numbers for both kernels and indicate how you did your testing.

-apw

Revision history for this message
Matt (mattjubb) wrote :

I have the same problem as reported many times here - Slow file transfers on one harddisk and the other works fine. hdparm -Tt gives me reasonable speeds. So I tried updating to a newer kernel - linux-image-2.6.32-02063202-generic_2.6.32-02063202_i386.deb

And the result is absolutely no change. This is such an annoying problem

Any other suggestions? Id be very grateful

Matt

Revision history for this message
The GuiGuy (linux-finalfiler) wrote :

Matt,
This bug, which has been around since 2007 (it is now 2010!!) was enough for to remove Linux from my desktop computers. My suggestion would be to eat humble pie and buy a copy of Windows 7.

Comparison, same hardware, SATA drives, 1G file; Linux > 5 minutes. Win7 < seconds!!

Revision history for this message
lefty.crupps (eljefedelito) wrote :

> This bug, which has been around since 2007 (it is now 2010!!)
> was enough for to remove Linux from my desktop computers

This bug only seems to afect the *buntu distributions; its not present in the upstream Debian distro FYI. Try other Linux distros before jumping ship completely, would be my suggestion.

€l ]€f€

Revision history for this message
andre (andre-compufu) wrote :

This bug is really serious.
It doesn't affect only *buntu distributions. I had the same problem
with fedora, debian, slackware.
Unfortunately, the only feasible system was windows 7, witch works very well.

On Mon, Jan 4, 2010 at 12:58 PM, lefty.crupps <email address hidden> wrote:
>> This bug, which has been around since 2007 (it is now 2010!!)
>> was enough for to remove Linux from my desktop computers
>
> This bug only seems to afect the *buntu distributions; its not present
> in the upstream Debian distro FYI.  Try other Linux distros before
> jumping ship completely, would be my suggestion.
>
> €l ]€f€
>
> --
> Slow SATA performance
> https://bugs.launchpad.net/bugs/119730
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Revision history for this message
ivanxx (ivan-monodosis) wrote :

I'm on an AMD64 2.6.31-19-generic #56-Ubuntu SMP and experiencing the same problem...

Copying speed for some large files (2-12 Gb per file) from SATA to a USB drive drops to 1,4Mb/s after the first hundreds of Mb are copied. I have to copy around 1Tb, and I'm expecting it to take 8 days!!! It should take around 14 hrs at a decent 20Mb/s speed...

Also the CPU wait states are around 50% all the time, thus the CPU use is 100% and load average 7.5... I suppose there's something wrong down in the kernel, perhaps the buffer for the first hundred Mbs not getting emptied/reused and everything slowing down after that.

Ivan.

Revision history for this message
Shane Rice (shane2peru) wrote :

On Wed, 2010-02-17 at 19:17 +0000, ivanxx wrote:

> I'm on an AMD64 2.6.31-19-generic #56-Ubuntu SMP and experiencing the
> same problem...
>
> Copying speed for some large files (2-12 Gb per file) from SATA to a USB
> drive drops to 1,4Mb/s after the first hundreds of Mb are copied. I have
> to copy around 1Tb, and I'm expecting it to take 8 days!!! It should
> take around 14 hrs at a decent 20Mb/s speed...
>
> Also the CPU wait states are around 50% all the time, thus the CPU use
> is 100% and load average 7.5... I suppose there's something wrong down
> in the kernel, perhaps the buffer for the first hundred Mbs not getting
> emptied/reused and everything slowing down after that.
>
> Ivan.
>

Please see post #12 and #14 of this thread
http://ubuntuforums.org/showthread.php?p=8769095#post8769095 if you are
copying to NTFS. This was amazing the difference it made. I don't know
much about how the ext3 fs works, but to sum up those posts, it depends
on how fragmented or non-fragmented the fs is when copying to NTFS. If
you are not copying to NTFS, then just ignore this solution, or read it
if you understand the workings of ext3 or others and perhaps it can put
you on a track that may be the problem with those fs.

Shane

Revision history for this message
Jonatan Magnusson (jonatan-cmteknik) wrote :

I have the same problem:

My setup:

 * Gigabyte P35 motherboard
 * 1 WD 500G IDE drive
 * 1 Seagate 500G SATA drive

hdparm ("hdparm -tT") gives 2966/109 MB/sec (cached and buffered reads) for the SATA-drive and 3026/74 MB/sec for the IDE-drive. No problem there.

In Windows XP there is no problem with either drive. Both are fast (~30-40 MB/sec).

Here are the tests I've done:

 * Reading from the IDE-drive is fast (+30 MB/sec)
 * Writing to the IDE-drive is fast (+30 MB/sec)
 * Reading from the SATA drive is SLOW (~3.5 MB/sec)
 * Writing to the SATA drive is fast (+30 MB/sec)

I've done these tests on two partitions of the SATA-drive, and using both FAT32 and ext4.

Revision history for this message
Thomas Herve (therve) wrote :

FWIW, I thought I had the same problem. But using mainstream kernel didn't change anything. My real problem is that most of my big files are downloaded via bittorrent, which ends up fragmenting files *a lot*. See http://trac.transmissionbt.com/ticket/849 in transmission bug tracker for example. I used shake (http://vleu.net/shake/) to defragment my disk, and now everything is fast again. I plan to switch to ext4 to see if the problem goes away for future downloads.

Revision history for this message
penalvch (penalvch) wrote :

Dan Walker, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? If so, could you please test for this with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ .

If it remains an issue, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder, but the one at the top) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.13-rc4

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

no longer affects: linux-source-2.6.20 (Ubuntu)
no longer affects: linux-source-2.6.22 (Ubuntu)
Changed in linux (Ubuntu):
status: Triaged → Incomplete
Revision history for this message
Ilya Murav'jov (muravjov-il) wrote :

Hi,

I found this bug is similar to mine (it hurts i386 only). Here is my workaround:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1264707/comments/18 .

Please try it and comment if it works for you.

Revision history for this message
Rafael García (rgo) wrote :

It also happens with kernel 3.13.2-031302-generic #201402061638 (from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.13.2-trusty/)

Based on previous comment of Ilya Murav'jov I "solved" it temporally with powertop.

I disabled powersaving modes of these devices:

PM ejecutable para dispositivo PCI Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1
PM ejecutable para dispositivo PCI Intel Corporation 5 Series/3400 Series Chipset 4 port SATA AHCI Controller

Revision history for this message
penalvch (penalvch) wrote :

Rafael García, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

Revision history for this message
dino99 (9d9) wrote :

closing that old report, as it has not got recent comment.

Changed in linux (Ubuntu):
status: Incomplete → Invalid
Displaying first 40 and last 40 comments. View all 161 comments or add a comment.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.