[Tinyos-devel] again about the baudrate issue for telos
pal at cs.stanford.edu
Tue Feb 17 20:13:17 PST 2009
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>
>> 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.
>> 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
>> 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
I think "don't care" is perhaps a bit strong. Let's wind this back a
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.
More information about the Tinyos-devel