[Tinyos-devel] FTSP testing result

[Thomas Schmid]

I attached a patch for the first problem described earlier. This
should fix problems with the receive timestamp.

Thomas

On Mon, Feb 23, 2009 at 10:25 AM, Branislav Kusy <kusy at stanford.edu> wrote:
> 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
>>>
>>
>>
>>
>



-- 
"Don't complain; Just work harder" - Randy Pausch

Thomas Schmid, Ph.D. Candidate
Networked & Embedded Systems Laboratory (NESL)
University of California, Los Angeles (UCLA)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-fixing-SFD-state-problem.patch
Type: text/x-diff
Size: 2934 bytes
Desc: not available
Url : https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20090223/b8d1e82a/attachment.patch