[fpc-devel] Problem with Now() and time changed by ntpd

[Jonas Maebe]

Marco van de Voort wrote on Wed, 02 Nov 2011:

> The point was just some encouragement to look further than the immediate
> need though, and keep the time call relatively cheap. That doesn't exclude
> being correct, it just means a more elaborate implementation.

I do not think that reporting the time correctly taking into account  
the current time zone and daylight savings time is a function that  
needs to be treated as performance-critical.

> They are not really used to time execution times btw, but more to rate limit
> certain events to xx per second.  The events can die out for hours however
> (if the machine is stopping for maintenance) Strictly speaking that carries
> a monotonous time requirement, but these are of the kind where a trip once
> an year doesn't matter.

Twice a year. Anyway: a function that reports the local time is simply  
the wrong tool for the job if you need a "mostly" monotonic timer that  
you can query at a high frequency. It may work (and apparently it does  
for you), but instating a plugin architecture just to be able to keep  
using it for that purpose is the wrong approach as far as I am  
concerned.

And even if it is eventually transformed into a pluggable API, fixing  
it now does not require this plug-in architecture to exist, nor does  
fixing it make it harder to transform it into a pluggable API  
afterwards.

> But harddisk latency can easily be in the half a second to second magnitude
> (and then I don't even count spindowns, and am I accessing directories that
> I continously access).

If you are stat'ing that file for changes all the time, either the  
result will be cached or the hard drive won't spin down. And stat'ing  
a file will not take half a second when done repeatedly.

> In Delphi, for timing of short intervals, typically queryperformance counter
> + family is used, but iirc these can't measure longer intervals and are very
> imprecise the too (since the CPU frequency might change)

For longer intervals you can use gettickcount/gettickcount64 on  
Windows and fpgettimeofday on Unix. I'm not opposed at all to add some  
kind of extra "return a monotonic clock value" function somewhere.

> In our previous episode, Jonas Maebe said:
>> If you are in a case where you do want a high precision timer that is only
>> adjusted once to the system's timezone (namely when the program was
>> started), then I think it is quite reasonable if the RTL does not provide
>> such functionality in a standard call.
>
> Not entirely related to the discussion,

It is related as far as I am concerned, because the above is how Now()  
currently works on Unix and as far as I understand, you don't want it  
to be fixed using a straightforward stat/update check because that may  
reduce the performance/rate properties of that call.

> but I don't see that at all.  There
> is a reason why libc has monotonous time functions.

Yes, but they are presumably not based on timezone information because  
that inherently defeats the monotonic property.


Jonas

----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.