discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] USRP latency


From: Eric Blossom
Subject: [Discuss-gnuradio] USRP latency
Date: Fri, 4 Feb 2005 11:49:07 -0800
User-agent: Mutt/1.5.6i

Here are some back-of-the-envelope calculations on the minimum roundtrip
latency I think we can achieve with the USRP.

These calculations assume that you're running half-duplex, or that the
sum of the Tx and Rx throughputs are <= 32MB/sec.

[I've added "measure the latency" to my to-do list.]

A) On the host I think that the minimum number of packet buffers we can
live with is 2 in each direction.  This is to ensure that the EHCI USB
host controller end point queue always has something in it for our
end points.  This is required to keep the throughput up and to keep us
from suffering underrun or overruns on the USRP.

B) On the FX2 the minimum we can use is two in each direction.

C) On the output path to the FPGA, there's a fifo, but the pipeline
runs if there's any data in the fifo.  This doesn't appear to add any
delay.


We're currently running with 512 byte packets.

Let PKTSIZE = 512

In both directions you can't start the transport until you've assembled
a full packet.  Assume you're running at 32MB/sec, t0 = 16us


The transport time of a single packet from the host controller to the
FX2 is

        PKTSIZE bytes       sec
  t1 =                *  --------  = 16us
                          32M byte


The transport time of a single packet from the FX2 to the FPGA is about

                PKTSIZE bytes      sec
  t2 =   4 us +               * --------- = 9.33 us
                                 96M byte

[The 4 us is firmware overhead in the FX2.  It could be improved]


The best case outbound case looks like t0 + t1 + t2 = 41.33 us

Inbound is the same 41.33 us. 



With 512 byte packets, total round trip latency

  2 * (t0 + t1 + t2) = 83 us


Lowering the packet size to 64 bytes would reduce this to

  2 * (2 + 2 + 4.7) = 8.7 us [this is optimistic, since our throughput 
                              will drop, and there are lots of other
                              unaccounted factors.  E.g., greater USB
                              overhead because of small pkts.]

Eric




reply via email to

[Prev in Thread] Current Thread [Next in Thread]