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

[Andreas Köpke]

If you write/read byte by byte the NSLU2 can not use the OS/HW internal buffers 
-- which is what you want and achieve with that patch. But having 8 or more 
telosb nodes at 115200 implies a total bit rate of something like 2MBit/s -- 
which is difficult to achieve without buffer support from the HW/OS, esp. since 
the NSLU2 runs at 133 MHz -- here goes your CPU time. The patch just shifts 
the workload: reducing the work load on the mote and increasing it on the 
slug, although in my experience the slug can handle it, but its stability 
seems to decrease, probably due to temperature effects. 

As a bottom line, all this patching and bit rate fiddling is just shifting the 
problem around, instead of solving it. In a solution, one would need to 
replace the code on the mote with a version that uses the DMA (reducing the 
CPU load there by avoiding the interrupt per byte, at least for sending) and a 
flow control protocol, which should be window based in order to "keep the pipe 
full" despite the long USB delays. Ok -- this looks like an overkill, but one 
could imagine to use the mote just as  a radio frontend an run a complex 
protocol on the PC or slug, which requires that one can send the packets at 
"radio speed" from PC to mote. But that is a whole lot of work, which might 
even require  a different TEP, so nobody attempted it. 

Best, Andreas 

On Dienstag 03 März 2009 Chieh-Jan (Mike) Liang wrote:
> Hi Andreas,
>
> Can you elaborate more? I am interested in what code can lead to the
> high CPU load, and see if there is any work-around.
>
> Thank you
>
> Mike
>
> On Mar 3, 2009, at 2:11 AM, Andreas Köpke wrote:
> > Hi, this patch has one disadvantage: it makes the SF less suitable
> > for devices
> > like the NSLU2: writing/reading single bytes for 8 or more telosb
> > leads to a
> > high CPU load on an slug.
> >
> > Best, Andreas
> >
> > On Dienstag 03 März 2009 00:06:37 Chieh-Jan (Mike) Liang wrote:
> >> Hi Eric,
> >>
> >> In my case, when the mote->pc packet rate is high, I get a a lot of
> >> "write fail" from the C serial forwarder, even at 57600. Here are my
> >> changes to the C serial forwarder:
> >>
> >> 1.) I have byte spacing to wait a little bit after sending each byte.
> >> Currently, this is 50 micro-sec, but I think it can be lower. Byte
> >> spacing was also recently added to the python T2 serial stack,
> >> tos.py.
> >> The hope is that the mote has some more time to handle the interrupt.
> >> 2.) Byte spacing helps a lot, but there were still some "write fail".
> >> So, I retry sending a packet if such case happens. I believe the Cpp
> >> serial forwarder already does this, but not the C version.
> >>
> >> I attached a patch. Please let me know if you see something weird.
> >>
> >> Thank you
> >>
> >> Mike