After comparing tick count results from different APIs, it looks like the issue is due to two factors.
First, when an application is started, it is assigned to a core, or some other interrupt-related state, that determines the order in which different tick count APIs (GetTickCount(), GetTickCount64(), QueryPerfomanceCounter(), timeGetTime(), GetSystemTimePreciseAsFileTime(), etc.) update their results. This is similar to what is being reported
here.
Second, different tick count APIs return results that are close but not identical, and may, in the same run, lag behind or be ahead of other methods, even if they are of higher resolution. The standard deviation will depend on the above.
mIRC uses different methods of determining tick count, based on Windows version, which APIs are available, and whether the multimedia timer is being used.
The issue you are seeing seems to be due to /timer using different tick count measures at different points to calculate elpased timed. Due to the variable lag mentioned above, this leads to a bias in elapsed time measurement per application run.
I have changed how /timer -h uses tick counts and tested it on Windows XP, 7, and 10 and this seems to have resolved the issue. This change will be in the next beta.
