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.

TDA4VH-Q1: PCIe X4 write/read performance problem between EP and RC.

Part Number: TDA4VH-Q1
Other Parts Discussed in Thread: TDA4VH

Hi,

We face a PCIe write/read performance problem as below, and want to make sure the TDA4VH performance SPEC firstly.

Our test environment and result is as below, and we suppose, maybe for PCIe X4, it should be over 3GB/s.

HW: RC + EP, connected with PCIe X4

SW: pcitest.sh and read EP kernel log for result(KB/s).

No.

Test Case

Size(Bytes)

Without DMA

With DMA

1

Write Test

1

2244

16

2

 

1024

231213

14757

3

 

1025

251501

16024

4

 

1024000

206962

335590

5

 

1024001

207684

344946

6

Read Test

1

712

14

7

 

1024

6705

13657

8

 

1025

6779

13772

9

 

1024000

6729

73666

10

 

1024001

6766

73503

11

Copy Test

1

309

14

12

 

1024

6474

13400

13

 

1025

6493

13420

14

 

1024000

6527

73448

15

 

1024001

6531

73345

 

  • Hi Xiaojuan,

    If you are using the 9.0/9.1 SDK, there is a known issue with performance, where DMA does not get correctly initialized when using the EP example. I would recommend switching back to 8.6 SDK to get a better feel for performance. When I was testing 8.6 version of the SDK for TDA4VH, I was seeing around 2.2GB/s.

    Regards,

    Takuma

  • Hi Takuma,

    We test  with SDK 8.5,and the result is as below. Please help to check whether it is a normal result.

    Thank you.

    No. Test Case Data Size SDK 9.0
    (without DMA)
    SDK 9.0
    (with DMA)
    SDK 8.5
    (without DMA)
    SDK 8.5(with DMA)
    1 Write 1 2244 16 10850 9
    2   1024 231213 14757 287769 16123
    3   1025 251501 16024 290559 16191
    4   1024000 206962 335590 210848 2032251
    5   1024001 207684 344946 208398 2026672
    6 Read 1 712 14 710 16
    7   1024 6705 13657 6913 15157
    8   1025 6779 13772 6808 16112
    9   1024000 6729 73666 6760 727214
    10   1024001 6777 73503 6776 727675
    11 Copy 1 309 14 350 15
    12   1024 6474 13400 6604 15411
    13   1025 6493 13420 6480 15508
    14   1024000 6527 73448 6532 634711
    15   1024001 6531 73345 6509 637686
  • Hi Xiaojuan,

    Could you do an experiment with a NVMe SSD card and using the FIO tool to do some data transfer? Goal of this is to see if there are issues with the software/hardware configuration on the RC-side, or if there is an issue only on the EP-side.

    The full command will look something like:

    • fio --name=/run/media/nvme0n1/test-pcie-1 --size=10GB --ioengine=libaio --iodepth=4 --numjobs=1 --direct=1 --runtime=60 --time_based --bs=4M

    Please note that the --name should be changed to the SSD card name/location within the filesystem.

    If this also shows a low transfer rate in the 300MB/s range, then the issue would be with RC. If this shows the expected 2GB/s range of performance, then issue would be on the EP-side or a issue with setting up the EP/RC example.

    Regards,

    Takuma

  • Hi Takuma,

    I am afraid I didn't write my question clearly, please check whether SDK 8.5 result is just as your SPEC.

    It seems nearly 2GB/s now. And please also help to check read speed.

    If it is normal, we can continue to do the next work.

    Thank you.

  • Hi Xiaojuan,

    Yes, around 2GB/s is expected. SDK 8.5 and 8.6 should be operating at what the expected performance is.

    Regards,

    Takuma

  • Hi Takuma,

    I have 3 more questions 

    1. Why read speed is just 1/3 as write speed?

    2. Why when data size is smaller, with DMA result is worse than without DMA?

    3. And when will you solve DMA problem on SDK 9.x? Is there any plan?

    Thank you.

  • Hi Xiaojuan,

    1. Why read speed is just 1/3 as write speed?

    Read speed should not be 1/3 of write speed - this is an anomaly. As an experiment, you could try read/write using SSD as an endpoint. This should automatically link to the nvme kernel module instead of the pci endpoint kernel module, and this should give you a better estimate of what read/write performance should be.

    2. Why when data size is smaller, with DMA result is worse than without DMA?

    This is most likely due to overhead that comes from initialization of DMA. For smaller data size, the time it takes to initialize DMA is significant enough to make an impact on performance. But, for larger data size, this overhead is averaged out.

    3. And when will you solve DMA problem on SDK 9.x? Is there any plan?

    Current plan is SDK 10.0. However, I am working with our SDK team to see if we can accelerate the debug effort.

    Regards,

    Takuma