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
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
