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

[Razvan Musaloiu-E.]

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.

> 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.

--
Razvan ME
-------------- next part --------------
A non-text attachment was scrubbed...
Name: SerialBugV2.tar.gz
Type: application/octet-stream
Size: 8383 bytes
Desc: 
Url : https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20090216/9c27642e/attachment-0001.obj