This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

SATA performance

Other Parts Discussed in Thread: AM3894

I have been looking at the performance of the SATA drives on your developement board(816x/389xEVM rev G) because we need to be able to transfer a 2GB file from the SATA drive to memory as quick as possible.  I am currently measuring about 100MB/sec with the Micron 50GB drive that we are using for this project.  I also found a wiki page on the web (http://processors.wiki.ti.com/index.php/DM816x_C6A816x_AM389x_PSP_04.00.00.12_Feature_Performance_Guide#Performance_and_Benchmarks) that indicates similar type of performance with your processor(120MB/sec with the drive used in that test).  The data sheet indicates that you support 3Gb/sec on the SATA interface which is about 384MB/sec.  Do you know why there is such a difference between the published data rate and the actual data rate?  I know that you will not get the full amount but I would think that it would be better than what we are seeing.

  • Hi,

    Most of the drives that are available can not sustain that rate. There is a lot of flow control going in the middle of the transfer. What I have seen from my experience is that GEN2 drives do not give you that much better throughput as compared to GEN1 drives (at least the one manufactured last year or so).

    That said, there are many other factors lik O/S delay, application delay, Frame headers, etc that contributes to additional delay. You will be getting a higher throuhgput if you use an application that directly control the SATA controller and performs a sustained transfer.

    Best regards, Zegeye

  • Hi,

    Just to add on top of Zegeye's comment, also please check the sustained data rate published by the HDD manufactuer in the hard disk data sheet. This is usually in the vicinity of 140MBytes/sec.

    Regards

    Mansoor

  • Zegeye and Mansoor,

    Assuming the drive has a faster rated speed than ~150MB/s is there anything on the device/driver side that would limit throughput? For example Micron sells a SATA NAND Flash SSD which offers sequential read speeds of up to 360MB/s and write speeds up to 275MB/s, but when connected to the board speeds are not observed much above 100MB/s.

    This seems more likely a limitation of the device/driver than the hard drive.

  • Hi,

    I have heard of issues with SSD. I tried to get more info on this prior to sending this email but so far I am not getting any traction.

    Based on the test I have performed, by directly controling the controller, the limitation seemed to point to the target drive. I have passed well over 100MB and for read even higher than 150MB/S using GEN2 drive.

    Best regards, Zegeye

  • I am seeing a little over 225MB/s with this same drive on a PC that is running Linux with the standard SATA drivers.  So it must not be the drive that is the bottle neck.

  • Hi,

    Thanks. That is a good data to have. What I can think at this time is that it must be a newer drive than the one I tested on. This drive seems to be leveraging GEN2 speed which I was unable to do so (a bit with read).

    We might have to go back and take more throughput measurement.

    Thanks again and best regards, Zegeye

  • Hi Steve,

    Could you let us know if the HDD is Gen 3 (i.e. 6Gbps capable) and also if the SATA controller on the PC is Gen 3.

    Regards

    Mansoor

  • Mansoor,

     

    The HDD is Gen3 but the SATA controller on the PC is only Gen2.

     

    Thanks,

    Steve

  • Mansoor,

     

    I believe that I may have found the problem.  When I was doing the testing for the SATA read performance originally I had the Micron drive attached to the board via a port replicator.  This was the only way that I could get that drive to work on the demo board.   Before I contacted TI about the performance issue I tried a performance test on the PC with and without the port replicator and there was very little difference in the performance.  Then last week we got a new demo board which came with a newer version of the kernel and I found that the Micron drive could attach directly to the demo board.  So I discovered yesterday that if I do not use the port replicator to connect the I can get about 190MB/sec for a 2GB file.  I am not sure why I did not see a difference on the PC.  The problem now is that the demo board does not see the Micron drive every time it boots up.  It works only about 10% of the time.  If I use the port replicator it sees it every time.  The port replicator is a Thermaltake BlacxDuet. 

     

    Thanks for your help,

    Steve

  • Hi Steve,

    Thanks for letting us know. The data you are referring to is similar  to what I had. It is great to have a confirmation.

    Also, Linux performance and CCS performance are very close. This also asserts what I was referring at earlier post that the Device is the bottleneck. It seems that the devices have improved a lot (probably due to GEN3 support) but the issue still exist.

    Best regards, Zegeye

  • Hi Steve,

    Regarding the connection issue:

    Could you check if there are any Jumpers in SSD drive to force Gen 2 (that is 3Gbps)? If so, please use a Jumper and force the SSD to work in 3Gbps mode and then see if it is connecting consistently with the board. Also, let us know the speed at which it is connecting to the board without the Jumper (Linux bootlog should have this information).

    Regarding performance,

    The DM8168 throughput cannot be directly compared with the PC throughput numbers for various reasons. For example, a x86 PC would have 2MB or 4MB of L2/L3 cache and the processor itself will be running at a very high speed (2.5Ghz). Also, most of the PCs are multi-core. DM8168 has 256KB of L2 cache and the core operates at 1Ghz.

    The raw throughput numbers claimed by the drive manufacturer includes data throughput and SATA protocol handshake. Usually there is a huge overhead on the bus due to this handshake. Also, SATA uses 10B8B encoding. So for every 8-bit data, in the bus you should see 10-bit data. So, if we are achieving 100MBytes/sec it actually means 100MBytes/sec + 10B8B encoding overhead + SATA handshake overhead. This overhead will be at-least  20% on the actual data. Hence for 100MBytes/sec of data, on the bus it might ~125MBytes/sec.

    There are various other overheads apart for the above stated. For example, the filsystem uses metadata, there is a userspace to kernel space (and vice versa) copy involved in every read/write operation and then the data will be DMAed to the SATA controller. The userspace <-> kernel space copy operation is done by the CPU and it has to take care of Cache coherency. There is also a overhead due to interrupts and context switches in the operation system. Also, there are also various layers in the operating like userspace <-> Virtual File System <-> Actual File System <-> SCSI <-> ATA <-> AHCI <-> DMA. But the data itself is not copied in all cases (only pointers). So the operating system itself in a way is a overhead.

    Manufacturers do no consider all these overheads when they claim the RAW throughput.

    But given all these overheads, there are various ways by which the performance could be optimized. For example,  if a filesystem is used then you could try tuning some of the filesystem parameters to see if that improves the performance. But the problem with these kind of tuning is, we cannot come up with a single solution which will meet all customer usecase and end application. Hence we need to analyze the usecase and then need to work on the tuning.

    Hope this information helps. Please let us know if you need any clarification.

     

    Regards

    Mansoor

  • Mansoor,

     

    There are no jumpers on this drive. 

    When the drive is seen by the system it is connecting at 3 Gbps.

    Here is the dmesg dump from when it connects:

    ata1: SATA link down (SStatus 0 SControl 300)

    scsi host0: rpm_suspend flags 0x0

    scsi host0: rpm_suspend returns 0

    ata2: link is slow to respond, please be patient (ready=0)

    ata2: softreset failed (device not ready)

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

    ata2.00: ATA-9: P300-MTFDDAC050SAL, 0001, max UDMA/133

    ata2.00: 97696368 sectors, multi 1: LBA48 NCQ (depth 31/32)

    ata2.00: configured for UDMA/133

    scsi host1: rpm_suspend flags 0x0

    scsi host1: rpm_suspend returns 0

    scsi target1:0:0: rpm_resume flags 0x4

    scsi target1:0:0: rpm_resume returns -11

    scsi host1: rpm_resume flags 0x4

    scsi host1: rpm_resume returns 0

    scsi 1:0:0:0: Direct-Access     ATA      P300-MTFDDAC050S 0001 PQ: 0 ANSI: 5

    scsi target1:0:0: rpm_resume flags 0x4

    scsi target1:0:0: rpm_resume returns 1

    scsi 1:0:0:0: rpm_resume flags 0x0

    scsi 1:0:0:0: rpm_resume returns -11

    scsi 1:0:0:0: rpm_resume flags 0x4

    scsi 1:0:0:0: rpm_resume returns 1

    sd 1:0:0:0: Attached scsi generic sg0 type 0

    sd 1:0:0:0: [sda] 97696368 512-byte logical blocks: (50.0 GB/46.5 GiB)

    sd 1:0:0:0: [sda] Write Protect is off

    sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00

    sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA

    sd 1:0:0:0: rpm_resume flags 0x4

    sd 1:0:0:0: rpm_resume returns 1

     sda: sda1 sda2

    sd 1:0:0:0: [sda] Attached SCSI disk

    Here is the dmesg dump from the same area when the drive is not seen:

    ata1: SATA link down (SStatus 0 SControl 300)

    scsi host0: rpm_suspend flags 0x0

    scsi host0: rpm_suspend returns 0

    ata2: SATA link down (SStatus 1 SControl 300)

    scsi host1: rpm_suspend flags 0x0

    scsi host1: rpm_suspend returns 0

     

    Thanks,

    Steve

     

  • Hi,

    The above dump is more meaningful for the Driver guys. I will request one of them to take a look at it.

    My understanding is that you are having a Link Establishment issue. We have done compliance test and our OOB tests are passing. Not sure as to why you are having this problem. Do you have a bus activity capture that you can send us? It is very hard to diagnosize the issue with out any data.

    Best regards, Zegeye

     

  • Hi,

    Sorry for the spam. One more question. What is the max speed supported by the SSD?

    Thanks and best regards,

    Zegeye

  • The max speed of the SSD is 6Gbps.   We do not currently have a sata bus analyzer so we have not been able to capture any data from the h/w.

  • Hi Steve,

    Thanks. Is your device the OMAPL1x device or DM814x device? If it is any of the two, then we have a problem. Our device gets confiused with the 6Gbits/Sec line speed due to aliasing and interpreting it as 3Gbits/Sec causing our device to complete the speed negotiation while the target is on its initial phase of speed negotiation making the two to be out of sync.

    Best regards, Zegeye

  • Zegeye,

     

    We are using the DM816x/AM3894 processor.  Is there an issue with this one?

     

    Thanks,

    Steve

  • Hi Steve,

    This device has a 5Gbits/Sec PHY. The other devices have a 3Gbits/Sec PHY. This device was not affected and correctly deciphering the 6Gbits/Sec signal and not responding to it.

    I will need to confirm with the PHY guys if that is good enough to cause an issue with your setup.

    Best regards,

    Zegeye