# Poor SATA hard drive/controller performance [SOLVED]

## paulbiz

Hi,

I recently built a new computer with SATA hard drives and much faster CPU, RAM & motherboard to replace an old P4 2.8ghz with IDE disks. 

I have 6 SATA devices. A Maxtor HDD as my boot/root drive, and a DVD-RW attached to sata_sil24 driver, and four Samsung HDDs attached in raid5 mdraid to sata_nv driver.

When heavy disk activity happens on the Maxtor drive, it literally blocks all other activity, causing huge delays in waiting for disk I/O from this drive. The other drives seem to be unaffected, only the Maxtor is blocked.

dmesg only id's the Maxtor as 1.5Gbps link, but it is supposed to be 3.0. (I have not tried attaching a different drive in its place, though I have a spare Samsung for the raid5 that I may give a shot as boot drive when I have some time.)

Do you think it is the sata_sil24 driver/controller causing this, or the drive itself? My old computer easily outperformed the new one on responsiveness during heavy disk activity, and that is very frustrating!

Thanks.Last edited by paulbiz on Mon Oct 15, 2007 11:36 pm; edited 1 time in total

----------

## gregf

I hope this does not seem insulting but are you using a Sata II (3gbps) cable? Since they look identical maybe you just did not realize. The reason I mention this is I built a new system with a motherboard that supported Sata II drives and bought a nice shiny Sata II drive to go with it. I noticed It was not nearly as fast as it should be myself. Then when looking into it one day found out the cables that my motherboard came with were only rated for Sata I. So if your lucky or unlucky depending on how you look at it, the problem maybe as simple as that. Just a thought. Other than that I'm not really sure myself. Hope it works out though.

----------

## Monkeh

 *gregf wrote:*   

> I hope this does not seem insulting but are you using a Sata II (3gbps) cable? Since they look identical maybe you just did not realize. The reason I mention this is I built a new system with a motherboard that supported Sata II drives and bought a nice shiny Sata II drive to go with it. I noticed It was not nearly as fast as it should be myself. Then when looking into it one day found out the cables that my motherboard came with were only rated for Sata I. So if your lucky or unlucky depending on how you look at it, the problem maybe as simple as that. Just a thought. Other than that I'm not really sure myself. Hope it works out though.

 

No single drive is capable of 1.5Gbps anyway..

----------

## NeddySeagoon

paulbiz,

I would not expect to see any change in single hard drive performance between your old system and you new one as the limiting factor has been the drives head/platter data rate for a long time now. Thats about 50Mb/sec at the outside of the platter for a 7200 rpm drive, falling as the head moves towards the spindle.

50Mb/sec is well within the 1.5Gbit/sec of any SATA link, so thats not your problem, unless the data link has a very high error rate and you are getting lots of retries. You can use 

```
hdparm -tT /dev/sd....
```

for a crude speed test.

----------

## paulbiz

Hi,

I was not as clear as I should have been about the "performance" I'm worried about. It's not the raw Mb/sec rate, and I surely do not expect 3.0 (or even 1.5) Gbps disk speeds, but the fact that any heavy disk activity involving writes causes the system to lockup is my problem. I was only mentioning the 1.5 vs 3.0 because the drive is supposed to be 3.0 and perhaps it was indicative of a bigger problem.

The performance issue is that disk reads, mouse clicks, etc do not register until the disk activity is finished (on that one drive only), writing data is especially at fault for causing this. During this time, the "wa" (I/O wait) time in "top" is at 99-100%. On my old slow computer, which was using old IDE drives and a $30 motherboard, I was able to do heavy disk activities without any noticeable impact, but which seemingly bring the new system to its knees.

As far as the cables, it has always been my understanding that labeling of cables as "sata ii" or "300MB/sec" are just a marketing ploy (usually to go along with locking and/or angled connectors), and that a sata cable is a sata cable is a sata cable. I have no expert knowledge to prove that, though, so I could have been misled by the information I found on Google that day. Anyway, I am using identical cables for all of the drives... however, I've got a different set I will try when I get a chance. It can't hurt to try!

Thanks for the suggestions. I appreciate your help!

Here is hdparm results against the "bad" drive:

```
/dev/sda6:

 Timing cached reads:   9118 MB in  2.00 seconds = 4563.52 MB/sec

 Timing buffered disk reads:  172 MB in  3.02 seconds =  56.90 MB/sec
```

Same test against one of the "good" drives:

```
/dev/sdb1:

 Timing cached reads:   9472 MB in  2.00 seconds = 4740.80 MB/sec

 Timing buffered disk reads:  226 MB in  3.02 seconds =  74.78 MB/sec
```

And those speeds look great. However, since it appears to only be doing reads, I don't think it is triggering my problem. If I copy a 2 gig file to that drive, most UI I/O and all disk I/O on that drive seems to be blocked for the length of the time it takes the disk to write the data... maybe 15 or 30 seconds? I have not timed it.

The motherboard is Abit IN9 32X-MAX, and I'm using Gentoo x86_64 and 2.6.23 gentoo-sources kernel. The Silicon Image 3132-based controller is the one the "bad" drive is attached to. The only other device on this controller is the DVD-RW drive. (It also has two eSATA ports, but I've never tried them.) The four well-behaved drives are attached to the NForce-based controller. All are built-in to the motherboard, none are add-in controller cards.

Here is my lspci:

```
00:00.0 Host bridge: nVidia Corporation C55 Host Bridge (rev a2)

00:00.1 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)

00:00.2 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)

00:00.3 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)

00:00.4 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)

00:00.5 RAM memory: nVidia Corporation C55 Memory Controller (rev a2)

00:00.6 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)

00:00.7 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)

00:01.0 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)

00:01.1 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)

00:01.2 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)

00:01.3 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)

00:01.4 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)

00:01.5 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)

00:01.6 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)

00:02.0 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)

00:02.1 RAM memory: nVidia Corporation Unknown device 03bc (rev a1)

00:02.2 RAM memory: nVidia Corporation C55 Memory Controller (rev a1)

00:03.0 PCI bridge: nVidia Corporation C55 PCI Express bridge (rev a1)

00:06.0 PCI bridge: nVidia Corporation C55 PCI Express bridge (rev a1)

00:09.0 RAM memory: nVidia Corporation MCP55 Memory Controller (rev a1)

00:0a.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2)

00:0a.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2)

00:0b.0 USB Controller: nVidia Corporation MCP55 USB Controller (rev a1)

00:0b.1 USB Controller: nVidia Corporation MCP55 USB Controller (rev a2)

00:0d.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1)

00:0e.0 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2)

00:0e.1 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2)

00:0e.2 IDE interface: nVidia Corporation MCP55 SATA Controller (rev a2)

00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev a2)

00:0f.1 Audio device: nVidia Corporation MCP55 High Definition Audio (rev a2)

00:11.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2)

00:12.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2)

00:16.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge (rev a2)

01:00.0 VGA compatible controller: nVidia Corporation Unknown device 0421 (rev a1)

02:00.0 Mass storage controller: Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller (rev 01)

03:08.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)

04:00.0 Ethernet controller: Atheros Communications, Inc. AR5006EG 802.11 b/g Wireless PCI Express Adapter (rev 01)
```

----------

## NeddySeagoon

paulbiz,

There is nothing out of the ordinary with your lspci. The fact that it works at all, shows the SATA part of the kernel setup is ok.

Are there any errors in dmesg after you have observed the lock ?

What preemption options do you ahve set in the kernel ?

```
$ grep PREE /usr/src/linux/.config

# CONFIG_PREEMPT_NONE is not set

# CONFIG_PREEMPT_VOLUNTARY is not set

CONFIG_PREEMPT=y

CONFIG_PREEMPT_BKL=y

# CONFIG_DEBUG_PREEMPT is not set
```

shows what you intended to set and 

```
zgrep PREE /proc/config.gz
```

will show how the running kernel was compiled, if you have a /proc/config.gz

My settings are good for a desktop.

When you write big files, a lot of RAM can be used as a buffer. These 'dirty' buffers cannot be swapped, where is the point in writing them to the wrong place, which can force the system into swapping things you are using. Look at top and watch swap activity while you do a test.  Start top beforehand.

----------

## PaulBredbury

 *paulbiz wrote:*   

> involving writes causes the system to lockup

 

Try commit=60.

----------

## overkll

Just curious...

What is the chunk size of your raid5 array?

What filesystem are you using?

----------

## paulbiz

 *NeddySeagoon wrote:*   

> Are there any errors in dmesg after you have observed the lock ?

 None.

 *NeddySeagoon wrote:*   

> What preemption options do you ahve set in the kernel ?

 In menuconfig, I chose "Voluntary Kernel Preemption (Desktop)" which gives me:

```
# CONFIG_PREEMPT_NONE is not set

CONFIG_PREEMPT_VOLUNTARY=y

# CONFIG_PREEMPT is not set

CONFIG_PREEMPT_BKL=y
```

(I don't have a /proc/config.gz, but /boot/config matches the above)

 *NeddySeagoon wrote:*   

> When you write big files, a lot of RAM can be used as a buffer. These 'dirty' buffers cannot be swapped, where is the point in writing them to the wrong place, which can force the system into swapping things you are using. Look at top and watch swap activity while you do a test.  Start top beforehand.

 I have 4 gigs of RAM, so my swap partition pretty much never gets hit, as far as I've ever seen. I suppose I could try to 'swapoff' and see if it makes a difference.

 *PaulBredbury wrote:*   

> Try commit=60.

 I will give it a go with my next reboot. It looks promising!

 *overkll wrote:*   

> Just curious...
> 
> What is the chunk size of your raid5 array?
> 
> What filesystem are you using?

 The raid5 is behaving fine, and the drive in question is not a part of the array. Anyhow, my filesystem in both the root and raid disks is ext3 and here is my /proc/mdstat:

```
Personalities : [linear] [raid0] [raid1] [raid10] [raid6] [raid5] [raid4] [multipath] [faulty]

md0 : active raid5 sde1[3] sdd1[2] sdc1[1] sdb1[0]

      1465151808 blocks level 5, 64k chunk, algorithm 2 [4/4] [UUUU]

unused devices: <none>
```

Thanks again for your ideas, I'll try them and report back.

----------

## dmpogo

Regarding 1.5 versus 3.0 link - what does dmesg exactly says about it ?  Also hdparm -I /dev/sda ?

----------

## paulbiz

 *PaulBredbury wrote:*   

>  *paulbiz wrote:*   involving writes causes the system to lockup 
> 
> Try commit=60.

 I just added this to my fstab and rebooted. It seems to have made a real difference! I tried a program that was giving me big problems before (downloading USENET headers with BNR2) and it worked beautifully, just like it used to on my old computer. Until now, when I would try to download headers on this computer, the disk writes would so overwhelm it that the connections to the server would actually timeout due to several minutes of inactivity while it waited for the disk writes to finish. (The program is by far not very efficient in its disk writes...). Previously, it would take around 15-20 minutes to download the headers. This time it took less than 2!

When I copied a few large files (totaling ~2gb) it still exhibited the same blocking behavior, but after a longer period of time (60 seconds as defined in fstab, I suppose).

I googled about ext3 commit option, and in the original patch there is a mention about changing /proc/sys/vm/dirty_writeback_centisecs to a different value. I also find there is a related setting in /proc/sys/vm/dirty_expire_centisecs -- do you know anything about those or have any recommendation? Should they be set to the equivalent amount of time as the ext3 commit option?

 *dmpogo wrote:*   

> Regarding 1.5 versus 3.0 link - what does dmesg exactly says about it ? Also hdparm -I /dev/sda ?

 dmesg | grep ata3:

```
ata3: SATA max UDMA/133 cmd 0x00000000000109f0 ctl 0x0000000000010bf2 bmdma 0x000000000001f700 irq 23

ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 300)

ata3.00: ATA-7: MAXTOR STM3320820AS, 3.AAE, max UDMA/133

ata3.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/32)

ata3.00: configured for UDMA/133
```

'hdparm -I /dev/sda' makes no mention of SATA II or 3.0Gbps:

```
/dev/sda:

ATA device, with non-removable media

        Model Number:       MAXTOR STM3320820AS

        Serial Number:      5QF17TRZ

        Firmware Revision:  3.AAE

Standards:

        Supported: 7 6 5 4

        Likely used: 7

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:  625142448

        device size with M = 1024*1024:      305245 MBytes

        device size with M = 1000*1000:      320072 MBytes (320 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: 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=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

           *    DOWNLOAD_MICROCODE

                SET_MAX security extension

           *    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

           *    SATA-I signaling speed (1.5Gb/s)

           *    Native Command Queueing (NCQ)

           *    Phy event counters

                Device-initiated interface power management

           *    Software settings preservation

Security:

        Master password revision code = 65534

                supported

        not     enabled

        not     locked

        not     frozen

        not     expired: security count

        not     supported: enhanced erase

Checksum: correct
```

----------

## 96140

--Last edited by 96140 on Fri Sep 13, 2013 9:00 am; edited 1 time in total

----------

## paulbiz

 *nightmorph wrote:*   

> As far as the hardware goes, take a look at the data connectors on the drives themselves. On my Seagate drives, and I think on my Samsung, there was a tiny, tiny little jumper set way back on two of the pins. Almost impossible to see. Turns out it comes from the factory like that, and that jumper had to be removed to enable SATAII speeds. Dumb, but there it was. Grabbed some needlenose pliers, popped it off, put the drives back in, rebooted, and presto, SATAII connections all the way around.

 Sure enough, I'm reading the manual online and there is a jumper block to limit it to 1.5 Gbps. Jumpered=1.5, jumperless=3.0. I'll have to open the case to check the drive for it.

----------

## paulbiz

Genius! There was a jumper, a tiny jumper. It was kind of sunken into the pins, and not visible from an angle. I had to use tweezers to remove it. Why on earth would that be the default jumper position? Anyway, it now shows up at 3.0 Gbps   :Very Happy: 

```
ata3: SATA max UDMA/133 cmd 0x00000000000109f0 ctl 0x0000000000010bf2 bmdma 0x000000000001f700 irq 23

ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)

ata3.00: ATA-7: MAXTOR STM3320820AS, 3.AAE, max UDMA/133

ata3.00: 625142448 sectors, multi 16: LBA48 NCQ (depth 0/32)

ata3.00: configured for UDMA/133
```

```
/dev/sda:

ATA device, with non-removable media

        Model Number:       MAXTOR STM3320820AS

        Serial Number:      5QF17TRZ

        Firmware Revision:  3.AAE

Standards:

        Supported: 7 6 5 4

        Likely used: 7

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:  625142448

        device size with M = 1024*1024:      305245 MBytes

        device size with M = 1000*1000:      320072 MBytes (320 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: 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=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

           *    DOWNLOAD_MICROCODE

                SET_MAX security extension

           *    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

           *    SATA-I signaling speed (1.5Gb/s)

           *    SATA-II signaling speed (3.0Gb/s)

           *    Native Command Queueing (NCQ)

           *    Phy event counters

                Device-initiated interface power management

           *    Software settings preservation

Security:

        Master password revision code = 65534

                supported

        not     enabled

        not     locked

        not     frozen

        not     expired: security count

        not     supported: enhanced erase

Checksum: correct
```

----------

## dmpogo

 *paulbiz wrote:*   

>  *nightmorph wrote:*   As far as the hardware goes, take a look at the data connectors on the drives themselves. On my Seagate drives, and I think on my Samsung, there was a tiny, tiny little jumper set way back on two of the pins. Almost impossible to see. Turns out it comes from the factory like that, and that jumper had to be removed to enable SATAII speeds. Dumb, but there it was. Grabbed some needlenose pliers, popped it off, put the drives back in, rebooted, and presto, SATAII connections all the way around. Sure enough, I'm reading the manual online and there is a jumper block to limit it to 1.5 Gbps. Jumpered=1.5, jumperless=3.0. I'll have to open the case to check the drive for it.

 

I bet it is on, because where is the jumper piece otherwise   :Very Happy:   ?

----------

## Pajarico

Could you post an hdparm test like the one above for comparison?

----------

## 96140

--Last edited by 96140 on Fri Sep 13, 2013 9:00 am; edited 1 time in total

----------

## Monkeh

 *nightmorph wrote:*   

>  *paulbiz wrote:*   Genius! There was a jumper, a tiny jumper. It was kind of sunken into the pins, and not visible from an angle. I had to use tweezers to remove it. Why on earth would that be the default jumper position? Anyway, it now shows up at 3.0 Gbps   
> 
> I told ya! 
> 
> Makes sense that a Maxtor drive would have it -- Seagate drives do, and Seagate bought out Maxtor some time ago. Still dumb that it ships with it on, though.
> ...

 

They ship with them on because of totally broken VIA SATA controllers.

----------

## paulbiz

 *Pajarico wrote:*   

> Could you post an hdparm test like the one above for comparison?

 

Sure... the results are basically the same as with the 1.5 Gbps jumper on:

```
/dev/sda6:

 Timing cached reads:   9894 MB in  2.00 seconds = 4952.46 MB/sec

 Timing buffered disk reads:  172 MB in  3.02 seconds =  56.88 MB/sec
```

With regard to the commit=60 setting, is it generally safe to set it to a larger number? One of the gentoo wiki pages suggesting setting it to 10 minutes. From what I can tell, it doesn't wait that long to write the data to disk, in fact it seems to start more or less immediately, but I guess it waits that long before it HAS to write the data to disk (taking priority over other disk activities). Is my understanding correct?

Nightmorph, I think my Maxtor is basically a Seagate. The same exact product number appears to be sold under both brand names. I think the only difference is the length of warranty.

Thanks for all your help.

----------

## dmpogo

 *nightmorph wrote:*   

>  *paulbiz wrote:*   Genius! There was a jumper, a tiny jumper. It was kind of sunken into the pins, and not visible from an angle. I had to use tweezers to remove it. Why on earth would that be the default jumper position? Anyway, it now shows up at 3.0 Gbps   
> 
> I told ya! 
> 
> Makes sense that a Maxtor drive would have it -- Seagate drives do, and Seagate bought out Maxtor some time ago. Still dumb that it ships with it on, though.
> ...

 

One sec, did it solve the desktop freezing while disk is active ?

----------

## paulbiz

 *dmpogo wrote:*   

>  *nightmorph wrote:*    *paulbiz wrote:*   Genius! There was a jumper, a tiny jumper. It was kind of sunken into the pins, and not visible from an angle. I had to use tweezers to remove it. Why on earth would that be the default jumper position? Anyway, it now shows up at 3.0 Gbps   
> 
> I told ya! 
> 
> Makes sense that a Maxtor drive would have it -- Seagate drives do, and Seagate bought out Maxtor some time ago. Still dumb that it ships with it on, though.
> ...

 

The 1.5 Gbps vs 3.0 Gbps had no impact whatsoever on performance or the freezing problem, but at least it is detected as SATA 300 now instead of SATA 150.

The freezing while disk is active seems to have been helped a lot -- though not completely eliminated -- by adding commit=60 to my ext3 mount options. Enough that the problem is only evident when I'm dealing with a very large disk write... and the problem may be worsened by the fact I have 4 gigs of RAM, most of which is available for buffer/cache usage. I think if I make that 60 a larger number (I'm thinking 300) it will help even more. I'm about to try it  :Smile: 

----------

## paulbiz

Well, increasing the commit time didn't help... When copying large files it still blocks the UI. It's good for a few seconds, then becomes unresponsive until the write is done. (For this test, I copied 2 gigs of files to /dev/shm, did a sync, then copied them to the hard drive and tried doing other things while that happened)

However, for the normal activity that used to cause problems, it seems to have helped (as mentioned before). I will leave it as [SOLVED] but I think there is still room for improvement  :Smile: 

----------

## paulbiz

Well, apparently I can't post images here, but here is a link to a picture of the tiny jumper that was on the HDD:

img_3007.jpg

----------

## Pajarico

Well, if your problem is an I/O problem -I mean at the SATA bus level- you might want to check the kernel log for messages about time issues and tell me if you have noticed a clock skew. I have had a similar problem albeit with unrelated hardware (a PATA DVD drive) which was unbearably slow during heavy disc access. The problem was that I had a generic driver for PATA and another specific driver which wasn't the proper one. 

PS: I expected better results with 3.0, is it a marketing ploy?

----------

## dmpogo

 *paulbiz wrote:*   

> Well, increasing the commit time didn't help... When copying large files it still blocks the UI. It's good for a few seconds, then becomes unresponsive until the write is done. (For this test, I copied 2 gigs of files to /dev/shm, did a sync, then copied them to the hard drive and tried doing other things while that happened)
> 
> However, for the normal activity that used to cause problems, it seems to have helped (as mentioned before). I will leave it as [SOLVED] but I think there is still room for improvement 

 

I would have not marked it as solved yet. One issue which you may hit later, since you have optical drive is on the same controller,  is if it will block the UI while burning DVD's. That will be a major pain.

----------

## dmpogo

 *Pajarico wrote:*   

> 
> 
> PS: I expected better results with 3.0, is it a marketing ploy?

 

It is not, it is just current consumer hard-drives do not max the capabilities of SATA 3.0 connection. The bottleneck is elsewere.

----------

