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

[Andreas Koepke]

>> 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. 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.

>> 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
>>>>>>
>>>>>>
>>>
>>
>