Interesting Findings: Seagate Barracuda 7200.8 400GB S-ATA

hjreggel

Weaksauce
Joined
Sep 23, 2005
Messages
96
Hi,

This is a complicated issue, so take your time.

I bought the Seagate Barracuda 7200.8 400GB S-ATA because it was listed as one of the fastest large disks in a way overrated local computer magazine. I was not able to get a clean zone diagram with any of my S-ATA host controllers (SiI 3112, SiI 3114R, ICH6R Southbridge) or the S-ATA to ATA/133 bridge (Marvell 88SA8040-TBC). Now Toms Hardware shows the same bad diagram for this disk. Here's mine:
ST3400832AS.gif


I was wondering what could be going on an did some math: My test program took samples of 32MB, so I calculated the effective transfer rate if the disk would miss some head or track switches, and has to wait a certain number of full revolutions during the measurement.
ST-Math.gif


I also got the idea to use dots instead of a line in the diagram. Guess what: Most dots appear on certain "quantum levels" which are exactly the effective transfer rate with a certain count of idle revolutions.
ST-Quant.gif


It looks like the head skew and/or track skew is too short, so that the disk sometimes misses the first sector of the next track and has to wait one full revolution for the data. The 32MB transfers take about 56 revolutions, and the worst rate equals 10 idle revolutions.

Hans-Jürgen
 
compslckr said:
do 10 revolutions really matter when it is doing 7200 of them every minute?

Do ram timings really matter? I mean, who cares if the ram is accessed only once every 2 cycles instead of 4? They still get accessed hundreds of thousands of times per second anyway right? same concept.
 
do 10 revolutions really matter when it is doing 7200 of them every minute?

Well if it could do a complete read in a 1 revolution instead of 10 you're looking at a massive performance boost.

I've got a pair of 250GB drives and i'm not real sure what is up with their performance. It's ok but doesn't seem anywhere near where it should be. Not to mention the things run hot as hell compared to any other drives i've seen. I've also got a pair of 10k SCSI drives in the system that don't put off nearly as much heat as the 7200.8's do. They're quiet, that's about all I can say for them and I just use them for storage so I'm not overly concerned about performance.
 
hjreggel said:
It looks like the head skew and/or track skew is too short, so that the disk sometimes misses the first sector of the next track and has to wait one full revolution for the data. The 32MB transfers take about 56 revolutions, and the worst rate equals 10 idle revolutions.
That's pretty amazing findings! This means not-so-good things for the 7200.9s unless this has been corrected. Glad I didn't buy 3 of these last week...

Do you have other drives of this generation that you could test in the same way? It'd be interesting to see if other companies' disks show the same results or if they've got this licked.

 
Ouch. Methinks Seagate set the bar a little to high with 133GB platters. Does this same phenomenon affect 300GB 7200.8s with 100GB platters? That would answer some questions, as it would answer if this is a limitaion of the read/write heads and servos, or is a problem with Seagate's design of the drive.

Once again, Seagate bit off more than they could chew with 7200.8, IMO. Yes, they may have achieved the platter density, but platter density must be accompanied by seek performance, servo precision, reliability, and a budget. They had to compromise somewhere, and it looks like it was on performance and precision :( At least it wasn't reliability :eek:
 
Hi Doug,

The weird thing about this is that this only seems to happen with the S-ATA model, not the P-ATA. Here's the link to Toms Hardware, the two graphs at the bottom, the green line is read:
http://www.tomshardware.com/storage/20050927/hd_round_up-29.html

I was also wondering why the cache can't compensate for this, since one track would be something like 600kB. If the head misses the first sector, the others should get cached, and as soon as the first one is found, the others should be delivered from the cache.

This reminds me of the "cacheseg" issue with the IBM DDRS disks where the cache configuration had impact on the sustained data rate with some SCSI host controllers.

Hans-Jürgen
 
btw, i didn't mean to crap on your thread, this stuff is just way beyond my understanding.

but props for doing what looks like some pretty crazy research into something.
 
Hi wake,

No problem. I am just wondering, what kind of Coke Zardoz was talking about ;-)

Back to the harddisk: I am really concerned, whether this could also affect the reliabilty, besides the performance impact.

Hans-Jürgen
 
SR got similar results, with a sawtooth looking graph, rather than flat stairstep. This may yet go farther in explaining the lackluster performance results with the 7200.8 - I wonder if the PATA version is significantly faster because it doesn't suffer from this issue?
 
Hi Doug,

Thanks for posting the link. It looks like nobody is able to get proper results with this drive.

The sawtooth look at SR is due to larger sample size. My test program uses 32MB samples. If I average the results across more samples, the positive and negative peaks get flatter. At the same time, the diagram gets washed out, so that you can't see the media zone borders.

I'll contact the reseller and ask if they would take the drive back...

Hans-Jürgen
 
compslckr said:
do 10 revolutions really matter when it is doing 7200 of them every minute?

Yeah. Because even at 7200 RPM, ten revolutions is about 83 milliseconds. How many floating point operations can your Newcastle do in that time?

Meanwhile, awesome anaylsis and great writeup Hans. I wish more smart guys like you were writing for hardware review sites, instead of the dipshits who post two pages of pictures of the box.
 
mikeblas said:
Meanwhile, awesome anaylsis and great writeup Hans. I wish more smart guys like you were writing for hardware review sites, instead of the dipshits who post two pages of pictures of the box.
QFT! I'd love to see some [H]ardcore reviews of hardware like this rather than the usual.

 
Back
Top