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

Philip Levis pal at cs.stanford.edu
Mon Feb 16 20:26:40 PST 2009

On Feb 16, 2009, at 8:02 PM, Razvan Musaloiu-E. wrote:

> Hi!
> On Mon, 16 Feb 2009, Philip Levis wrote:
>> 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?
> There was not other load! :-)
> I attached program that demonstrates this. The nesc program is  
> sending packets back to back. The PC side is sending from time to  
> time a packet to the mote. The RX led from the mote is properly  
> blinking indicating this but there is not ACK coming from the mote.  
> When the baudrate is lowered to 57600 the acks start working properly.
> Note: the blue leds blinks when a mote receives a packet from the PC.


As I've said, this observation isn't new. Sure, I've myself written  
and run programs just like this one before. Have you read the email  
thread I posted?

The point is that 57600 is only reliable assuming there is no other  
load in the system. Shifting to 57600 doesn't promise you anything; it  
just happens to work when all you're doing is a serial stress test.  

>> 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.
> I understand the need for acks but if the delivery radio between PC  
> and mote is very-very low (as the attached program proves) then even  
> if we have acks the situation is not so good.
>> 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.
> My argument is that if we don't drop to 57600 then, if a high enough  
> data rate from mote to PC can kill the delivery ratio from PC to mote.

I understand this. But there are of course a lot of other solutions:

1) The serial protocol could have a PC->mote ACK that tells the mote a  
transmission is pending, which causes the mote to pause until it  
receives it (with some error timeout).

2) More generally, the serial protocol could have explicit flow control.

3) The mote could rate-limit its send rate when it detects it is  
receiving bytes.

Or, the small slice of applications that have persistently high serial  
load could just use 57600.


More information about the Tinyos-devel mailing list