[Tinyos-devel] Re: Adding receive queue to AM interface

[Philip Levis]

On Sep 24, 2007, at 12:11 PM, Tony Petz wrote:

> Thanks for the answers Miklos and Andreas.  You are not missing  
> anything, it's just that our grasp of the internals is not great.   
> I followed your lead on changing the Packet interface to be  
> asynchronous, and I came across this document making a case for  
> general buffer management:
>
> http://www.hogthrob.dk/output/technotes_files/buffer-management.pdf
>
> Receive queues don't make sense for current platforms, but this  
> makes a case for adding them to support BT and 802.15.4 radios.

The Bluetooth timing also means that you can't disable interrupts for  
a byte time (140/160 cycles). There are many interrupt handlers which  
run longer than this. So you'll lose packets due to dropped bytes,  
back-to-back packets or not. If you could control this, then yeah,  
you'll probably want a receive queue so you can receive back-to-back  
packets. Note, though, that there's little chance that you'll be able  
to process large bursts of packets: my guess is that you'd be  
spending almost all your cycles just streaming from the UART. Don't  
forget that to be async, your queue will require atomic sections. The  
TinyOS serial stack also suffers from a byte-time turnaround problem,  
which is why it maintains two buffers.

Again, this comes down to Amdahl's law: is the lack of a receive  
queue a significant loss of packets, or are the losses elsewhere? The  
key first step to solving an engineering problem is to quantify the  
impact of the different causes.

With respect to 15.4, are you concerned with the bit rate? 15.4  
radios aren't byte-level, they are packet level, so timing is not so  
tight. TinyOS stacks can receive packets as fast as 15.4 can send  
them, even when there is no MAC backoff.

Receive queues will not let you receive packets faster. Rather, they  
will let you absorb bursts of faster packets. This leads to the  
question of how big the queue should be.

All of this naysaying aside, it's clear that if the radio is fast  
enough, or requires fast interrupt processing, the underlying radio  
stack will need to have a different design than current ones do. I  
just question whether "receive queues! receive queues!" will  
substantively solve the issues raised by either of the above example  
radios.

Phil