SATA 3 disk being driven at 3Gbps rather than 6.

Story: How to measure the speed of SATA devices from the command line on LinuxTotal Replies: 9
Author Content

Apr 04, 2013
9:26 AM EDT
So, inspired by this article, I did some poking (ok, peeking really):

$ dmesg | grep -i sata ... [ 4.528764] ata2: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 4.528784] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

Right. One DVD drive, one rather gnarly HD. Yet this is just the boot. What about the running status?

As suggested in the comments....

$ cat /sys/class/ata_link/link?/sata_spd 1.5 Gbps 3.0 Gbps

Would I be correct that my SATA-3 disk is being driven at SATA-2 speeds?

Apr 04, 2013
10:07 AM EDT
I am seeing a similar discrepancy on my ultrabook's ssd drive.

dmesg | grep -i sata shows 6.0 Gbps

cat sata_spd shows 3.0 Gbps

Since both of those information sources originate from the same source (kernel), I would expect the information to be consistent. I am not sure how to interpret the apparent discrepancy.

Any kernel hackers reading this thread?

Apr 04, 2013
10:44 PM EDT
I got the same thing from the dmesg and cat commands. I tried hdparm -tT /dev/sda and got: /dev/sda: Timing cached reads: 19816 MB in 2.00 seconds = 9920.16 MB/sec Timing buffered disk reads: 796 MB in 3.00 seconds = 265.13 MB/sec

The 265 MBs seems to fit in with the SATA 2 speed. It does appear that the SATA 3 devices are being held back or something.

Apr 05, 2013
1:44 AM EDT
What's actually being identified -- the devices, or the controllers?

Apr 05, 2013
4:17 PM EDT
Also, check that Native Command Queueing (NCQ) is enabled or disabled. If it's disabled on boot, chances are you have a blacklisted (buggy) chipset.

Apr 08, 2013
8:48 AM EDT
Gus, do you have a quick and dirty command to do that, or should I look it up? :^)


$ cat /sys/block/sda/device/queue_depth



Apr 08, 2013
4:14 PM EDT
That's a good start. I did:

$ dmesg | grep NCQ

to find out my chipset's NCQ support was buggy, therefore disabled.

Apr 08, 2013
4:44 PM EDT

How did doing that tell you the chipset was buggy?

$ dmesg | grep NCQ

[ 4.530851] ata2.00: 976773168 sectors, multi 16: LBA48 NCQ (depth 31/32), AA


Apr 08, 2013
4:49 PM EDT
It told me NCQ was disabled. My chipset is blacklisted as "buggy" in the source code.

I tried removing it from the blacklist, and NCQ became enabled, but the performance difference wasn't worth the risk of massive data loss.

Apr 08, 2013
4:53 PM EDT
Ok. I just haven't seen any comparison to know what NCQ "bad" looks like.

I should log into my friend's system in California... or not.. :^)

Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]

Becoming a member of LXer is easy and free. Join Us!