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

[Philip Levis]

On Feb 16, 2009, at 6:14 PM, Omprakash Gnawali wrote:

> On Mon, Feb 16, 2009 at 2:54 PM, Stephen Dawson-Haggerty
> <stevedh at eecs.berkeley.edu> wrote:
>> On Mon, Feb 16, 2009 at 2:50 PM, Razvan Musaloiu-E. <razvanm at cs.jhu.edu 
>> >
>> wrote:
>>> Hi!
>>>
>>> On Mon, 16 Feb 2009, Stephen Dawson-Haggerty wrote:
>>>
>>>> I don't know what other tests people have run, but at least in my
>>>> experience
>>>> (all on linux) 115200 seems to have more dropped packets and be  
>>>> less
>>>> stable
>>>> when you're sending quickly.
>>>
>>> In which direction did you see this? In my case I see dropped  
>>> packets when
>>> I send from PC to the mote. The other direction (from the mote to  
>>> PC) seems
>>> fine. Which is probably why many people don't have big issues with  
>>> 115200.
>>> :P
>>
>> I think I agree with you-- packets make it to the pc just fine but  
>> they get
>> dropped on the way to the mote.
>>
>> This seems consistent with what Eric said about the receive path  
>> being a
>> little too long on the mote-- presumably the pc doesn't have this  
>> problem.
>>
>
> For Tenet (which has mote-pc and pc-mote packets), we used 115200 for
> a while and switched to 57600 for higher reliability.

I think part of the complication is also that some of it seemed to be  
due to USB hubs and other factors, so it was not certain that the  
issue was the TinyOS code. Ben Greenstein, when he ran tests, didn't  
see overflows.[1] David Moss seemed to think the Linux side was due to  
the FTDI driver.[2] This, combined with the fact that it's not hard  
for a host application to limit its rate, suggested that reducing the  
mote->PC throughput to 57600 was not worth it.

I feel like this is a damned-if-you-do, damned-if-you-don't situation.  
If we set it to 57600, then people who need high mote->PC throughput  
will say it should be 115200. If we set it to 115200, then people who  
need high PC->mote throughput will say it should be 57600.

Maybe the solution is to change the toolchain. If the errors are only  
when you're sending quickly, then it's unlikely to be the interrupt  
handler length. The packet send rate does not determine the inter- 
interrupt timing, after all. Can someone verify this? If this is the  
case (it's the packet rate, not the bitrate), then we can rate-limit  
packets.

Phil

[1] http://mail.millennium.berkeley.edu/pipermail/tinyos-devel/2008-April/002704.html
[2] http://mail.millennium.berkeley.edu/pipermail/tinyos-devel/2008-April/002705.html