[Tinyos-devel] Time Sync Requirements

[Michael Newman]

My message was intended to present a reason for fine granularity time
against several emails that suggest that there is no need for it at all.

In addition to there being a reason for fine granularity time I think TinyOS
code will benefit from a simple representation of time that can be coded
against with very simple assumptions on how to write the code. I think a 64
bit representation can be good enough to handle all of the interesting cases
including date/time and sub-nanosecond time counting. Note that there are
two types of time represented by 64 bit numbers, elapsed time and date/time.
Elapsed times can be added to date/times. Elapsed times might be logged in
smaller sized datums if they happen to fit. Date/times can not be shrunk
without adding complexity.

I suspect the efficiency of code to use smaller time types will be offset by
increased complexity to mix usage of various time types.

When you have a limited oscillator as Phil describes you count time by a
larger number and the low order bits of the time counter never change.

One issue that must be thought about for this type of implementation is how
to handle timers that count and incompatible intervals. For example Mu-law
encoding of telephone audio is 8000 cycles per second. This does not fit
well with timers that count at 1024 cycles per second. If the finest
precision is only 1024 cycles per second it could be impossible to implement
time for telephone audio. I suspect that we can identify a critical set of
times and make sure that the minimum granularity of the time base allows for
all of them.

-----Original Message-----
From: Philip Levis [mailto:pal at cs.stanford.edu] 
Sent: Wednesday, December 19, 2007 5:16 PM
To: Michael Newman
Cc: 'TinyOS Development'
Subject: Re: [Tinyos-devel] Time Sync Requirements


On Dec 19, 2007, at 2:08 PM, Michael Newman wrote:

> I think very fine grain time is critical. I would opt for microsecond
> granularity and can make an argument for nanosecond granularity.
>
> Consider communication protocols where nodes sleep and wake up at  
> specific
> times to communicate.
>
> The accuracy of the time sync is equivalent to the cost in power  
> for the
> nodes to communicate. For the communication to succeed the  
> listening node
> must be on for plus and minus the skew in time between the nodes  
> plus the
> message time. The skew is usually much larger than the message time.
>
> While it is possible for time sync to be accurate with coarse time
> granularity it is very difficult. More straightforward implementations
> require fine granularity in time. In straightforward  
> implementations with
> coarse time granularity the skew will be driven by the time  
> granularity.
>
> I have worked on frequency hopping protocols where these issues are
> critical. It is my experience that listening for messages dominates  
> the
> power consumption and that time skew is a huge contributing factor.
>
>
> A second reason for fine granularity time:
>
> Nanosecond or sub-nanosecond granularity allows for timing of radio  
> waves
> and would be used for marking time in systems like GPS receivers.

The question isn't what is desired, but rather, what's a reasonable  
minimum functionality that most hardware can easily achieve. Nano- 
second granularity is kind of difficult with an 8MHz oscillator.

Phil