[Interest] QTimer and Qt::PreciseTimer

[Thiago Macieira]

On Friday, 28 July 2017 16:15:27 PDT Joshua Grauman wrote:
> I have a related but different question.
> 
> I am reading the time with QDateTime::currentMSecsSinceEpoch(). How
> susceptible is this time to clock drift/jitter/etc. on Linux (Kubuntu
> 16.04.2)?

It's susceptible to complete jumps. You're using the realtime clock.

> I know ntpd is constantly updating the time, and there is some
> error involved in this. 

How do you know that all your users are using ntpd? How do you know that they 
are in a network that allows NTP packets (it's UDP)?

And how sure are you that the system won't run ntpdate on a whim once you 
connect to a network? (it shouldn't, but a lot of poorly-configured systems 
exist)

> If I am reading the time from
> QDateTime::currentMSecsSinceEpoch() and using it to set a QTimer every
> 40ms, how does ntpd constantly correcting the time going to affect this,
> if at all?

QTimer has nothing to do with the current wall-clock time. The Qt event loop 
uses the monotonic clock exclusively.

> FYI: My timer slot basically looks like this:
> 
> void myClass::animationTimerSlot(void)
> {
>    if(firstTime)
>      startTime=QDateTime::currentMSecsSinceEpoch();
> 
>    dowork();
> 
>    frameCnt++;
>    int t = startTime + ((double)frameCnt*40.0) -
> QDateTime::currentMSecsSinceEpoch(); if(t<0)
>      t=0;
>    animTimer->start(t);
> }

Your code is susceptible to time jumps. If the clock went backwards for a 
second (for example), your t would be about 1000 and your animation would stop 
for a second.

Use the monotonic clock instead.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center