[Tinyos-devel] again about the baudrate issue for telos

[Philip Levis]

On Feb 17, 2009, at 7:25 PM, Omprakash Gnawali wrote:

> On Tue, Feb 17, 2009 at 5:42 PM, Philip Levis <pal at cs.stanford.edu>  
> wrote:
>>
>> On Feb 17, 2009, at 8:42 AM, Jorge Ortiz wrote:
>>
>>> If we're taking a poll, I vote to slow it down to 57600.  I've had
>>> trouble with the higher speed with and without the serial
>>> forwarder.  At 57600 all my serial-related reliability problems went
>>> away and the code I was working with was significantly more stable.
>>>
>>> Jorge
>>
>> Can you be more specific than "I've had trouble?" Which direction?
>> What motes? What operating system? Which serial forwarder?
>>
>> I could have some code in my back pocket that's unstable except at
>> 2400. There's a fundamental issue here, with respect to rate control
>> and flow control. The general operating model for the serial stack  
>> was
>> that data mostly comes *out* of the network, so you want to optimize
>> the mote->PC speed. Changing it to 57600 might make the problem go
>> away for some cases, but it doesn't actually solve the problem. This
>> isn't good system design.
>
> The argument almost sounds like you should not use the provided
> PC->mote interface unless you don't care about the packets being
> delivered. I think there are hidden assumptions about reliability and
> hidden assumptions are almost everywhere so it is not necessarily
> dangerous.

I think "don't care" is perhaps a bit strong. Let's wind this back a  
bit.

One reason why there was a push to 115200 was the speed of the CC2420.  
When folks mess around with MAC parameters (e.g., send bursts of  
packets with no carrier sense), then 57600 ends up being insufficient  
for forwarding packets from the radio. E.g., sustaining 616pps with a  
payload of 14 bytes leads to 23 bytes x 616 packets x 8 bits, or  
113,344 bps. 616pps comes from the original rates the stack was  
clocked at in the T2 tech report. While Alan from UCL has noted that  
telosb in T2 can't sustain this (due to running at a lower clock  
speed, such that there are FIFO overflows), correctly configured TMote  
sky units can, and we've yet to measure the rate with DMA.

That being said, what you're saying is generally correct: you can't  
assume the serial link is reliable. This is the end-to-end argument.  
Configuring a system in order to (imperfectly) maintain a fiction is  
not good system design.

However, the issue here is not really reliability, but starvation.  
High load in the mote->PC direction causes bytes to be dropped in the  
PC->mote direction, such that packets almost never arrive successfully.

That being said, there are lots of ways to solve this. Here's a simple  
one: when a packet is lost in the PC->mote direction, have the PC  
toolchain start inserting small pauses between bytes, so the mote has  
time enough to handle the interrupt. Scale the duration of these  
pauses using MIAD (multiplicative increase, additive decrease). This  
would be a few tens of lines of Java code, and would not limit the  
mote->PC rate in the unidirectional case.

Phil