[Tinyos-devel] cc2420 packet timestamping, FTSP, and LPL

Andreas Köpke koepke at tkn.tu-berlin.de
Mon Mar 2 01:21:28 PST 2009


On Montag 02 März 2009 09:47:25 Branislav Kusy wrote:

> i'd like to restart discussions about packet timestamping (cc2420):
>   1) thomas's CC2420TransmitP.nc patch
>   2) removing m_timestamp_queue queue from CC2420ReceiveP
>   3) timestamping and LPL
>   4) andreas's problem with CC2420ReceiveP
>
> =========================================================================
> 1) thomas's patch
>
> i tested thomas's patch - i set up 5 telosb motes within one hop,
> sending 100 pkts/sec overall, plus keeping MCU busy (running 5ms long
> tasks from a 30ms timer). i tested timestamping only (ie. not ftsp),
> using 32khz precision clock and LPL wasn't enabled.
>
> i have seen small improvements - but there were very few errors in both
> cases. summary of the results based on ~40k collected timestamps:
>
> original code:
> 	4 large timestamping errors (~2000 jiffies~=60ms)
> 	average tx->rx error 0.17 jiffy
> 	average rx<->rx (reference bcast) error 0.18 jiffy
>
> patched code:
> 	2 large timestamping errors (~100 jiffies~=3ms)
> 	average tx->rx error 0.23 jiffy
> 	average rx<->rx error 0.25 jiffy (reference broadcast)
> the average errors exclude the large errors
>
> bottom line: 1 error in 10k packets is pretty good, but not perfect. i
> committed the patch because it may help removing some of the bad cases
> (the big TS error).

Good news, although it would be interesting to have an explanation ;-)

> =========================================================================
> 2) timestamp queue
>
> i think we do agree that cc2420 timestamping is tricky. summarized in
> the attached email from jonathan hui and also discussed by me&miklos a
> while ago:
> http://mail.millennium.berkeley.edu/pipermail/tinyos-devel/2008-August/0033
>46.html
>
> one suggestion to drop the queue was by miklos:
> http://mail.millennium.berkeley.edu/pipermail/tinyos-devel/2008-August/0033
>56.html i tested it and it didn't work, but it can be a good starting point.

As far as I could follow the code, the whole time stamp queue is dead code: 
the real time stamp is maintained in the packet meta data. Besides the 
slightly smaller RAM footprint of the meta data I do not see any advantages, 
not even from a beautiful programming point of view to put the time stamp in a 
separate queue. 

> =========================================================================
> 3) timestamping and LPL
>
> geoff found bugs in the timestamping code which caused all received
> timestamps to be 0 when LPL was used and had a few suggestions of how to
> fix it:
> http://mail.millennium.berkeley.edu/pipermail/tinyos-devel/2008-November/00
>3491.html
>
> geoff's discussion with miklos in this thread is a bit hard to follow,
> due to miklos's bad habit of not using 'reply all' button. but this was
> potentially about changing how packet timestamping is implemented (ie.
> an alternative to the pass-through activemessage implementation) and
> fixing the LPL problems. did anything come out of this?

The observation of gwa is still correct: LPL and time stamping do not work, 
because of the meta data reset in CsmaP.send. What is the reason to reset the 
meta data here? If it is about preventing the meta data to pollute the 
settings of other stack users, we could safely move the meta data reset code 
to the sendDone event. 
 
> =========================================================================
> 4) timestamp zeroed out at the receiver
>
> andreas, i wonder if the problem you mentioned bellow was due to LPL?
> because i haven't seen timestamps being cleared by CC2420ReceiveP. i use
> CC2420PacketC.PacketTimeStamp to read timestamps both on the rx side (in
> Receive.receive event) and on the tx side (in Send.sendDone event).

This might be the case, although I will test with Thomas code again: he 
touched those very lines that seemed to cause the problem. 

> brano
>
> Thomas Schmid wrote:
> > 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-de
> >>>>vel




More information about the Tinyos-devel mailing list