Are all SATA cables the same?

  • Thread starter Thread starter Metspitzer
  • Start date Start date
The Daring Dufas <the- said:
So the SATA III drive will work in a computer with a SATA II controller
and doesn't care about the speed limit of the controller because it will
never be able to transfer data faster anyway? O_o
Click to expand...

Yes. You need SATA3 for SSDs.

The latest crop of 4Tb hard drives (1TB per platter) have SATA3
interfaces, but it's pretty pointless because their maximum sustained
transfer rate is still only about 160MB/s, which is well within SATA2's
300MB/s.
 
Loren said:
There's nothing out there that can max a SATA3 yet but he said all he
has is a SATA2--and that will limit transfers with a good SSD.
Click to expand...

Yes, and he also said "I bought a new hard drive with 6Gbps". We're
talking about his hard drive, not an SSD.
 
This drive says 6Gbs. Is that not supposed to be the transfer rate?
http://www.newegg.com/Product/Product.aspx?Item=N82E16822148840
Click to expand...

It's marketing. It says it has a 6Gbps interface, and that is provably
true, but it remains that the maximum transfer rate of the drive will
come nowhere near that.

There is one true fact listed that might benefit from a SATA3 interface:
"SATA 6Gb/s interface optimizes burst performance"
But I doubt even the burst rate of a spinning drive will reach 3Gbps.
 
So long as it isn't a good SSD that's the case. You will lose
performance off a good SSD, though.
Click to expand...

I'm not so flush with money that I can afford to buy any SSD storage.
I'll be lucky enough to come up with the cash for a whirligig drive. ^_^

TDD
 
Metspitzer said:
This drive says 6Gbs. Is that not supposed to be the transfer rate?
Click to expand...

It's the transfer rate of the SATA link between the drive's cache and
the controller, yes. What you're interested in, the *real-world*
benchmark, is the transfer rate off the platter, which is nowhere near
as fast.

Let's say you're loading a 100MB file. The drive has a 64MB cache, not
all of which will be available for caching reads. The drive can fill
the cache and transfers from that to the controller will be at 6Gbit/s
(about 580MBps), but once the cache is exhausted, the rest of the file
can only flow to the controller as fast as it comes off the platter,
which is about 160MB/s for a 5400rpm drive, and that's a maximum reading
from the outer edges of the platter. It'll be considerably slower
reading from the inner areas of the disk.

Even if you're loading a file small enough to fit entirely within the
drive's cache, there's read latency, access time and fragmentation to
consider. The OS has to read the file table and determine which sectors
on the drive constitute the full file, then the drive has to move the
heads to the right part of the disk (seek time) and wait for the
required sector to pass under the head (access time) then load them into
the cache. This latency means that in reality, even files which
theoretically would fit within the cache will not transfer at anything
like the full SATA interface speed.

SSDs don't suffer from this problem - they don't have mechanics to move
around to locate sectors, and so seek time and access time are to all
intents and purposes instant. That's why they are so much faster.
 
It's the transfer rate of the SATA link between the drive's cache and
the controller, yes. What you're interested in, the *real-world*
benchmark, is the transfer rate off the platter, which is nowhere near
as fast.

Let's say you're loading a 100MB file. The drive has a 64MB cache, not
all of which will be available for caching reads. The drive can fill
the cache and transfers from that to the controller will be at 6Gbit/s
(about 580MBps), but once the cache is exhausted, the rest of the file
can only flow to the controller as fast as it comes off the platter,
which is about 160MB/s for a 5400rpm drive, and that's a maximum reading
from the outer edges of the platter. It'll be considerably slower
reading from the inner areas of the disk.

Even if you're loading a file small enough to fit entirely within the
drive's cache, there's read latency, access time and fragmentation to
consider. The OS has to read the file table and determine which sectors
on the drive constitute the full file, then the drive has to move the
heads to the right part of the disk (seek time) and wait for the
required sector to pass under the head (access time) then load them into
the cache. This latency means that in reality, even files which
theoretically would fit within the cache will not transfer at anything
like the full SATA interface speed.

SSDs don't suffer from this problem - they don't have mechanics to move
around to locate sectors, and so seek time and access time are to all
intents and purposes instant. That's why they are so much faster.
Click to expand...

I feel like Penny on the Big Bang Theory.

I know you think you are explaining this to me, but you are really
not. :)
 
It's the transfer rate of the SATA link between the drive's cache and
the controller, yes. What you're interested in, the *real-world*
benchmark, is the transfer rate off the platter, which is nowhere near
as fast.

Let's say you're loading a 100MB file. The drive has a 64MB cache, not
all of which will be available for caching reads. The drive can fill
the cache and transfers from that to the controller will be at 6Gbit/s
(about 580MBps), but once the cache is exhausted, the rest of the file
can only flow to the controller as fast as it comes off the platter,
which is about 160MB/s for a 5400rpm drive, and that's a maximum reading
from the outer edges of the platter. It'll be considerably slower
reading from the inner areas of the disk.

Even if you're loading a file small enough to fit entirely within the
drive's cache, there's read latency, access time and fragmentation to
consider. The OS has to read the file table and determine which sectors
on the drive constitute the full file, then the drive has to move the
heads to the right part of the disk (seek time) and wait for the
required sector to pass under the head (access time) then load them into
the cache. This latency means that in reality, even files which
theoretically would fit within the cache will not transfer at anything
like the full SATA interface speed.

SSDs don't suffer from this problem - they don't have mechanics to move
around to locate sectors, and so seek time and access time are to all
intents and purposes instant. That's why they are so much faster.
Click to expand...

Would the 6Gbs controller work better for a RAID since it may have to
handle more data being tossed at it by multiple drives at a higher rate? O_o

TDD
 
It's marketing. It says it has a 6Gbps interface, and that is provably
true, but it remains that the maximum transfer rate of the drive will
come nowhere near that.

There is one true fact listed that might benefit from a SATA3
interface: "SATA 6Gb/s interface optimizes burst performance"
But I doubt even the burst rate of a spinning drive will reach 3Gbps.
Click to expand...

If the disk has a nice big internal cache, it will for short bursts
with pre-fetched data, use the full speed of the sata link.
 
If the disk has a nice big internal cache, it will for short bursts
with pre-fetched data, use the full speed of the sata link.
Click to expand...

That's what I was assuming about the internal cache memory. Now I'm
wondering about the data rates of hybrid drives where the SSD is melded
with a mechanical disk drive. ^_^

TDD

TDD
 
Yes, and he also said "I bought a new hard drive with 6Gbps". We're
talking about his hard drive, not an SSD.
Click to expand...

I've seen people use "hard drive" to refer to a SSD.
 
Loren said:
26AWG is the wire size. That says very little about how fast they can
work. The 6gbs/3gbs marking is a clear indication that that's a SATA3
cable.
Click to expand...

26AWG means 26 American Wire Gauge. And has nothing to do with how
the wire works. Wire gauge might be important for maximum current
flow say, but for signal transmission, the currents aren't that
large.

The SATA cable is set up to have a characteristic impedance, which affects
how high frequency signals propagate. The location of the wire mates
(diff pair), the insulation material, position of shield or drain wire,
matter to the construction. Maybe you could change the wire gauge,
adjust the dimensions a bit, and it would still work. But more than
just the wire diameter would be a factor.

As far as I know, the intention was to use the same cables for both
SATA II and SATA III. A vendor extolling the virtues of a cable
they're selling, is selling FUD (feat uncertainty doubt).

I don't know if there is any difference in length spec for SATA III
or not. But I think they wanted to be able to use the same cables,
so there wouldn't have to be something distinctive on the cables
to tell them apart.

This is *not* how you test cables. You can use a digital storage scope
with eye diagram software, and get the real answer as to whether a
given setup is passing or failing. If the spec says the max cable
length is X, you don't make a 3X cable and test it. There is no point
to that. It's outside the spec. Maybe it gives an impression of the
margin available in the chip interfaces, but the eye diagram can
tell you much the same thing, without potentially screwing up an
SSD to prove it works.

http://www.maximumpc.com/article/fe..._down_your_data_transfers_max_pc_investigates

A SATA II eye diagram. Blue repetitive waveform, must not touch
the red colored pass/fail points. This example has plenty of
margin. Not likely to be any transmission errors here.

http://www.fujitsu.com/img/EDG/product/asic/ipmacro/sata-2.jpg

I couldn't find an eye diagram for SATA III, but this is a
device running at SATA III rates. And you can see the signal
is still clean. Amazingly clean actually, considering the
frequency.

http://www.maximintegrated.com/images/appnotes/4648/4648Fig05.gif

Paul
 
Metspitzer said:
I feel like Penny on the Big Bang Theory.

I know you think you are explaining this to me, but you are really
not. :)
Click to expand...

Data coming off the platter, inside the drive. We could represent
a transferred sector like this. The disk is relatively slow, compared
to the cabling.
__ __ __ __ __
__| |__| |__| |__| |__| |__

The transfer on the cable goes faster. The transfer takes less
time. Both diagrams are carrying the same amount of data.
_ _ _ _ _
_| |_| |_| |_| |_| |_

When you're reading data off the disk, the cable is so much
faster, the transfers are not continuous. This is what
happens on a read operation on a hard drive. The hard drive
cannot "keep the cable full", and the cable gets to "rest"
between bursts. The cable only transmits data, when enough
to "fill a packet" is available. SATA uses packets to transfer
data. The disk has sectors. The SATA cable has packets.
_ _ _ _ _ _ _ _ _ _
_| |_| |_| |_| |_| |_ _| |_| |_| |_| |_| |_

On a write, the host can send to the disk drive in a
continuous burst, at the high speed of the cable.
The drive cannot keep up. Eventually, the disk drive
RAM cache fills up. The cache is a temporary storage
area, meant to "take up the slack" between the fast
cable, and the slow hard drive.
_ _ _ _ _ _ _ _ _ _
_| |_| |_| |_| |_| |_| |_| |_| |_| |_| |_ . . .

When the cache is full on a write, the host can only send
new data when there is space in the cache. The transfer pattern
on the cable settles down, until it looks like the read
transfer diagram. Like this. The hard drive platter and
heads are pretty well running continuously while this
write operation is taking place (lower trace in the graph).
Notice that again, the 6Gbit/sec SATA cable gets to "rest"
between burst. And the bursts exist, because the cable
protocol is packet based, and not byte based.
_ _ _ _ _ _ _ _ _ _
_| |_| |_| |_| |_| |_ _| |_| |_| |_| |_| |_

__ __ __ __ __ __ __ __ __ __
__| |__| |__| |__| |__| |__| |__| |__| |__| |__| |__

Did I mention, I love ASCII art diagrams ? :-)

HTH,
Paul
 
Back
Top