时延
- We can calculate the latency introduced by the USB since the USB packet
is only sent when we have a sufficient amount of data collected in the USRP
buffer, i.e., the smallest allowed USB packet is 512 byte, and the largest one
is specified by the user by two parameters, fusb_nblock and fusb_block_size. As
a paper mentions, the USB delay (Tu) is according to the
equation:
Tu = f(512,
fusb_block_size*fusb_nblock) / (fs*sample_size )
Where:f(x,y) is
depends on the data in the buffer and it is at least x and at most y and fs is
the sampling frequency. Since we use complex 16 bit samples, the sample size is
sample_ size = 2 * 16bit= 4
bytes
So, does that mean if we have large product of
fusb_block_size and fusb_nblock, then the theoretical maximum delay will be
increased?
Yes that is true. If you're trying to minimize latency you want the smallest
values that work reliably (no over/underruns) and with acceptable overhead. If
you enable real time scheduling, you can reliably use smaller values. Try
fusb_block_size 2048 and fusb_nblock 4 or 8. You may be able to run with
fusb_block_size 1024. It depends on your data rate across the USB.
- What is the theoretical minimum roundtrip latency that we can achieve
with the USRP?
Different cases:
1) 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.
2) On the FX2 the minimum we can use is two in each
direction.
3) 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. In USRP,
we're currently running with 512 byte packets.
Theoretical Calculations:
Let the PKTSIZE = 512. In both directions we
can't start the transport until you've assembled a full packet. Assume we're
running at 32MB/sec, t0 = 16usec. The transport time of a single packet from the
host controller to the FX2 is
t1 = PKTSIZE (bytes)/32(Mbyte/sec) = 16
usec
The transport time of a single packet from the FX2 to the FPGA is
about
t2 = 4 us + PKTSIZE (bytes)/96(Mbyte/sec) = 9.33
usec
[The 4 us is firmware overhead in the FX2. It could be
improved]
The best case:
Outbound looks like = t0 + t1 + t2 = 41.33 usec.
Inbound is the same 41.33 usec.
With 512 byte packets, total round trip latency
2 * (t0 + t1 + t2) = 83 usec
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 the small
packets]
- How we can practically measure the round trip latency?
Here's an easy way to measure round trip latency:
Hook up a signal
generator to one of the Rx basic inputs and to one input of an oscilloscope.
Hook up one Tx basic output to another input on the o'scope. Write some code on
the host that reads from usrp.source_c and writes to usrp.sink_c Look at the
delay between the two traces on your o'scope.
[ << 装载 FPGA 微码 | ^ USRP
FAQ 首页 ^ | FX2 USB 控制器 >>
]
注：Timing Latency Questions（原文出处，翻译整理仅供参考!）
|
|
