[Tinyos-devel] packet level time synchronization TEP

[Geoffrey Werner-Allen]

Hi Miklos:

> This is a good point, but is it really necessary to change the length of
> > packets at all?  What is currently done is to add bytes to the end, but
> why
> > not just have the protocol stipulate that the last 4 bytes of the packet
> > data are overwritten? This doesn't require any length munging on the
> sender
> > and receiver and allows simpler access to the timestamp on the receiver
> side
> > (since I just declare a field for it in my message struct). It also means
> > that you don't have to handle the corner case where X + 4 > maximum
> packet
> > size.  Would that work?
>
> Yes, that would work without a problem. However you will not get a
> timestamp in those 4 bytes, only a time offset in microsecond, the
> actual time stamp is the packet receive time + this time offset which
> is usually in different units. So this would solve the +4 byte problem
> but would not simplify the getting the time offset part.
>

Well, either you can correct this in a ReceiveNotifier interface as we are
discussing below, or just have the recipient have to call a separate
function to complete the process.

Another option is to, rather than putting in the offset (i.e. eventTime -
wireTime), you could just put in wireTime and let the receiver sort it out.
(You've already got 4 bytes in there, right?) It seems like, while the delay
can be applied directly to the receivers timestamp without interpretation,
it only is meaningful in the context of the event (i.e. the timestamp
associated with the packet, in the case of FTSP the localtime in the senders
context that matches the globaltime contained in the message).  So in order
to make any sense out of the offset the receiver needs the event time, the
wire time, and the received time. Right now you put in the difference, but
why not just include all three in their full glory?

> The other solution which is more intrusive is to have an equivalent to the
> > SendNotifier interface on the receive side. Essentially something that
> sat
> > on the top of the receive stack and was able to munge packets before
> > Receive.receive() was called.  This would allow you to correct the length
> > without having to implement another AM pass-through.  It could also be
> > useful in other contexts, although I can't come up with any off of the
> top
> > of my head.
>
> I think it would be best to somehow register a set of AM types with
> the SendNotifier and ReveiceNotifier interfaces, and move all extra
> parameters into these. This could remove most of the metadata too (e.g
> LPL duty cycle, etc.).
>

I think that could simplify some things, but other pieces of metadata (like
whether or not to timestamp the packet in the transmit handler, the LPL duty
cycle, etc.) are there because they effect the way that other pieces of the
stack behave. I'm not sure I understand, for example, how if you remove the
LPL duty cycle the LPL layer knows how long to send the packet train for?

Best,

-gwa-
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20081207/eafd35b5/attachment.htm