Sunday, March 4, 2012

Re: [Discuss-gnuradio] building carrier sense in the FPGA and UHD

On 03/04/2012 04:10 PM, George Nychis wrote:
>
> I totally like and support your idea and would love to help realizing
> it. Using the timestamp logic inside UHD as a reference is a great idea
> that also came to my mind a while ago.
> There are a few things from the architecture point of view though that
> need to be discussed. Let's take a CSMA MAC as an example, I guess that
> goes into the right direction :-) Just having the "if channel free,
> transmit packet"-logic inside the FPGA wouldn't make much sense in a
> multi-user environment. What would happen is that if the channel is busy
> and multiple nodes have packets in their tx queues, they would all end
> up sending their packets more or less at the same time after the channel
> gets idle again (assuming all nodes are in sensing range). In a
> practical system, one would now start to move parts of the CSMA state
> machine, i.e the random backoff, into the FPGA. Trying to control this
> via UHD is probably a bad idea as UHD's main business is transportation.
>
> I do think we need something like what you have suggested but I am still
> a bit puzzled about the right way of implementing it.
>
>
> Hi Andre,
>
> Yeppp, the idea is to build part of the MAC in to the FPGA... the part
> that requires low latency operation. So, after the simple "transmit
> when idle" logic, you put some basic form of back off in to the logic
> also.
>
> I have a paper which argues low latency MAC functionality should be
> built in to the FPGA, but controlled from the host, otherwise it's as
> good as worthless implementing it on the host. If you try to build this
> part of the MAC at the host, the latency of receiving the channel state
> (latency from FPGA -> host), making a decision and performing an action
> (host -> FPGA), completely makes the information stale. You end up with
> a decision that is something like 1-2ms old, which clearly the state of
> the channel changes at a more finer-grain than that.

Well, I believe it's just a matter of scaling the whole system by the
right factor. Information that is 1ms old can still be valuable if it
still represents the truth.

I just don't want to loose all the flexibility of software by moving the
critical but interesting things to hardware.

But of course, it all depends upon your goals.

-Andre


_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

No comments:

Post a Comment