[Tinyos-devel] lost packets from PC to the mote

[David Moss]

Can we be sure that the Linux FTDI driver implementation is working
correctly?  It was created by a guy who wanted to use some FTDI chip in
Linux, and not the FTDI Corporation itself.  It's open source, and "The
driver is no longer marked experimental because many people have used it and
it seems to behave as expected. However as with all open source software you
should USE IT AT YOUR OWN RISK."  (http://ftdi-usb-sio.sourceforge.net/)

"Behaved as expected" doesn't give me confidence the thing actually works.

My co-worker has seen numerous problems with timing issues with FTDI drivers
in linux vs. windows (using custom C++ apps).  

TUnit has lots of problems on linux that it does not have on windows.  As
you may know, TUnit uses the java serial forwarder to check if a node is
connected to the system. It does this by starting the serial forwarder,
sending a ping packet, waiting for a reply, and then disconnecting.  It can
normally get through this procedure once, but the second time, the ping
packet never reaches the mote. This causes TUnit to think that there is no
mote connected, and the test fails. The java native driver controlling the
FTDI driver in linux may be to blame, but the FTDI driver itself may be
broken in some edge cases.  It works fine on Windows
(http://www.lavalampmotemasters is still chugging away on a windows box,
because linux serial stuff gave me lots of problems when I tried to set it
up on linux long ago).

So what's the difference? FTDI drivers and native java serial code.  But the
fact that bypassing the java native serial code with a C++ app still has
problems tells me the issue may be more with FTDI linux drivers.  That
hypothesis seems to be compatible with all the evidence I've seen. Someone
feel like digging into the FTDI linux drivers?

-David



-----Original Message-----
From: tinyos-devel-bounces at millennium.berkeley.edu
[mailto:tinyos-devel-bounces at millennium.berkeley.edu] On Behalf Of Ben
Greenstein
Sent: Wednesday, April 30, 2008 2:45 PM
To: Razvan Musaloiu-E.
Cc: tinyos-devel at millennium.berkeley.edu; Philip Levis
Subject: Re: [Tinyos-devel] lost packets from PC to the mote

Razvan,
Thanks for digging into this and sorry to take so long to reply to the
thread. I never got to the bottom of why 115200 (and rates above that)
incur so many losses. I did verify that there were no overflows. I'm
surprised that you see these problems in linux as I only saw them in
Cygwin. Perhaps it was the device that I was using and not the OS that
made the difference (the linux env was on a dell precision 690
desktop, cygwin/windows was on a thinkpad t42 laptop). I verified that
the overflow bit in the control register wasn't being asserted. Also,
since this problem only seems to manifest itself when there are
packets going in both directions, I'd guess that packets are being
lost at a higher layer. Aargh.
Ben


On Fri, Apr 25, 2008 at 6:31 PM, Razvan Musaloiu-E. <razvanm at cs.jhu.edu>
wrote:
> Hi!
>
>
>  On Fri, 25 Apr 2008, Philip Levis wrote:
>
>  >
>  > On Apr 18, 2008, at 6:47 PM, Razvan Musaloiu-E. wrote:
>  >> Hi!
>  >>
>  >> I just noticed that when a mote sends a lot of packets to a the PC,
the
>  >> packets from the PC to the mote doesn't go reach the user application
layer
>  >> some of the time. In the attached archive there is a test program that
is
>  >> exposing this. The mote program is sending packets back-to-back while
the
>  >> PC program (in Java) is receiving the packets and sends to the mote
one
>  >> packets each second. I run the program on telosb in the following way:
>  >>
>  >> (console 1)$ ./sf 9001 /dev/ttyUSB0 115200
>  >> (console 2)$ java StressSerialTest -comm sf at localhost:9001
>  >>
>  >> The mote is toggling the blue led each time it receives a packet and
it
>  >> should change state each time the RX led from the USB blinks. This
doesn't
>  >> always happen: the RX led indicates a receive but the blue doesn't
always
>  >> change its state. The (console 1) also shows lines like this:
>  >>      Note: write failed
>  >>      Note: write failed
>  >>      Note: write failed
>  >>      Note: write failed
>  >>
>  >> Did anyone else notice this behavior?
>  >
>  > Razvan,
>  >
>  > When I run your test application on my machine, I do not see this
behavior. I
>  > was able to send 100 packets (the program ran for 100 seconds) with no
write
>  > fails. What write fail rate do you observe?
>
>  Here are the loss rates I got so far:
>
>  Python in Linux:
>               115200        57600
>               PC   Laptop   PC Laptop
>         MoteA 20%   18%     0%  0%
>         MoteB 33%   20%     0%  0%
>         MoteC 34%   17%     0%  0%
>
>  Native Python in Windows:
>               115200  57600
>         MoteD 68%     88%
>
>  Java application using C sf in Linux:
>                115200  57600
>                PC      PC
>          MoteC 18%     0%
>
>  I all the test I send between 100-120 packets.
>
>  I haven't check the serial hardware overflow indicator yet but that's
what
>  I'm going to do next.
>
>  --
>  Razvan ME
>
>
>
>  > I ran your Java application connected to a C serial forwarder.
>  >
>  > Phil
>  _______________________________________________
>  Tinyos-devel mailing list
>  Tinyos-devel at millennium.berkeley.edu
>  https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>
_______________________________________________
Tinyos-devel mailing list
Tinyos-devel at millennium.berkeley.edu
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel