[USRP-users] roundtrip delay with x310 and RIO express card interface

Michael West michael.west at ettus.com
Fri Oct 23 15:25:22 EDT 2015


Hi Yann,

GnuRadio may not be the best to use for lowest latency.  There is overhead
added and each block runs in its own thread, so the latency introduced by
GnuRadio can be significant.  It is very easy to write a program that
receives and immediately sends the received data using the UHD C++ API.
One of the many examples packaged with UHD could be easily modified to do
that.

The ExpressCard PCIe interface is only x1 and the 10us latency was measured
on a PCIe x4 interface.  Furthermore, the latency is only the UHD and
transport latency and does not include the DSP chains.  It was tested by
taking the timespec from the received packet, adding an offset, sending the
packet and checking the asynchronous data to see if a late packet was
reported using the UHD C++ API.  Sample rate and frame size will also
significantly affect latency.

The simple things to try:
1)  Increase the sample rate.
2)  Reduce frame size.  Add "recv_frame_size=XXX,send_frame_size=XXX" to
the device address field (where XXX is the size in bytes).  The default for
PCIe is ~8K.

The more drastic things to try:
1)  Use a PCIe x4 connection
2)  Use the UHD C++ API and have a single thread call recv() and send()
back to back.

Best regards,
Michael


On Fri, Oct 23, 2015 at 3:19 AM, Lecoq Yann via USRP-users <
usrp-users at lists.ettus.com> wrote:

> Hello,
>
> I am trying to see if I can use a X310 for a (reasonnably fast) servo loop
> involving the RX and TX of a UBX160 daughter board. To this aim, I need to
> sync the RX and TX and reduce the round trip delay for a signal going from
> RX to TX via the host computer as much as possible.
>
> The test bench for this is a simple gnuradio flowgraph, connected as such:
>
> ****
> usrp source (from RFA/RX)-> delay block -> usrp sink (to RFA/TX)
> ****
>
> In the python file, after declaring the usrp source and sink, I synch them
> with:
>
>         now = self.uhd_usrp_source_0.get_time_now().get_real_secs()
>         start = uhd.time_spec(now + 1.3)
>         self.uhd_usrp_source_0.set_start_time(start)
>         self.uhd_usrp_sink_0.set_start_time(start)
>
> I feed the RFA/Rx with an external RF synthesizer near 80MHz. The gnuradio
> sample rate is 20MSPS. The sinewave produced by this synthesizer is
> therefore coppied to the Tx channel, with a fix and predictable delay that
> is set by the delayblock value. I can check the delay that is effectivel
> realized with an oscilloscope monitoring both the signal from the RF
> synthesizer and the signal emmited by the TX. This perfectly agrees with
> what is expected from the flowgraph delay block.
>
> By reducing the delay time, I can get down to 2ms no problem. If I try to
> go to 1ms or less, I start loosing samples which, to me, means that the
> minimum roundtrip delay is somewhere between 1 and 2ms.
>
> I am using a X310 with RIO interface on a Express card laptop, and the
> website claims a roundtrip latency for this interface "as low as 10µs". I
> understand that this is probably obtained in a very specific situation not
> necessarly identical to what I have in mind, but I am still puzzled by the
> 200x difference between what I obtain as a roundtrip delay and what is
> specified.
>
> Am I doing something wrong ? Is there any way or clever trick to reduce
> the round trip delay for a X310 RX to X310 TX in gnuradio ? I understand
> that RFNoC may be a possible answer, but if I could get down to a few 100µs
> roundtrip delay without ressorting to RFNoC it would be good enough for my
> application. Note that I have tried doing the exact same thing in both
> Python and C++ Gnuradio, which doesn't do any better.
>
>
> Thanks for any help or hint on this issue.
>
> -Yann Le Coq
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users at lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20151023/bcad2477/attachment-0002.html>


More information about the USRP-users mailing list