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

Philip Levis pal at cs.stanford.edu
Mon Feb 16 19:16:57 PST 2009

On Feb 16, 2009, at 7:05 PM, Razvan Musaloiu-E. wrote:

> Hi!
>> 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.
> In my experience a high traffic from mote to PC at 115200 can make  
> pretty much impossible the sending from PC to mote. At 57600 things  
> worked fine for any amount of traffic from mote to PC. Does this  
> match other people's experience?

Well, this is all assuming that there's no other load on the system,  
right? It seems like a "seems to work" solution rather than get at the  
actual problem. For example, what happens if you try to receive over  
serial at 57600 while also receiving packets over the radio as fast as  
possible (MAC delay set to 0)?

What I'm trying to say is that core looked at this really really  
carefully for several months, and concluded that the only correct  
solution is higher-layer rate-limiting or acknowledgments. You cannot  
assume the serial link is reliable. But enforcing this on all serial  
protocols seemed a waste of code memory. Systems that need this  
functionality can introduce it.

Setting the serial port to 57600 is basically saying that, in case you  
have high throughput in both directions, everyone should only be able  
to use half of the link throughput. I'm not trying to argue that this  
is the wrong decision, but it doesn't actually solve the problem, it  
just happens to work.


More information about the Tinyos-devel mailing list