USB latency problem

I tried to use the usrp for implementing rfid protocols, however the USB
latency is causing a bottleneck and I cannot generate and send the reply
packet before the timeout(I need to send the reply within 80-120 us).
upon reading Thomas Schimd’s
paper(http://nesl.ee.ucla.edu/document/show/242), it seems that I may
have
to do processing on the fpga itself instead of sending data over usb.

Has anyone else faced a similar problem? CTS packets in 802.11 use
functionality similar to mine, so maybe those who implemented it can
help
me.

thanks
-rushikesh

It totally depends on where you implement the latency sensitive
components. I believe the best USB can do is a minimum of 100us, and
that probably the theoretical minimum. If you need 80-120 us latency,
you will definitely need to move the latency sensitive components to the
FPGA.

Here are a couple more references related to latency in GNUradio and the
USRP:
G. Nychis, T. Hottelier, Z. Yang, S. Seshan, P. Steenkiste, “Enabling
MAC Protocol Implementations on Software-Defined Radios”, NDIS 2009
K. Tan, J. Zhang, J. Fang, H. Liu, Y. Ye, S. Wang, Y. Zhang, H. Wu, W.
Wang, G. Voelker, “Sora: High Performance Software Radio using General
Purpose Multi-core Processors”

Tim


Timothy R. Newman, Ph.D.
Wireless @ Virginia Tech
447 Durham Hall
Blacksburg, VA 24061
Phone: 540-231-2041


From: [email protected]nvalid
[[email protected]nvalid] On Behalf Of
Rushikesh Khasgiwale [[email protected]]
Sent: Sunday, September 20, 2009 5:17 PM
To: gnuradio
Subject: [Discuss-gnuradio] USB latency problem

I tried to use the usrp for implementing rfid protocols, however the USB
latency is causing a bottleneck and I cannot generate and send the reply
packet before the timeout(I need to send the reply within 80-120 us).
upon reading Thomas Schimd’s
paper(http://nesl.ee.ucla.edu/document/show/242), it seems that I may
have
to do processing on the fpga itself instead of sending data over usb.

Has anyone else faced a similar problem? CTS packets in 802.11 use
functionality similar to mine, so maybe those who implemented it can
help
me.

thanks
-rushikesh


Discuss-gnuradio mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

On Sunday 20 September 2009 22:45:08 Newman, Timothy wrote:

It totally depends on where you implement the latency sensitive components.
I believe the best USB can do is a minimum of 100us, and that probably
the theoretical minimum. If you need 80-120 us latency, you will
definitely need to move the latency sensitive components to the FPGA.

The best you can do with USB is 150-200us, if you use really small USB
transfers (~16bytes), and 250-400 if you use the default block size of
512
bytes. For small transfers, latency is dominated by IRQ coalescing -
there is
just one interrupt per microframe, resulting in a variable delay of
0-125us
[1]. For larger transfers, the time needed for filling a USB packet (128
samples/sample_rate) and transferring it ( (55+512byte) /60MByte/s)
contributes to latency significantly.

Reducing the packet size to 128 bytes hardly influences the achievable
USB
transfer rate (~40MB/s, [2]), but lowers the theoretical latency
signicantly,
although it will cause higher processing overhead on the host. As far as
I
know, there is no possibility to disable irq coalescing.

Stefan

[1] see Intel EHCI specification
[2] USB 2.0 spec, Table 5-10


Stefan Brüns / Bergstraße 21 / 52062 Aachen
phone: +49 241 53809034 mobile: +49 151 50412019

The best you can do with USB is 150-200us, if you use really small USB
transfers (~16bytes), and 250-400 if you use the default block size of 512
bytes.

I did the following experiment:

I connected a square-wave to one of the J101 pins on the RFX1800 on two
USRPs. Then the two PCs polled the pin using some libusrp function. When
the pin changed polarity a burst was sent between the two PCs. The start
of the useful data in the received burst varied up to 0.75ms. Is this
consistent with the above ?

BR/
Per

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs