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

[Stephen Dawson-Haggerty]

On Tue, Feb 17, 2009 at 7:25 PM, Omprakash Gnawali <gnawali at usc.edu> wrote:

> On Tue, Feb 17, 2009 at 5:42 PM, Philip Levis <pal at cs.stanford.edu> wrote:
> >
> > 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.
> >>
> >> Jorge
> >
> > 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 was
> > 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
> dangerous.
>
> I think the point being made here is in some (maybe a lot?) scenarios
> there is the need to simplify the system rather than make it pure and
> perfect. If the system is being built for deployments where there is
> no luxury for trial-and-error, they can be easily convinced that they
> might want to do more than rely on assuming PC->mote reliability. If
> someone wants to send messages to control quick research experiments,
> a flow control that follows "good system design" might seem onerous.
>
> If someone has implemented PC->mote reliability, it would be good to
> examine the code and timing overheads. If the overheads are minimal,
> we should make such a system widely available because one of the
> arguments here is no one should use the unreliable PC->mote
> communication unless you don't care about packet delivery. If no one
> has implemented such a module, we can recommend this work when someone
> is looking for a project...


I think Phil's statement actually gets to the bottom of this
misunderstanding.  From TEP113, justifying the serial stack: "Users need to
read data out of a TinyOS network."  That's true, but that's not all they
need to do anymore; from injecting Deluge images to sending command packets
via dissemination to sending IP packets, *lots* of people interact with the
network using full duplex uart, sometimes at a pretty quick rate (at least,
a quick instantanous rate).  However, 113 makes it pretty clear that the
stack hasn't been designed with this in mind; I think many of our
experiences bear this out.

I would be interested in knowing if anyone has tried getting flow control to
work; I gather it's a little tricky, and not all of our platforms export all
the lines necessary for hardware flow control; perhaps the software flow
control is an option.

Anyhow, I didn't want to get into a tiff about this; I just honestly thought
people had agreed that the change would be made.  Since I apparently had a
misunderstanding about that, adding a bit of platform specific code to make
the switch is certainly no problem, and perhaps I will look into better
solutions at some point.

Thanks,
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20090217/062b3b42/attachment.htm