• State TI Thinks Resolved
  • Locked Locked
  • Replies 6 replies
  • Answers 2 answers
  • Subscribers 97 subscribers
  • Views 412 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

SK-TDA4VM: SK-TDA4VM: qbu performance

Zhao Huijun
Prodigy 25 points

Part Number: SK-TDA4VM
Other Parts Discussed in Thread: TDA4VM

1.HI,We tested the performance of qbu, such as message latency。

2.We compare the delay of receiving and sending high priority messages，when the qbu is enabled and not enabled.

3.We found that,after the qbu is enabled, the delay is not greatly improved.

4.We send data through iperf, and at the same time we send data through sockets in user space,like this:

iperf3 -c 192.168.100.20 -u -b500M -l1472 -t300

iperf3 -s

It mapped to queue 0.

5.And ethtool -l eth0 like this:

    

6.Then we send data through sockets in user space with priority 3,result like this:

gap1 is the delay of receiving and sending high priority messages.

7.Without qbu,the result is like this:

8.After the qbu is enabled, the delay is not greatly improved.

  Can you tell me why is this result?

  • 0
    TI__Mastermind 43830 points

    Hi,

    Qbu (Mentioned as IET in out documentation) is observed in specific type of bandwidth combination between high priority and low priority traffic. This page here explains the usage of IET on TDA4VM (The J7VCL and TDA4VM are same for this purpose). Please go through it and mention your questions here.

    Regards,
    Tanmay

  • 0 in reply to Tanmay Patil
    Prodigy 25 points

    Yes，we follow this usage of IET on TDA4VM ,and we get result like this:

    On AM64-SK (Receiver):

    root@am64xx-evm:~# ethtool -S eth0 | grep iet
     iet_rx_assembly_err: 0
     iet_rx_assembly_ok: 148
     iet_rx_smd_err: 109
     iet_rx_frag: 212
     iet_tx_hold: 0
     iet_tx_frag: 0

    But based on our understanding,as the high priority traffic preempts,the delay of receiving and sending messages should be improved.
    And then we found that this performance is not greatly improved.
  • 0 in reply to Zhao Huijun
    TI__Mastermind 43830 points

    Hi,

    As you see, you only needed to preempt 212 packets for a 300s transmission (iet_rx_frag). So the actual difference will be observed in these 212 packets only and not affect the rest of the transmission. This amount of change might not substantial and will often be not detected. Hence the observed improvements depend on bandwidth of both priority data and at other times you can see almost no change in latency. Hence the observed improvement depends on the test case.

    I also wanted to confirm, is this thread duplicate for this thread.

    Regards,
    Tanmay

  • 0 in reply to Tanmay Patil
    Prodigy 25 points

    Thanks！I understand what you mean.

    And then , how can I test the change of latency?

    I also wanted to confirm, is this thread duplicate for this thread.  --No.

  • 0 in reply to Zhao Huijun
    TI__Mastermind 43830 points

    Hi,

    Sorry for the delayed response.

    Zhao Huijun said:
    And then , how can I test the change of latency?

    As it depends on the background traffic bandwidth, by making the background bandwidth as high as possible, you should ideally be able to observe the effects. As you are using iperf, you can use -b0 flag to maximise the background data throughput.

    But the thing to note here would be that we haven't actually checked for improvement in latency for this. For us, what we place importance is that the high priority packet is serviced by express MAC and low priority packet is pre-empted. As long as this is observed, we can guarantee QoS. Hence, we don't have any latency test for IET.

    Regards,
    Tanmay