[Tinyos-devel] improving FTSP interface

[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