Solved Qt::PreciseTimer performance
-
In an earlier post of mine on timers, JonB responded with a suggestion of using Qt::PreciseTimer. I have implemented this for one-minute interval and it runs from 8am to 4pm. There are about 4-5 instances where it is horribly off, like 15-seconds or more. The other thing I have noticed is the cumulative drift. By midday it is consistently running 0.4 seconds late and by the end of the day this drift has gone up to 0.8 seconds. Nothing too disconcerting but anybody know why it would be like 15+ seconds late the few times? The whole CPU is only taxed at 70% and this process only gets up to 3% CPU usage. Thanks.
-
Hi,
What does your application do ? Any heavy computation ?
-
Today there were 8 instances where the timer was late between 1 to 2 seconds and one where it was late by 4 secs. This doesn't include the 0.1-second/hour drift which I can live with.
The app itself is something I wrote for my thesis. Data is sent from remote sensors via Dynamic Data Exchange link where it is picked up by an Excel spreadsheet. I don't have the smarts to write a DDE app in python and the Excel front-end was already working in the lab. The Excel does some processing with the data but that is separate and it uses up about 35% of the 3-core CPU. This app takes the raw unprocessed data from Excel every 2-secs and puts it out the QTableWidget with no processing. Every 1-minute a counter is incremented so that at the end of the day I store all the data for each 1-min interval. Right now I am running this for 8-hours but eventually it will run 24-hours. I can fix the small drift by doing a reset on the timer but these random delays could play havoc. This app barely crosses 3% CPU usage. Any insight appreciated. Thanks.
-
Hi, just a guess but if you're fetching the data from Excel via ActiveQt/QAxObjects then that could be the reason for the delays, since DDE is a protocol from the 80's it's a bit loose with the timings, what I mean is that Excel could be busy DDE'ing while you're polling it for data.
-
@hskoglund said in Qt::PreciseTimer performance:
Hi, just a guess but if you're fetching the data from Excel via ActiveQt/QAxObjects then that could be the reason for the delays, since DDE is a protocol from the 80's it's a bit loose with the timings, what I mean is that Excel could be busy DDE'ing while you're polling it for data.
This is quite plausible.
To test this hypothesis, create a separate thread that runs nothing except a timer. Make the thread print debug messages every minute.
@ACollins said in Qt::PreciseTimer performance:
The whole CPU is only taxed at 70% and this process only gets up to 3% CPU usage.
What about RAM? If that gets used up, the OS will start transferring data between your RAM and your pagefile which can cause delays.
Right now I am running this for 8-hours but eventually it will run 24-hours. I can fix the small drift by doing a reset on the timer but these random delays could play havoc.
How are you measuring the delays?
Anyway, if timing precision and determinism are important to you, look into using a real-time operating system -- for example, by applying the PREEMPT_RT patch to your Linux kernel.
Windows is not real-time. The OS can put your app to sleep for any period of time that it wants. This can block timers, even Qt::PreciseTimer. In contrast, you can tell a RTOS that a particular thread in a particular process is time-critical and the OS will guarantee that the thread doesn't get delayed beyond a certain threshold (assuming that it doesn't get starved of CPU and RAM)
Note that Qt::PreciseTimer is primarily designed to be a high-resolution timer that can be triggered at millisecond intervals. I don't know how well it performs when you try to trigger it at minute intervals.
-
I am using xlwings to read data from Excel. ActiveQt/QAxObjects is well beyond my abilities.
I am printing a msg from inside the function that is called every minute. That is how I am determining the time. I let it run from 8am to 5:45 and total drift was 1.004121 secs at the end of the day. I can live with that. As for random delays, it seems they are related to app clogging up the CPU. One way might be to spawn off a new thread. Will a single-shot timer spawn off a new thread or does it run in the same thread?
The RAM is fine. It never gets to more than 60% RAM used. RTOS would be overkill.
-
@ACollins said in Qt::PreciseTimer performance:
Will a single-shot timer spawn off a new thread or does it run in the same thread?
Same thread.