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

[Philip Levis]

On Dec 18, 2007, at 11:14 PM, Janos Sallai wrote:

>>>
> Not necessarily. The precision of the timestamp in the footer can be
> arbitrary (i.e. platform specific or radio stack specific), as long as
> there is a way for the recipients of the packet (which are potentially
> different devices) to figure that out. This would encourage  
> implementers
> of radio stacks not to omit timestamping support just because  
> complying
> with a "network time precision" is too cumbersome.

This requires additional bits in the packet, describing the  
precision, or the protocol specification (e.g., of a particular AM  
type) defining the precision.

>
> The precision (and width) provided by the HIL is completely  
> independent
> from settling on an over-the-air timestamp precision. Well, completely
> independent might be an overstatement, but for sure, they don't  
> have to be
> identical. Of course, the over-the-air precision is equal or higher  
> than
> the HIL precision required by the standard. We can well say that  
> the radio
> stacks MUST provide PacketTimeStamp and PacketTimeSync with a  
> prescribed
> "standard precision", without specifying a standard over-the-air  
> network
> time precision.

The concern is on both fronts: code and packets. We want code to be  
portable, and we want different network implementations to be  
interoperable.
>

> It's trivial to implement a component that converts the timestamps  
> from
> radio stack specific over-the-air precision to "standard  
> precision". If
> the network is homogeneous, you don't even have to ask the sender  
> what the
> timestamp precision of the received packet is. (This is what I had  
> been
> referring to when I was writing that 90% of the deployments are
> homogeneous.)

The implicit assumption here is that you don't evolve your code.  
E.g., you build your app on 2.0.2, deploy it, and then when you want  
to add new nodes, you compile against 2.0.2. Any deployment therefore  
suffers the bit rot of historical code. Because, who knows, it might  
be that 2.1.3 stack changes the timestamp precision in the packet but  
keeps the same programming interface.

Phil