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

Lecoq Yann Yann.Lecoq at obspm.fr
Wed Oct 28 11:35:24 EDT 2015

Hello Michael,

Thanks for the feed-back and tips.

I played a little with the sample rate and frame size, with no much improvement. I also tried using sc16 instead of fc32, went from the generic Linux kernel to the low-latency version (Ubuntu 14.04), and used cpufreq-set to get all the 8 "seen" cores (4 hyperthreaded cores in reality, on my intel core i7 laptop processor) at max frequency (2.9GHz).

With a bit of all these tricks, the best I could get to was about 500µs delay, with still a few L and U packets transmits warning every hour. This points more towards, as you said yourself, a gnuradio (or UHD) latency overhead issue than a PCIe latency issue. I will try again with a PCIe x4 connection when I receive the necessary equipment, just to be sure though.

Best regards,


Le Vendredi 23 Octobre 2015 21:25 CEST, Michael West <michael.west at ettus.com> a écrit: 
> 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
> >

More information about the USRP-users mailing list