Re: [Discuss-gnuradio] implementing state flow

[Eric Blossom]

On Tue, May 03, 2005 at 10:29:20AM -0500, Jim Hanlon wrote:

> I think the issue of programming MAC layer interaction comes down to
> one of timing. I am still investigating gnuradio-to-USRP timings,
> but I am looking at simple integer writes to the daughterboard,
> driven from a python program loop, and seeing 1 to 5 per millisecond
> on the logic analyzer.

If what you are measuring is the time required to wiggle a
daughterboard i/o pin you are measuring a *very* slow path.

That path was never intended for low latency or high throughput, but
rather to be able to control PLL's etc on daughterboards.  There is a
part of that communication path that is over an SPI serial bus that is
big-banged by firmware in the FX2.  It's not fast.

The fast path on the USRP would be (as yet unimplemented) in-band
signaling on the Tx data path.

> Now, my controller machine is a bit slow, and I regularly see USB
> underruns and overruns during tx and rx tests.

Generally speaking you shouldn't see under or overruns.  We generally
see them because of two reasons:

  (1) slow USB EHCI host controller
  (2) burning up too many cycles on signal processing (signal
      processing not keeping up).

> But say a fast CPU could effectively service the USB link (the presumed
> bottleneck). What then? 10 integers per mS?  20? And how would these
> simple integer writes translate to service times for successive MAC
> data units?

Assuming you are sending your control in-band with the data (not out of
the question with a packet based protocol), the key question is the
minimum round trip latency from the host app, through the USB to the FPGA.

There's a discussion of this at:
http://lists.gnu.org/archive/html/discuss-gnuradio/2005-02/msg00035.html

Summary: 

   best case with 512-byte packets:   83 uS round-trip
   best case with 64-byte packets:   ~10 uS round-trip


> I am most interested at the moment in 802.11, which has quite a
> complex MAC layer, particularly in its "permission-to-send" logic,
> the Distributed Coordination Function. Interframe timings are
> multiples of SIFS and slot times (10 and 20uS, respectively). Just
> on the basis of back-of-the-envelop calculations, combined with my
> baseline measurements, a Python implementation of 802.11 MAC seems
> unlikely.

For sake of clarity, I would distinguish "host based" from C++ and/or
Python.  Generally speaking we try to keep python out of any
performance critical path.  Even so, I think that an 802.11 MAC would
be hard to implement on the host with the USRP.

> Even given a more modern CPU, one that could run MAC logic
> effectively, I would still be concerned with the stability and
> repeatability of MAC-associated timing. USB link servicing,
> turnaround times, etc., would add still more variation.

Real time scheduling could bound this.

> Would a USRP PCIe bus connection improve the situation? Probably,
> but such a thing does not yet exist.

A PCI/PCIe bus connection would lower the latency.

> A natural question arises: Could the FPGA on the USRP perform 802.11
> MAC logic in a timely and repeatable manner? This is an intriguing
> possibility. Current program space on the Cyclone chip is limited,
> but the USRP II could conceivably provide more room to maneuver.

If it would fit, putting at least part of the MAC on the FPGA would
make sense.

> Another factor to consider is that the economics of mass production
> affects the wisdom of using general purpose tools for specific
> purposes. If a mass-market wireless interface card or router maker
> were to make their system "open" in some sense, it would behoove one
> to get in the $20-$50 part and go to town programming it. The
> actions of Linksys and its WRT54GS router are instructive in this
> regard: there's quite a lot of activity reprogramming the firmware
> of this product (see sveasoft.com forums, search on "long fat pipes"
> for altering SIFS intervals).

> Jim Hanlon

Eric