[conspire] SATA HD transfers slow?

[Luke S Crawford]

Mark S Bilk <mark at cosmicpenguin.com> writes:

> 
> When I copy a 700-900MB file from my 1TB 7200 RPM SATA drive 
> to my 1.5 TB 5900 RPM SATA drive (both Seagate Barracudas) the 
> transfer rate varies from 8 to 29 MB/sec. (8, 11, 27, 29MB/sec
> in four tests).  I don't know what causes the variation.  
> I get similar rates transferring large files between one of the
> internal drives and a Seagate FreeAgent Desk 1TB USB2.0 drive.
> 
> The spec sheet says up to 120MB/sec sustained data transfer 
> rate for the 7200 RPM drive, 

This is /completely unrealistic/  at least for anything but the 
very outermost tracks on a absolutely pristine drive  - on a really good 
day, with a really good disk (there is variance, even amongst the same 
part number, mostly, I believe, due to remapped sectors) I'd expect 
100MB/sec to the outer tracks and less if you were averaging the whole
damn thing.

(now, this data is from the older seagate 1.5TB and 750GB drives of a few 
years back, before they started selling the 5900RPM kit, so it's possible
things have improved significantly) 

Note, the inner tracks on a drive get maybe half the speed of the outer tracks
on a drive.

If you want to do this test without that variable, partition both
disks so you are only using the first 50GiB  (in fdisk, you are going from
the outer tracks to the inner tracks, so place your faster/more heavily
used partitions first.)  

Back when i used consumer grade drives in my servers (a few years back)  
I had this problem very often.  One drive would max out at 100MB/sec
for sequential transfers on the outer track, and another with the same
model number would only get 30MB/sec.   

My theory is that it had remapped sectors coming from the factory.

See, when a drive finds a bad sector, it remaps it to some spare space
set aside for this.  the problem with this (well, one of the problems)
is that it doesn't change the sector numbers.  So your computer thinks
it's pulling a sequential read off the disk, but the disk /actually/ is
doing a bunch of random seeks to the remapped sector space.  

When this happened to me, well, at the time most of my disks came from 
fry's, so i just took the slow one back to frys and got another.  

(yet another reason to avoid the things at frys that have the 'returned 
by customer' sticker.  I doubt they took my "but it's slow" complaint
seriously, as the thing would still format, and generally worked fine.)  

Switching to 'enterprise sata' has largely solved the problem.   I mean,
I switched so that bad drives would actually fail out of my raid...
but the better quality control is also pretty nice.    But yeah, 
failing that, just return the goddamn drive.   

It would be interesting to compare sequential transfer speeds of new 
drives to referbished.

Now, of course, one could argue that except in extreme cases I shouldn't
worry too much about sequential transfers.  I don't think my drives
have seen a single sequential transfer larger than a meg or two since the
day I put 'em in production.  but if I'm right, and low sequential speeds
mean high remapped sector counts, then that means the drives are closer
to failure anyhow, so returning them is reasonable.  




> so the 5900 RPM one should do 
> about 98MB/sec.  I think I should be getting 50-90MB/sec from 
> one drive to the other.

Now, I haven't used 5900rpm drives myself, but  90MB/sec is pretty good
for a 7200rpm drive, so I'd guess they'd be slower.  

> # hdparm -d /dev/sda
> 
> /dev/sda:
>  HDIO_GET_DMA failed: Inappropriate ioctl for device
> 
> Same result for /dev/sdb.

In PIO mode, I'd expect things to be much slower.  like less than 10MB/sec.

I just tried the hdparm command on some of my stuff, where dma is working 
fine, and I got the same ioctl error you got.  

here is a snippit of my dmesg from my old servers built back when I used
consumer drives.  

[    5.071490] sd 2:0:0:0: [sda] Attached SCSI disk
[    5.079048] ata4.00: ATA-8: MAXTOR STM31000333AS, MX15, max UDMA/133
[    5.079097] ata4.00: 1953525168 sectors, multi 0: LBA48 NCQ (depth 31/32)
[    5.121032] ata4.00: configured for UDMA/133
[    5.121187] scsi 3:0:0:0: Direct-Access     ATA      MAXTOR STM310003 MX15 PQ: 0 ANSI: 5


Note it says UDMA/133  ... that's dma.   it would say PIO otherwise

Personally, I don't have the patience to jack around with nvidia crap
when it doesn't work right off the bat.  (funny, coming from a guy who 
probably owns more than 17 dual socket f servers with nvidia mcp55 
chipsets)  -   Central computers sells two port cards with silicon 
image chips that I've used with great success.  Don't worry that it's
single lane pcie... that's plenty of bandwidth.  I think they are 
around twenty bucks.  totally worth it. 

-- 
Luke S. Crawford
http://prgmr.com/xen/         -   Hosting for the technically adept
http://nostarch.com/xen.htm   -   We don't assume you are stupid.