On Sun, Jul 3, 2011 at 8:16 AM, Tom Rondeau <trondeau1...@gmail.com> wrote:
> On Thu, Jun 30, 2011 at 9:16 PM, Morgan Redfield <redfie...@gmail.com>wrote: > >> Hi, >> >> I've been working on building a CSMA/CA MAC for the past couple of >> weeks. I built it in Python, and used ofdm/tunnel.py as a guide. It's >> working now, but I don't think it's very efficient. I ended up having >> to relax a lot of timing parameters to get it working, so my >> throughput is pretty bad. I also get a lot of dropped packets. I think >> this is also because my timing isn't very accurate, and I end up with >> more collisions than I would expect. >> >> I was wondering if anyone else had had any luck building a CSMA/CA >> MAC. I saw a few posts on the mailing list from several years ago >> about people who were working on it, but I don't see any example code >> anywhere. I also checked out CMUmacs on CGRAN, but that relies on a >> deprecated version of GNURadio. >> >> Is my best bet to rewrite the MAC as a block in C++? Can anyone tell >> me what kind of speedup that's likely to get me? >> >> Thanks, >> Morgan Redfield >> > > > Morgan, > Yes, this is an issue with MACs in software radio when you have a bus like > USB or Ethernet between the processing and the air interface. These buses > have fairly large and jittery latency, so by the time you have received > samples, measured the power to determine that the channel is clear, and then > sent a payload to be transmitted, but the time the payload actually goes out > of the air interface, you decision is so far in the past that it's pretty > meaningless to the current state of the channel. > > We have a rudimentary CSMA MAC in tunnel.py in the digital examples, but it > suffers from the same problems you are seeing. > > Tom > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > Perhaps this could be a new feature for the UHD driver interface. There is already a start streaming at clock value X feature. The idea is to augment that and have a start streaming at clock value X if channel is clear; if not clear return an error code. A channel sense block should not be too complicated to put into hardware. A side note, it would be great if Ettus and company could develop a USRP with a PCI-express interface (the new Thunderbolt interface?). This could possible solve a lot of the timing issues (can the more HW oriented folks comment on this). Also it would a great excuse to sell a more expensive USRP board (with higher margin! $$). :P --Colby
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
