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
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
