Re: [Discuss-gnuradio] implementing state flow
On Thu, May 05, 2005 at 11:52:23AM -0700, Eric Blossom wrote: > On Mon, May 02, 2005 at 04:07:04PM -0700, Richard Cagley wrote: > > To implement MAC layer elements, i.e. waiting for data to arrive, is the > > best strategy to program these elements in python? > > This is an area of active exploration. > > Some are working in python, some with blocks in C++, some using the > message and message queue abstractions. It's not sorted out. > > > Are there any example apps that implement packet modem like functionality? > > Rahul, care to chime in here about your work? I'm working on CSMA/CA-over-GNU Radio. Here's a long-winded summary: The end goal is an 802.11-like protocol (probably with relaxed timing requirements), so CSMA/CA is a necessary first step. To keep things simple, I'm using wires (wireless will come...later) The flowgraph makes things very modular, and once you understand the programming model, things fall into place nicely (Eric, thanks for you all your help!) GNU Radio provides message queues, which are very useful for passing state information between blocks and also link subgraphs nicely. Incidentally, I'm told the OSSIE project at Virginia Tech is compatible with GNU Radio. I'm not sure if that means the full platform or just the USRP, though. The main problems that I've encountered are lack of a good way to handle timing and difficulty implementing physical carrier sensing. Timing has been mentioned a few times, and the consensus seems to be that it will require some changes in GNU Radio. Eric mentioned setting up something running alongside the ADCs/DACs to do this (off-list discussion). Until then, I'm planning on hacking in something to emulate timeouts and retransmissions. In general, it's a bad idea to sleep in a block, but if I set up the flowgraph right, I think I can get away with it. Maybe using SIGALRM will help also. As already noted, keeping up with DIFS and SIFS will be difficult because of the latency issues. Putting some of the MAC in the FPGA sounds promising, but what are the implications for on-the-fly reconfigurationg? How long would it take to reprogram the FPGA if you needed to switch between 802.11a and b/g? As for carrier sensing, I'm pretty sure I'm just not doing something right and need to take another look at it (I'm wrapping up my thesis right now, so I'm tied up with that). Is there a way to shut of the Tx port to make sure there's no carrier? How long does it take to go back to a ready-to-transmit state after it's been shut off? -Rahul -- Rahul Dhar [EMAIL PROTECTED] Actually, my goal is to have a sandwich named after me. pgpNFrSWoVgIG.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] implementing state flow
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
Re: [Discuss-gnuradio] implementing state flow
On Mon, May 02, 2005 at 04:07:04PM -0700, Richard Cagley wrote: > To implement MAC layer elements, i.e. waiting for data to arrive, is the > best strategy to program these elements in python? This is an area of active exploration. Some are working in python, some with blocks in C++, some using the message and message queue abstractions. It's not sorted out. > Are there any example apps that implement packet modem like functionality? Rahul, care to chime in here about your work? Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] implementing state flow
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. Now, my controller machine is a bit slow, and I regularly see USB underruns and overruns during tx and rx tests. 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? 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. 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. Would a USRP PCIe bus connection improve the situation? Probably, but such a thing does not yet exist. 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. 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 ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] implementing state flow
To implement MAC layer elements, i.e. waiting for data to arrive, is the best strategy to program these elements in python? Are there any example apps that implement packet modem like functionality? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
