[Tinyos-devel] improving FTSP interface

[Andreas Köpke]

Am Donnerstag, den 07.08.2008, 10:44 -0700 schrieb Branislav Kusy:
> 
> Omprakash Gnawali wrote:
> > On Thu, Aug 7, 2008 at 10:09 AM, Andreas Köpke <koepke at tkn.tu-berlin.de> wrote:
> >> Am Donnerstag, den 07.08.2008, 09:29 -0700 schrieb Branislav Kusy:
> >>>>>> But realize, the 33rd bit (which is what you are asking for) might
> >>>>>> change for other reasons as well. How can FTSP detect a rollover
> >>>>>> internally? If your timesync is so much messed up that it cannot
> >>>>>> distinguish a rollover from a simple 2^31 unit time offset change,
> >>>>>> then you should not rely on it in the first place. Trust me, just
> >>>>>> watch the 32nd bit, and tell me a concrete scenario when that is not
> >>>>>> working.
> >>>>> It is much easier for FTSP to realize if it is a rollover or other
> >>>>> reasons than an application. I think this is different from 33rd bit.
> >>>>>
> >>>>> Yes, we run FTSP in scenarios where something more than the 32nd or
> >>>>> 33rd bit would be useful and seems necessary - a bit that takes into
> >>>>> account the FTSP state machine as well as the counter value.
> >>>> FTSP does not have a state machine, it always updates its internal
> >>>> global clock pretty much in the same way (except when it is the root
> >>>> node). It calculates a reference point (local, global time pair) and a
> >>>> skew from an internal list of data points. Yes, global time can jump
> >>>> if the node looses connection, but you can detect that one as well
> >>>> (via the TimeSyncInfo.getNumEntries method). It is not clear if your
> >>>> overflow (33rd bit) should be set or cleared when a jump occurs. The
> >>>> only reasonable solution would be the following:
> >>>>
> >>>> 1) maintain the last obtained global time value
> >>>> 2) periodically read the current global them when needed
> >>>> 3) if the current global time is less than 0x3FFFFFFF and the last
> >>>> global time is greater than 0xBFFFFFFF, then you have a rollover.
> >>>> 4) replace the last global time with the current global time and go to step 2.
> >>>>
> >>>> Actually, step 3) could be more precise as follows:
> >>>>
> >>>> (int32_t)(current_global_time - last_global_time) > 0
> >>>> && (int32_t)(current_global_time) >= 0
> >>>> && (int32_t)(last_global_time) < 0
> >>>>
> >>>> The first condition says that the clock went forward (with or without
> >>>> overflow, think about it)
> >>>> The second condition says that the highest bit in the current global time is 0
> >>>> The third condition says that the highest bit in the last global time is 1.
> >>>>
> >>>> This should work. Always.
> >>> so to make it easier for app developers, FTSP can provide
> >>> isRollover(uint32_t current_time) command that implements this, right?
> >>>
> >>> one scenario, where rollover would be useful is when your application
> >>> runs for a long time and doesn't query ftsp's global time very often.
> >>> 33rd bit could flip twice without the app realizing it, while rollover
> >>> bit would stay set. for 32khz clock (hopefully provided soon), this
> >>> would mean 4.5 hours which is not totally unreasonable. ftsp could
> >>> realize the rollover because it receives periodic timesync messages.
> >>>
> >>> brano
> >> Another solution would be to provide an overflow "interrupt" like the
> >> Counters.
> >>
> > 
> > Commenting on the interface - an interface such as this or the one
> > that Brano suggested should work.
> > 
> > It just does not make sense for an application to make indirect
> > inferences which can be error prone.
> agreed. especially - miklos's code is usually correct and very 
> efficient, but hard to understand. i bet only 50% of people will 
> understand what he proposed above, and less than 1% will understand the 
> comment that the code will always work (and the reason for it). :)
> 
> any preferences on pull vs push? i'm personally on the pull side 
> (isRollover) - this allows you to check rollover of any timestamp at any 
> place in your code. as opposed to forcing everybody to wire yet another 
> event.
> 
> brano

Push has the advantage that you can maintain a 64 bit clock on top of
it. Just my 2c.