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

[Marco van de Voort]

In our previous episode, Jonas Maebe said:

> 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.

True, but as said a very common abuse. Oh, and btw, I forgot, I update a
clock on my app once a second too (which is not that strange for
systems that run fullscreen).

Note again that my apps are not in FPC, and could be easily changed. They are
just meant as illustrations of very common use (and thus of the number of
support issues you can expect when sb after a lot of debugging finds out
that the system reacts differently, *JUST* like the issue that initiated
this thread)
 
> 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.

That kind of quick and dirty mentality and pooh,poohing away sideeffects
(like a noticably slower gettime) without a way to override it is exactly
what I'm afraid of.

> > 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.

So this would make FPC apps that use gettime a lot not very eco friendly :-)

> And stat'ing  
> a file will not take half a second when done repeatedly.

On average or _always_. Big difference. I'm talking about worst case times,
not average times.
 
> > 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.

(I'm not sure btw if monotonic is the right term for getticks like
solutions.  Afaik it is used more for clocks that never go back, e.g.  that
handle setting clock back by running slower for a while)

> > 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.

I meant that wrt compatibility, since such solution requires an audit of all
gettime use, and worse awareness. On the other hand I'm not as insensitive
to the "time should be correct" arguments as people think I am.

Such code change solution would be like having said "monitor timezone info
yourself and update unixutils.tzsecond if you see changes" to Zeljko.  The
trouble when porting is that you must first find the problem before you can
fix it. Argueing that the fix is easy is futile in such case, since
diagnosing the problem out is nearly always magnitudes more work (and trouble)

Minimizing that is one of the things compatibility is about. More
importantly, the various requirements don't bite eachother, except that a
proper solution might require some more functionality in the core set (hence
plugin route).

> > 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.

I'm not sure. (see "monotonic" remarks above).