[Tinyos-devel] Re: [Tinyos Core WG] time sync interfaces

[David Gay]

On Dec 13, 2007 5:20 AM, Miklos Maroti <mmaroti at math.u-szeged.hu> wrote:
> Dear All,
>
> > > interface PacketTimeSynch<precision_tag, size_type> {
> > >   async command void set(message_t* msg, size_type eventTime);
> > >   async command bool isSet(message_t* msg);
> > >   async command size_type get(message_t* msg);
> > > }
>
> Another, maybe less controversial interface would be a callback:
>
> interface PacketLastTouch
> {
>     async event lastTouch(message_t* msg);
> }
>
> which would be called AFTER the packet has been timestamped with
> the PacketTimeStamp interface and before it was actually transmitted.
> This would allow to do last touch modifications to the message just
> when it is going out. The ActiveMessageC would provide this interface
> with am_type dispatch:
>
>    provides PacketLastTouch[am_type am];
>
> and the default implementation would do nothing.
>
> ADVANTAGES:
>
> - AM_TYPE specific, no need for extra bit in the footer
> - Does not constrain the type of time synch protocol, width and precision
>
> DISADVANTAGES:
>
> - On some architecture maybe it is not possible to provide this
> call after the message is time stamped and/or the MAC does not
> know what part of the message has been modified.
>
> It is important that this call is called AFTER the packet is time
> stamped, otherwise we cannot guarantee precise timing.
>
> What do you guys think?

This also has the disadvantage that the corresponding 1.x interface
had: excessive processing in a lastTouch implementation can break the
radio stack, i.e. on some radio stacks the place where lastTouch would
be called is very timing sensitive. "Excessive processing" may not be
much processing btw (I think the example from 1.x involved a few
32-bit arithmetic operations).

An alternate proposal would be:

interface PacketTimeSync
{
    async event int8_t isTimeSyncPacket();
}

which would be:
- offered as a parameterized-by-amid interface (like PacketLastTouch)
- called from the radio stack at the "last possible moment"
- if isTimeSyncPacket returns -1, nothing happens
- if isTimeSyncPacket returns X (>= 0), a time stamp is stuffed in the
packet at offset X

The idea is:
- to make it easy to only put time stamps in some packets, with no
header overhead
- to discourage users from doing anything fancy within a critical part
of a radio stack - normally they should just do something like return
a constant (or maybe a variable's value) from isTimeSyncPacket - this
is why there's no message_t parameter...

There's a few obvious issues:
- what's the width/precision/etc of the timestamp (maybe
PacketTimeSync should be a generic interface, with appropriate type
parameters, presumably matching the radio stack's PacketTimeStamping
interface)
- how do you get the right offset in isTimeSyncPacket?
- isTimeSyncPacket could be split into two events (one for the
question, the other for the offset)

David