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

[Razvan Musaloiu-E.]

Hi!

On Mon, 21 Apr 2008, Andreas Koepke wrote:

>>> 2. Due to the temperature dependency of the uC clock speed it may happen
>>>    that the baud rate error is sometimes slightly too large for reliable
>>>    communication. This cause is less likely with slower baud rates
>>>    (they have a smaller initial error).
>> 
>> If this would be the case then the losses should happen even if there are 
>> no packets from the mote to the PC, right? From my tests there are no 
>> losses in that case though.
>
> Correct, now for a little math: At 115200 Bit/s the uC has 86us to process 
> each byte.

115200 bits = 14400 bytes and 1/14400 is about 7e-05. So the MCU has 
around 70us to deal with each byte.

> If both directions are used, this drops to 43us. Scheduling a timer 
> takes about this much in T2. So if the node happens to do something else 
> than mere byte crunching, packets may be lost.

This situation should be indicated by some overflow register from MSP420, 
right?

--
Razvan ME

>>> 3. Can you cross-check with the C++ sf? In our experiments it does not
>>>    loose packets.
>> 
>> Here is what the C++ version says:
>>     >> SF-Server ( SerialComm on device /dev/ttyUSB0 ) : baudrate = 115200 , packets read = 8958 ( dropped = 2678, bad = 0 ) , packets written = 106 ( dropped = 0, total retries: 46 )
>> The packets are not really dropped from the sf client point of view because 
>> the sf is retrying. The number of retries is very high though. :|
>
> Well, yeah but there is some good news hidden here: the first retry is 
> usually successful, and half of the packets are successful at the first 
> attempt.
>
>> -- 
>> Razvan ME
>> 
>>> Best, Andreas
>>> 
>>> Razvan Musaloiu-E.:
>>>> Hi!
>>>> 
>>>> On Sat, 19 Apr 2008, Razvan Musaloiu-E. wrote:
>>>> 
>>>>> Hi!
>>>>> 
>>>>> On Sat, 19 Apr 2008, Vlado Handziski wrote:
>>>>> 
>>>>>> It is a known behavior for which many hypothesis have been made, but no one
>>>>>> has nailed the bug/problem until now. You can dig through the  core WG notes
>>>>>> for some more info on the issues like the different preference to sending
>>>>>> mote->pc direction, etc. Ben has looked into this and it seems it is not a
>>>>>> queue overflow problem. He also experimented with making the ISR reentrant
>>>>>> without noticeable improvement.
>>>>>
>>>>> Thanks for the quick reply. I guess some of the notes you are talking
>>>>> about are these:
>>>>>     http://tinyos.stanford.edu:8000/TinyOS_2.x_WG/05.16.2007
>>>> 
>>>> Some more details: I run the same test code on micaz (on which the
>>>> baudrate is 57600) and no packets were lost. I also lowered the baudrate
>>>> to 57600 for telosb and it also stop losing packets. I only tested with
>>>> low (1 packet/s) data rates from PC to the mote.
>>>> 
>>>> Question for Ben: did you also notice this?
>>>> 
>>>> -- 
>>>> Razvan ME
>>>> 
>>>>>> On Sat, Apr 19, 2008 at 3:47 AM, Razvan Musaloiu-E. 
>>>>>> <razvanm at cs.jhu.edu>
>>>>>> 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 ME
>>>>>>> 
>>>>>>> 
>>>> 
>>> 
>> 
>