[Tinyos-devel] FTSP testing result

[Branislav Kusy]

hi thomas,

yes, i suggested to drop the timestamp queue a while ago but nobody got 
around to actually do it. miklos suggested some code in august'08 on 
tinyos devel list, but it didn't work, so i didn't commit it. i'll send 
you a link later because the berkeley server is down right now.

if you send me a patch, i can stress test the code to see if it works 
and then we can commit it.

as for the magic 10 ticks - we were wondering about it as well and never 
got an explanation. i think the conclusion was that this was for ack 
timestamps to fall through. but i'm not even sure who wrote it.

brano


Thomas Schmid wrote:
> Has anybody tried to fix this? The timestamp queue is very ugly right
> now! Especially, we basically invalidate the timestamp every time we
> have more than one timestamp in that queue anyway!
> 
> Next, I think the problem for the invalidated timestamps in the
> ReceiveP is in line number 324 in CC2420Transmit P. Code here
> duplicated:
> if ( time - m_prev_time < 10 ) {
>   call CC2420Receive.sfd_dropped();
>   if (m_msg)
>     call PacketTimeStamp.clear(m_msg);
> }
> 
> I don't really understand what this check is for, but this will always
> trigger a clear on the timestamp if we fall through in the SFD. I
> think this is wrong. We should only invalidate the timestamp if
> SFD.get() was 0 at the time of reading the timer, not if the time
> between the two interrupts was smaller than some magic 10 tics.
> 
> If no one is working on this already, please let me know and I will
> clean this timestamping mess up.
> 
> Cheers,
> 
> Thomas
> 
> On Mon, Feb 9, 2009 at 3:13 AM, Omprakash Gnawali <gnawali at usc.edu> wrote:
>> On Mon, Feb 9, 2009 at 2:09 AM, Andreas Köpke <koepke at tkn.tu-berlin.de> wrote:
>>>> Branislav Kusy wrote:
>>>>> so it seems the problem fixed?
>>>>>
>>> Ok -- I did some more measurements with the code, so the patch in
>>> CC2420TransmitP works well: now all timesync packets are transmitted with a
>>> correct timesync field.
>>>
>>> But on the CC2420ReceiveP side, all timestamps are cleared again. The CVS
>>> version 1.17 works fine for me, but the 1.18 does not.
>>>
>>> And while we are at it: can we remove this time stamp queue stuff? I can not
>>> imagine how this should work with LPL.
>>>
>> In one experiment, getGlobalTime call returned a success but the time
>> was all over the place; it should have been roughly linear over time.
>> This happened for a significant fraction of the experiment duration.
>> In another run, this was not the case.
>>
>> - om_p
>>
>> _______________________________________________
>> Tinyos-devel mailing list
>> Tinyos-devel at millennium.berkeley.edu
>> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
>>
> 
> 
>