E310: Streaming performance regression on 4.0.0.0

[RGerzaguet]

Hello everyone,

I have some e310 devices (sg3) with UHD 3.9 on it (UHD_003.009.002-0-unknown). The behavior is fine and if I try to benchmark the receiver performance, I get the following performance results

root@ettus-e3xx-sg3-rose1:/usr/lib/uhd/examples# ./benchmark_rate --rx_rate 8e6
linux; GNU C++ version 4.9.2; Boost_105700; UHD_003.009.002-0-unknown
...
Testing receive rate 8.000000 Msps on 1 channels

Benchmark rate summary:
  Num received samples:    79993744
  Num dropped samples:     0
  Num overflows detected:  0
  Num transmitted samples: 0
  Num sequence errors:     0
  Num underflows detected: 0

I have upgraded the e310 device recently on UHD4.0.0 with the new SD image and if I redo the same benchmark, I get this

oot@ni-e31x-3150CBB:/usr/lib/uhd/examples# ./benchmark_rate --rx_rate 8e6 

[INFO] [UHD] linux; GNU C++ version 9.2.0; Boost_107100; UHD_4.0.0.0-0-g90ce6062
....
Benchmark rate summary:
  Num received samples:     5930340
  Num dropped samples:      74754467
  Num overruns detected:    79
  Num transmitted samples:  0
  Num sequence errors (Tx): 0
  Num sequence errors (Rx): 0
  Num underruns detected:   0
  Num late commands:        0
  Num timeouts (Tx):        0
  Num timeouts (Rx):        42

It seems that the e310 devices does not allow more than 4MHz Rampling on the arm, contrary to the 11.9MHz obtained with UHD3. The results are aligned with the green blinking LED that shows that a lot of Rx samples are dropped. This is not a normal behavior any advices or clues would be greatly appreciated. BR

[michael-west]

@RGerzaguet Thank you for reporting this. We have opened an internal issue for further investigation.

There has been a significant architecture change in the software for the E310 between 3.9.2 and 4.0.0.0 including the transport between the ARM and FPGA fabric. It is likely that change that has had the biggest impact on the streaming performance. You can try playing around with some of the device arguments (specifically recv_buff_size, num_recv_frames, and recv_frame_size) to see if they help at all while we investigate.

[vibhud]

@michael-west Any update on the issue? I see same behavior.