Ah i never heard of this before.
That would explain why i see 58.86 or 59 instead of 60 when i time the monogame timer and i end up short always with fixed on and 60 fps.
However if i run at 120 more often then not i end up at like 125 fps or so which is just another indication that the timing that was patched into monogame last was not tested properly or something is buged,
Also if i remember right win 7 uses a different underlying call to query the time deep down the rtc is not always used if a certain bit flag is set windows will switch and some of the resolutions are 16 ms.
It is in that ms page i linked.
Timing is absolutely critical to a smooth running game so this is where i tend to think the problem stems from.
This could be hardware interupts as well like the mouse interupts interfering with the timing interupts or something thread wise but the more likely suspect is the timer.
I can manually time things better myself with fixed off then on to be honest even with gameTime which does have a very small error interval so its fairly accurate.
Ok so i was just thinking about this and i had a idea if its really hard to know were the problem is maybe it is possible to know when the problem is.
If it is stemming from a interrupt or some gc or even a big hiccup in the timer.
Then the interval error on a single frame should show a spike in proportion to the average interval error.
I suppose if you were recording everything that was going on in the last frame then you could see likely culprits for the reason that spike occurred and start to narrow down the source that way.