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

[Adler, Robert P]

Hi Janos-

My interpretation of Miklos's comment was that the changes I had
suggested were "more generic" in that a TimeSync component that used
such an approach (i.e tx timestamps included in the payload of the next
transmitted packet instead of the current one) could be made to work on
a wider variety of HW.  While it's true that the the timesync
implementation should allow for alternate (platform specific) clock
sources, the implementation shouldn't preclude interoperability.  The
point of my last mail was to request the whatever becomes the standard
T2 implementation be based on this alternate mode so that it could be
easily ported to new platforms(with the same radio) and that
interoperabilty between platforms at least has a chance of working
(there is still the timebase and precision issue).  While these are
implementation issues and not interface issues, it is still important
that the TEP and whatever code gets checked in reflect them.

-Robbie


>
>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
>