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

[Vlado Handziski]

On Dec 19, 2007 11:42 AM, Miklos Maroti <mmaroti at math.u-szeged.hu> wrote:

> Hi!
>
> > I expect that timesync protocol implementations in T2 (e.g. FTSP, RBS,
> > RITS) wouldn't wire the "standard precision" interfaces, but would work
> > directly with the arbitrary precision ones the radio stacks provide. I
> > would say that in 90% of the cases applications would wire the above
> > protocols instead of the low-level timestamping primitives. For the
> > remaining 10%, I don't think it's worth specifying a standard precision
> > for the HIL, either.
>
> No. The MAC in most cases will provide a SINGLE over the air precision.
> How that is presented to the application developer (as a platform sepcific
> precision or a standard one) is a different issue. I think for now we can
> have this single patform dependent over the air precision (in almost all
> cases 32khz) and have a standard PacketTimeSynch precision (with
> 32khz). This way 90% of the applications can use the standard interfaces,
> and would be completely shielded by changes in the MAC if later we
> need to modify the over-the-air layout. Anyone how wants to experiment
> with higher over-the-air precision now can rewire the MAC layer and
> provide the native over-te-air precision PacketTimeSynch which can be
> converted to the standard 32khz PacketTimeSynch with a simple
> wrapper.
>
> The applications need to be shileded, we need a standard interface
> that MUST be provided by all platforms. The implementation details
> are details.
>
>
Exactly.  We are mixing vertically and horizontally things that should be
kept decoupled in the spirit of the HAA. First of all, the different
building-blocks of the time-synchronization functionality (time stamping,
sending of the stamps over the air, reading/control of local clocks, etc.)
CAN be observed separately. For each of these a HAL/HIL decomposition should
be performed. This means that the HALs for each platform should be designed
in a way that exports to the rest of the system the maximal reasonable
capabilities allowed by the timer hardware and the available computational
resources. This means that each platform can have its own notion of
PacketTimeStamp/PacketTimeSync precision and size on the HAL level. Whenever
a protocol/application wants to tap the full potential of the platform it
should use these interfaces directly.

Once we have these platform HAL interfaces (conceptually) we can start the
discussion of selecting a HIL that will transform them to
platform-independent interfaces used by portable applications/protocols. The
HAA proposes that the capabilities of the most "common" hardware/application
requirements  combination at a given point of time should be used in
selecting these interfaces, effectively making the HIL implementation for
these platforms quite "thin" because of the significant overlap between the
exported capabilities at the HAL and the HIL. Looking at the discussion (I
am not an expert on time-sync apps), it looks like the 32kHz osci as a
source sounds reasonable, with 16 or 32 bit size.

All of this is completely orthogonal to the way we want to implement the HAL
and and the HIL levels. For example, we can follow the same approach as in
the current timer library where we have a common infrastructure across the
platforms for building those HALs using generic interfaces and components.

As for the on-the-air format, the portability of the representation depends
on the level in the stack where we want to conceptually assign this info to.
The current practice has been that MAC/LL allows of platform specific
behavior, while above the AM we should strive for platform-independent
meaning of the payload. Following this practice, we can stick with a single
default cross-platform interpretation of the time stamp data (that might or
might not correspond 1:1 with the selected HIL precision, i.e. it has to be
better or equal to). Using AM type differentiation, applications/protocols
that need to do so, can tunnel HAL level info instead.

Vlado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-devel/attachments/20071219/a7a79b3e/attachment-0001.htm