Wait Until Next Millisecond Taking longer than it should

[evapjep]

Rather sure it was the recent windows feature updates, tried to roll back on one PC, but the machine instantly shut off and was then difficult to get back alive.. so hesitant to try a rollback on other PC's.  I deferred windows updates and changed the IT time sync policy from 15 mins to 1 week when I tried that ah-ha thought two weeks back.

I built and started the test chart .exe on the PC I have the most issue with, will have to check frequently as the chart will only display about 25 minutes of history without making the history length to large for practical screen resolution. Also replaced the "wait till next multiple" with just "wait" as that seems more stable in general with only longer delays.

I have no doubt it will exceed 4 seconds in the next 24hrs, maybe 6 or more.

Thanks for the ideas, I will keep searching too.

[Ben]

My money is on the OS being mucked with via an update or a push from IT.

THE Desktop Execution Toolkit may shed some light but I suspect the light will point at the OS not scheduling the code to run because it has to go look for virus checks etc.

If I really had to chase this down, I would kill every background process on the machine, shut off all power saving nonsense pull the plug to the internet and then let it run.

Ben

[evapjep]

Why??

[mcduff]

Follow Sir Ben's advice:

1. Disconnect Network.
2. Kill unnecessary services. (Safe Mode easiest way to accomplish)
3. If possible kill AV.
4. Kill any Bitcoin processes.

mcduff

This is what I see with me using my computer and in a locked down situation for work.

[cstorey]

I'd put in a case to get a time stamp when the 6s delay happens and then go look at the windows events logs for answers.

[mcduff]

Update: Ran simple loop from yesterday afternoon to this morning. IT pushed an update that did not require a restart. Kept track of the maximum delay, it is 765 ms, well under 6 s, and not too far off from the value 750 ms.

Check your computer for other stuff.

mcduff

[Frozen]

Have you tried logging (time-stamp) when the larger variations occur? It might give you some more insight to your problems... like correlating deviations to any scheduled activates on your PC. I also suspect something your IT department did.

If you are really grasping at straws, you can try checking your BIOS clock.

Now I am really curious to what the problems is. Keep us updated!

Good luck!

[evapjep]

Logging with timestamp results:

Timestamp | ms Max loop time (again 750ms wait loop doing nearly nothing as test)

10/24/19 1:20:11.17 PM	884
10/24/19 1:20:11.92 PM	884
10/24/19 1:20:12.68 PM	884
10/24/19 1:20:13.43 PM	884
10/24/19 1:20:14.29 PM	5819
10/24/19 1:20:20.07 PM	5819
10/24/19 1:20:20.82 PM	5819
10/24/19 1:20:21.58 PM	5819
10/24/19 1:20:22.33 PM	5819

Last windows system log 12:36:39PM, again no helpful info here, timestamp and ms cntr agree, but no event logged in windows, just a long delay occurrence.

only events close were at 1:18:45 and 1:21:38 for security audits/Special Logon/Logon which seem to happen frequently.  I stopped the W32Time Service for this testing, server updates as well.  Thanks for the ideas, but still at a loss for the solution.

[Frozen]

Oh wow! That is a lot more frequent that I expected. It is occurring once every minute it seems.... for multiple minutes in a row.

[EDIT]: WAIT, that is every second... it is taking 5 seconds every second... something is not adding up there.

[evapjep]

only one event, logging the max time only and full timestamp, updated diagram:

the clock is Get Date/Time in Seconds with some friendly format to string [%Y/%m/%d %H:%M:%S%3u] code