[Tinyos-devel] packet timestamping and packet-level timesynchronization

[Janos Sallai]

Robbie,

> Assuming that there will eventually be an official timesync component
> checked into the t2 tree, what are the chances of that implementation
> making use of this mode of operation?

The packet time stamping/synchronization TEPs specify what interfaces
must be implemented by the communication stack in order to be TEP
compliant, how these interfaces should be provided, and it describes how
the user should use these interfaces.

The packet time stamping/synch implementation (which is part of the
communications stack) does not have to be portable. In fact, it is even
less portable than a particular radio stack, since the implementation
may also be dependent on the clock sources that are specific to a
particular platform. I think Miklos' comment about the possibility of a
generic (i.e. radio stack independent)
packet-time-synch-over-packet-time-stamping implementation might be a
bit of an overstatement.

Since, however, the TEPs specify how these interfaces are provided by
the HIL, components relying on the HIL will be portable across
platforms. An example of such a component is FTSP, which provides global
time, but it is beyond the scope of the packet time stamping/synch TEPs,
as stated in the intro sections.

Janos

-----Original Message-----
From: Adler, Robert P [mailto:robert.p.adler at intel.com] 
Sent: Tuesday, May 13, 2008 12:40 PM
To: Miklos Maroti; Janos Sallai
Cc: tinyos-devel at millennium.berkeley.edu
Subject: RE: [Tinyos-devel] packet timestamping and packet-level
timesynchronization

 

>
>> > On the timesync protocol side of
>> > thing, slow interrupt handling time forced us to changing 
>the original
>> > flooding timesync protocol so that tx timestamps were sent 
>out on the
>> > next outgoing packet instead of on the current outgoing 
>packet since
>> the
>> > write to the outgoing tx fifo as it was going out over the air was
>> > something that didn't always work.  At least IMHO, it would be good
>> for
>> > the timesync interface to be able to support such an 
>operating mode as
>> > it will eliminate the race condition on the packet write 
>(arguably a
>> > better coding practice) while also making fewer 
>assumptions about the
>> > processor's interrupt handling turn around time.  The current
>> interface
>> > might be made to support such a mode, but it's not clear if this is
>> > something that was intentionally supported or not.
>>
>> This is a very good point. Such implementation would definitely work
>> with the interfaces, but I had not thought of this. It is, in fact,
>> equivalent to using the PacketTimestamp interface to implement the
>> PacketTimeSync functionality. I guess that it makes sense to 
>change the
>> implementation guidelines section to describe this approach, too.
>
>This could be implemented as follows. The TimeSyncSend implementation
>could send a short message to the destination address which is
>timestamped on both side, but the stamp is not embedded. Then the
>actual payload is transmitted together with the proper embedded time
>stamp. The receiver has to remember the last time sync message arrival
>time so it can use and return that value. This would be a very nice
>generic implementation that requires only the PacketTimeStamp
>interface to work.
>
>Miklos
>
Assuming that there will eventually be an official timesync component
checked into the t2 tree, what are the chances of that implementation
making use of this mode of operation?  As you say, it is more generic
and it certainly makes fewer assumptions (if any) on platform interrupt
handling performance.  While it's probably possible to make the two
modes of operation compatible, this seems like unnecessary overhead if
the more generic one was used from the get go.  From previously
experience, imote2 definitely requires this alternate mode of operation,
so at some point, at least that platform will need to implement this
alternate version (thus making interoperability a bit problematic).

Another comment on the TEP; how might other, non-radio components take
advantage of timestamps?.  In the past this was through the GlobalTime
interface, but it would also be nice for components that use an
interface like that to be able to get "isvalid" information.  Perhaps
this is another TEP, but I can certainly see an argument being made for
having both radio packet timestamps and other timestamps covered under
the same TEP.

-Robbie