Frame skips/reuses with most monitors?

[SubstantialCt8690]

(10-12-2023 04:16 AM)ToastyX Wrote:  It's skipping a frame of input and repeating a frame of output, which is something I haven't seen a display do.

To be clear you do see your monitor doing that with my test program, you're just saying it doesn't happen often. Right?

Quote:Actually to throw more confusion into the mix, there are monitors that can strobe the backlight to reduce motion blur, but it wouldn't be enabled by default because you normally have to explicitly enable this feature. In this case, the backlight only flashes briefly after finishing a refresh and stays black the rest of the time, but that only affects what you see, not how the panel actually refreshes, which doesn't change.

I don't think the monitors I've tested are operating at low persistence, low exposure in the cameras doesn't reveal black bars which is what happens when capturing VR headset LCDs.

[ToastyX]

(10-12-2023 12:27 PM)SubstantialCt8690 Wrote:  

(10-12-2023 04:16 AM)ToastyX Wrote:  It's skipping a frame of input and repeating a frame of output, which is something I haven't seen a display do.

To be clear you do see your monitor doing that with my test program, you're just saying it doesn't happen often. Right?

No, what I see is the monitor receiving the same frame twice from the GPU.

[SubstantialCt8690]

(10-12-2023 01:29 PM)ToastyX Wrote:  No, what I see is the monitor receiving the same frame twice from the GPU.

Understood. So if it's receiving the same frame twice, one would assume it skips a frame after it (shows 1,1,3..)?

Here's all the data I've gathered:

1) Using Intel UHD instead of NVidia GPU didn't solve the artifact.

2)

Quote:when connecting a monitor to a laptop, you end up with two displays. Historically, Windows had issues with multiple displays and would only synchronize with one display, causing stutter on the other, so ideally you should disable the laptop screen when testing the external monitor.

I disabled the main laptop display and it made no difference. What you described is an issue with Linux using the X window system though, when the external monitor would produce extreme tearing at 240Hz 1080p when the laptop's display was also set to 240Hz 1080p and they were extended. Although I'm concerned if I've somehow messed up the blanking values on Windows with CRU and can't reset them for some reason.

3)

Quote:1. Try using the multimedia timer API to set the timer resolution to 1 ms. This changes globally when any program requests it, so this is already happening on my end for whatever reason. You can use this to check: https://www.lucashale.com/timer-resolution/

TimerResolution doesn't let to set exact number you need. The "Maximum" button sets it to 0.496ms on my system, "Default" to 0.997 ms. https://i.imgur.com/cmisetq.jpg
Doesn't solve the problem, the artifact is still there at 120Hz, 180Hz, 240Hz.

4)

Quote:2. Use LatencyMon to see if there are any DPC latency issues: https://www.sweetwater.com/sweetcare/art...cy-issues/

Here's the results. Didn't have time to go through it yet but sharing with the result of the post content here. https://e.pcloud.link/publink/show?code=...CmYugPGSzX

I'm not sure what this will help, even you say you see the artifact occasionally on your system.

5)

Quote:3. Try starting the program with high priority and see if that changes the results: https://superuser.com/questions/699651/s...h-priority

I did, no difference.

6) What do you think about getting a 240Hz HDMI capture card and checking the captured 240Hz video instead of the un-synced 480Hz camera capture?

7)

Quote:CRU doesn't change anything on the display's end, so running reset-all.exe and rebooting would reset everything back to default.

I feel like after reboot some old settings like non-standard refresh rates unused and deleted for a long time keep coming back. Where are these settings located on the PC? I could try also deleting them manually.

8)

Quote:Another factor is the laptop screen and the external monitor might be using different timing parameters. Normally this shouldn't matter, but if there is a frame timing issue somewhere (not necessarily in your code but possibly a graphics driver or hardware bug), then it's possible certain timing parameters might work better than others. It would be interesting to see if you can reproduce the problem with one display and not the other on the same system if they were using the same exact timing parameters (including resolution and refresh rate).

To be clear, do you mean anything else here besides refresh rate and resolution? From my understanding blanking depends on the specific monitor model and can't be the same. I don't know anything else related here.


9) Finally, the interesting part, my results with 480fps recordings.
First, this is the modified program: https://e.pcloud.link/publink/show?code=...srs0f2J6dV

There's a grid a white rectangle is being repositioned in each frame, like the Blurbusters web-based tool. The white rectangle moves in each refresh only, not a fixed time interval.
The mouse cursor is set to move each 1ms. Of course visible changes to it are limited by the monitor's refresh rate. The delimeters for the mouse have longer lines where the mouse is meant to land on, the thinner lines between them are meant for the cases where the monitor refresh will be higher than the fps the program is running on, for whatever reason.

Link to the video captures:
https://e.pcloud.link/publink/show?code=...5zhYnJnmRy

"Aorus" videos are for the laptop, they lacked any visible artifact during recoridng.
"AOC" is the 240Hz monitor which has the artifacts.
I've tried recording videos with my 120fps phone camera and the 480 fps camera at the same time, although since I had to press two buttons at the same time, they are not perfectly synced. The 120fps recordings show the artifacts as you'd see them with your eyes, at least for the 240Hz recordings.

"480fps recording - aoc 180hz.MOV":

In all below frame ranges, we can see the mouse cursor (which is positioned every 1 millisecond) skipping a position while the white bar (which is positioned every refresh) stays in place longer than expected. Similarly the background color in the top of the frame also stays the same longer than expected. The white rectangle doesn't skip cells, just stays longer than expected:

1) 00:03:58,02 - 00:03:58,07
2) 00:04:04,09 - 00:04:04,18
3) 00:05:37,18 - 00:05:37,29
4) 00:06:12,14 - 00:06:12,19


"480fps recording - aoc 240hz.MOV":

Mouse cursor doesn't skip positions and does move, but delayed, and the white rectangle stayes longer than unusual in the cell it was in at:

1) 00:00:06,16 - 00:00:06,25
2) 00:03:23,15 - 00:03:23,16
3) 00:03:34,08 - 00:03:34,10
4) 00:03:56,19 - 00:03:56,21
5) 00:04:05,26 - 00:04:05,28

It's surprising that recording mouse movement when monitor is 180Hz and camera records at 480fps shows the mouse cursor skipping a position, while recording the mouse movement when monitor is 240Hz and the camera records at 480fps shows the mouse cursor not skipping positions, just staying longer on some. I don't know why the latter even happens.

The results are a bit confusing. If the GPU or monitor was skipping a frame, then the white rectangle would jump a cell. But it looks like that instead the GPU/graphics API is telling the program to simply wait, which the latter does patiently.
The mouse movement is also confusing. It's not tied to the refresh rate, it's in a function called every 1ms, so I have no idea why its positioning is sometimes getting stuck (in the 240Hz recordings) and sometimes skips a position (in the 180Hz recordings). If it skipped a position, and the white rectangle also skipped a position, then we could conclude a frame has been skipped, but it rather looks like the Windows OS elements skip a frame, while the OpenGL program simply pauses for a frame.

Appreciate all the help so far, literally the only place online we got any feedback at all so far.

[ToastyX]

(10-12-2023 08:22 PM)SubstantialCt8690 Wrote:  Link to the video captures:
https://e.pcloud.link/publink/show?code=...5zhYnJnmRy

The 480 FPS videos are showing up as small 30 FPS thumbnail videos for me. Can you also take a bunch of photos with a slow shutter speed instead of a video? That would make it easier to see what's happening.

I noticed something in the 240 Hz videos. In the Aorus video, the one that doesn't repeat frames, the FPS counter stays consistent around 240 FPS. In the AOC video, it jumps around between 235-240 FPS. This happens in the first set of videos as well. This means the issue with the AOC at 240 Hz is happening on the PC's end for sure because the FPS counter is able to detect it. Also, it looks like the AOC's own frame counter is enabled in the monitor, and it's showing a consistent 241, which also means the issue is happening on the PC's end for sure. Was this with G-SYNC/FreeSync enabled or disabled?

(10-12-2023 08:22 PM)SubstantialCt8690 Wrote:  Understood. So if it's receiving the same frame twice, one would assume it skips a frame after it (shows 1,1,3..)?

Not if the program doesn't take missed refreshes into account.

(10-12-2023 08:22 PM)SubstantialCt8690 Wrote:  The results are a bit confusing. If the GPU or monitor was skipping a frame, then the white rectangle would jump a cell. But it looks like that instead the GPU/graphics API is telling the program to simply wait, which the latter does patiently.

This is exactly what I expect would happen if the program is missing refreshes. The test program is refresh-based and not time-based, so the rectangle positions and frame counter only update after each refresh, but if it misses a refresh, then the updates are also delayed until the next refresh, and the last frame is displayed again.

The timeline would go something like this:

Refresh #1: Present frame #1, wait for next refresh, output frame #1
Refresh #2: Present frame #2, wait for next refresh, output frame #2
Refresh #3: Something happens that causes the program to miss the next refresh, output frame #2 again
Refresh #4: Present frame #3, wait for next refresh, output frame #3

Using a millisecond timer instead of a frame counter would help you see how much time passed between frames (although you would have to move the timer every frame to avoid blending the numbers), and drawing something that is positioned based on the millisecond time would show a gap if it missed a refresh.

I should also mention that monitors refresh from top to bottom, so it's possible for a video frame to show the top of the new frame and the bottom of the previous frame, and this would blend together somewhere in the middle because of the pixel response times of LCD monitors, and then the camera's shutter speed might blend together yet another frame. That's why I want to see photos with a slow shutter speed and moving squares so I can see several frames of data at once without overlapping.

There's a lot of things to consider when writing a test program. I wanted to make a monitor lag testing tool that would draw moving vertical bars with interpolated timers in them so you could see exactly where each monitor is refreshing and time the lag difference, sort of like this but with timers in the bars: https://www.monitortests.com/monoprice-2...-large.jpg (the monitor on the left is lagging one frame)

(10-12-2023 08:22 PM)SubstantialCt8690 Wrote:  The mouse movement is also confusing. It's not tied to the refresh rate, it's in a function called every 1ms, so I have no idea why its positioning is sometimes getting stuck (in the 240Hz recordings) and sometimes skips a position (in the 180Hz recordings). If it skipped a position, and the white rectangle also skipped a position, then we could conclude a frame has been skipped, but it rather looks like the Windows OS elements skip a frame, while the OpenGL program simply pauses for a frame.

The mouse movement is still being done in the same program. I'm not familiar with Panda3D, but the docs say all tasks execute in the same thread, and I'm not sure how precise the timing is for tasks.

Anyway, forget the mouse cursor for now. Instead of moving the cursor, try drawing something positioned based on the millisecond time (not an incrementing counter), so you can see a gap when it misses a refresh. Then the question becomes why is it missing a refresh?

(10-12-2023 08:22 PM)SubstantialCt8690 Wrote:  What do you think about getting a 240Hz HDMI capture card and checking the captured 240Hz video instead of the un-synced 480Hz camera capture?

That would work in theory, but I've seen TV capture cards do stupid things, often in software, so I'm not sure about HDMI capture cards.

(10-12-2023 08:22 PM)SubstantialCt8690 Wrote:  I feel like after reboot some old settings like non-standard refresh rates unused and deleted for a long time keep coming back. Where are these settings located on the PC? I could try also deleting them manually.

That shouldn't be the case. Search the registry for EDID_OVERRIDE.

(10-12-2023 08:22 PM)SubstantialCt8690 Wrote:  To be clear, do you mean anything else here besides refresh rate and resolution? From my understanding blanking depends on the specific monitor model and can't be the same. I don't know anything else related here.

I mean literally every parameter shown in the detailed resolution window including blanking, not just the resolution and refresh rate. Most monitors can handle a range of values, so usually it's possible to get two monitors to use the same timing parameters, but not always. If the AOC has the problem but not the Aorus, see if the Aorus timing parameters work with the AOC. They could be the same already because most monitors use the same few standards, but sometimes they use non-standard timing parameters.

[SubstantialCt8690]

Hello,

Here's a partial response until a fix the test program to do what you described.

Quote:The 480 FPS videos are showing up as small 30 FPS thumbnail videos for me.

That's normal. The Exilim camera can only record at 480 fps at low resolutions. It saves the videos as very slow 30 fps videos instead of 480fps videos but the 30 fps video files have all the recorded frames, so you can actually watch it and see each recorded frame on a regular <=240Hz monitor.
The resolution is still enough to clearly see the mouse location and the grid and in which of its cell the white square is in.
I've timestamped where the artifacts happen in my post above, I myself use a free video editor called KDEnlive to navigate to those problematic frames.

Quote:Can you also take a bunch of photos with a slow shutter speed instead of a video?

I can't, it's impossible to capture the artifact exactly when it happens as it's just few dozen milliseconds long and happens randomly, and I don't have a camera which can do burst photo for few seconds.

Quote:That's why I want to see photos with a slow shutter speed and moving squares so I can see several frames of data at once without overlapping.

Please see the 480fps videos already shared, the resolution is bad but still very sufficient to see the squares and mouse cursor position clearly.

Quote:Most monitors can handle a range of values, so usually it's possible to get two monitors to use the same timing parameters, but not always. If the AOC has the problem but not the Aorus, see if the Aorus timing parameters work with the AOC. They could be the same already because most monitors use the same few standards, but sometimes they use non-standard timing parameters.

I tried this, and you're right that the AOC could work with the values of the laptop display (which were different, btw), but it had no impact on the artifact.

Quote:I noticed something in the 240 Hz videos. In the Aorus video, the one that doesn't repeat frames, the FPS counter stays consistent around 240 FPS. In the AOC video, it jumps around between 235-240 FPS. This means the issue with the AOC at 240 Hz is happening on the PC's end for sure because the FPS counter is able to detect it.

With both monitors the fps counter of the Panda3D game engine is not consistent, maybe more so on the AOC monitor in these videos. But the AOC monitor's own frame rate meter always seems to stay at 120, 180 or 240 (241 now, for some reason).
I don't know how reliable and accurate each counter is. Panda's frame counter specifically is there for 3d performance analysis reasons. Not sure if anything can be derived from the frame counters.

Quote:it looks like the AOC's own frame counter is enabled in the monitor, and it's showing a consistent 241, which also means the issue is happening on the PC's end for sure. Was this with G-SYNC/FreeSync enabled or disabled?

Tests have been performed both video the freesync enabled and disabled. In these tests specifically, it's disabled.
I'm not sure when the monitor counter started showing 241 instead of 240, but it's a new thing. This is why I think the CRU isn't resetting the monitor settings properly, since now it remains like that even when resetting monitor settings and rebooting.

Quote:Refresh #3: Something happens that causes the program to miss the next refresh, output frame #2 again

Sounds like you're saying the graphics pipeline can request the 3d program to output the same frame again, without the 3d program being programmed to do so. Or you mean the 3d program simply sits and waits while the graphics pipeline or the GPU outputs the same frame again.

Quote:I should also mention that monitors refresh from top to bottom, so it's possible for a video frame to show the top of the new frame and the bottom of the previous frame, and this would blend together somewhere in the middle because of the pixel response times of LCD monitors

Sure, but both the mouse cursor movement and white rectangle movement is horizontal, so I don't think this will cause an issue with test result analysis.

Quote:Using a millisecond timer instead of a frame counter would help you see how much time passed between frames (although you would have to move the timer every frame to avoid blending the numbers), and drawing something that is positioned based on the millisecond time would show a gap if it missed a refresh.

We'll do that. I tried with Python already but python's threading isn't cut out for the job.

[ToastyX]

(10-13-2023 07:29 PM)SubstantialCt8690 Wrote:  Tests have been performed both video the freesync enabled and disabled. In these tests specifically, it's disabled.
I'm not sure when the monitor counter started showing 241 instead of 240, but it's a new thing. This is why I think the CRU isn't resetting the monitor settings properly, since now it remains like that even when resetting monitor settings and rebooting.

CRU only creates EDID overrides, which only describes what a monitor supports. If there are no EDID_OVERRIDE keys in the registry, then there is nothing left over. The frame rate counter on the monitor might round differently with G-SYNC/FreeSync enabled vs. disabled. The frame rate on the monitor will be steady if it is disabled because the GPU always sends what's in its frame buffer every refresh, but if it's enabled, the length of the vertical blanking period can vary, so it's best to test with it disabled until we can solve that problem first.

(10-13-2023 07:29 PM)SubstantialCt8690 Wrote:  Sounds like you're saying the graphics pipeline can request the 3d program to output the same frame again, without the 3d program being programmed to do so. Or you mean the 3d program simply sits and waits while the graphics pipeline or the GPU outputs the same frame again.

I mean the program is waiting either because the CPU happens to be busy with something else long enough to miss a refresh, or something is blocking the graphics pipeline.

I have two ideas to try:

1. Try adding a millisecond delay after presenting. I remember having to do that to avoid stuttering with vsync when dealing with graphics but I couldn't figure out why.

2. If you have access to a computer running Windows 7, try changing the theme to Basic or Classic to disable the Desktop Window Manager (DWM). Windows 8 onward force DWM to be active all the time, so maybe there's a graphics timing issue related to that.

(10-13-2023 07:29 PM)SubstantialCt8690 Wrote:  We'll do that. I tried with Python already but python's threading isn't cut out for the job.

You don't need threading for the timer. Just draw a vertical line positioned horizontally based on the current millisecond time, so if the time in seconds is x.123, it would draw a vertical line at the 123rd pixel, or multiply by 2 if you want. Then you can see visually when every frame happens. If the program misses a refresh, there will be a gap, and you will know for sure this is happening on the PC's end.

I might make my own test program, but dealing with DirectX or OpenGL is such a pain without third-party frameworks. It's hard to trust third-party frameworks when making a test program because I have no idea what it might be doing. Maybe I can do something with just GDI since I don't need to do GPU-intensive drawing anyway.

[SubstantialCt8690]

(10-16-2023 11:19 PM)ToastyX Wrote:  CRU only creates EDID overrides, which only describes what a monitor supports. If there are no EDID_OVERRIDE keys in the registry, then there is nothing left over. The frame rate counter on the monitor might round differently with G-SYNC/FreeSync enabled vs. disabled. The frame rate on the monitor will be steady if it is disabled because the GPU always sends what's in its frame buffer every refresh, but if it's enabled, the length of the vertical blanking period can vary, so it's best to test with it disabled until we can solve that problem first.

Okay, freesync has been disabled for quite a while, before I messaged you the first time.

So far so good, recent CRU reset seems to be preserved all day.
This is the thing: The default AOC monitor values show 239.964Hz instead of pure 240. But the game engine frame counter and the monitor's on-screen graphic timer show 240 in this case.

If I create a new entry in CRU and specify 240Hz, the monitor frame counter becomes 241.

But both settings result in zero artifacts and stable 240Hz performance with one laptop's display panel. And both settings result in frame repeating artifacts with the AOC monitor (although the first one shows 240 in teh counter, the second one shows 241).

(10-13-2023 07:29 PM)SubstantialCt8690 Wrote:  I have two ideas to try:

Will try both and report back.

Quote:2. If you have access to a computer running Windows 7, try changing the theme to Basic or Classic to disable the Desktop Window Manager (DWM). Windows 8 onward force DWM to be active all the time, so maybe there's a graphics timing issue related to that.

I think in Windows 8+ DWM is disabled for programs in fullscreen mode and mouse rendering has handed to the program, is it not? If not, then Windows 7 test makes sense.

(10-13-2023 07:29 PM)SubstantialCt8690 Wrote:  You don't need threading for the timer. Just draw a vertical line positioned horizontally based on the current millisecond time, so if the time in seconds is x.123, it would draw a vertical line at the 123rd pixel, or multiply by 2 if you want. Then you can see visually when every frame happens. If the program misses a refresh, there will be a gap, and you will know for sure this is happening on the PC's end.

Haven't checked in pure DirectX, but with a game engine this doesn't work well. The game engine loop takes over the main thread and the engine loop operates by frame-by-frame basis. If you try to add a custom time-based functionality there, sometimes it gets pushed to the next frame, checking the output log of the timing, I was seeing some intervals taking twice as long as the frame duration itself an not very rarely. And when the engine (and therefore the main thread) stops rendering for a moment and waits a frame, I can't run any code in the same thread. This is where the need of a separate thread comes in.

Quote:I might make my own test program, but dealing with DirectX or OpenGL is such a pain without third-party frameworks. It's hard to trust third-party frameworks when making a test program because I have no idea what it might be doing. Maybe I can do something with just GDI since I don't need to do GPU-intensive drawing anyway.

The programmer I work with is a engine programmer using DX and C++. I've asked him to convert my Panda3d Python code to pure DirectX in C++. I'll share it here when it's ready. Mine had timing that worked fine 95% of the time which is not enough for this.

[SubstantialCt8690]

Hi Toasty,

So I wanted to let you know that we've been busy investigating this, just didn't have an update.

Here's the latest DirectX test program executable and sourcecode.
https://e.pcloud.link/publink/show?code=...vaYkjPiS4k
https://e.pcloud.link/publink/show?code=...meBS4pSi2y

The test program provided is meant to illustrate, that even when just a blank frame (with a different color each time) is presented each frame, there’s still an alarming number of repeated frames at the monitor (every 30 seconds or so) with our test laptops (HP Victus 15 2022 model, Aorus 15G-XC, Asus G752VS) even at 120Hz. Here’s the laptop logs, together with a spreadhseet of the results: https://e.pcloud.link/publink/show?code=...ARSzAsp1Xk

Blue-red alternating colors is just for the test and is a good way to visually notice the issue clearly as it happens and in a video camera capture. They are easier to spot during testing than stutters, although stutters are still visible themselves.

Here’s video camera captures of the test program on our devices.
https://e.pcloud.link/publink/show?code=...1P9VsE03S7
(recorded with two cameras simultaneously, one 120fps and one 480fps, logs text files show the offending frame indexes)

Here’s few GIF animations I’ve generated from the videos, of just the few frames where the frame repeat happens. https://e.pcloud.link/publink/show?code=...jMfXElz7T7


To summarize what the test program does:

2 grids have white cards moving each frame, mouse cursor is also moved each frame (use Atl+F4 to close program). Top grid card and the mouse cursor, unlike the bottom grid card, compensate for the repeated frame as soon as the program becomes aware that it has occurred.

When a frame repeat happens, you notice both the white cards and mouse cursors freezing in place, then:

1) The mouse cursor jumps a position to compensate for the repeat.

2) The top card moves a cell, only later jumps a cell to compensate. This is because the next frame was already presented to the GPU and the 3d program couldn’t recall the next presented frame when it learned that the current presented frame had been repeated.

3) The bottom white card just resumes moving as usual, as it has not been programmed to compensate its position due to a frame repeat.

I’m sure you’ll agree that it’s not okay for the end user to experience this every 30 seconds or so on modern gaming laptops and at as low as 120Hz.


We are simultaneously testing the code using the Nvidia VRWorks API, which is meant for VR and in theory should bypass DWM. We experience the issue with and without using VRWorks. Since VRWorks API requires an NDA and needs an edit to the Windows registry to work with normal monitors, I am only supplying the pure DirectX version of the program to you for testing.
We also tested the program on an older PC running Windows 7 to bypass DWM via dwmapi.h. We also tried to just setting the theme to classic as you suggested.
The artifacts were still there.
So the issue does not seem to be related to DWM.

Quote:1. Try adding a millisecond delay after presenting. I remember having to do that to avoid stuttering with vsync when dealing with graphics but I couldn't figure out why.

Tried this as well, issue remained.



To clarify, the issue is not merely that only one frame sometimes stays longer / is displayed twice the duration than it should. There’s actually 2 mis-timed frames when this happens. The first frame gets repeated on the monitor, while the 2nd frame is already rendered and presented to the GPU and is displayed at the time slot of the 3rd expected frame (counted as 3rd if no repeating were to occur).

And often times, the frame is actually repeated twice or more in sequence, not just once.


DirectX SetFullscreenState does not seem to prevent the issue from happening. Maybe we we somehow are still not in "true fullscreen" and there’s an alternative way to enable that?


Going one step ahead: are you aware if there is any way to query the GPU or some other way determine a frame repeat is happening, before the repeating finishes? And/or is there any way to recall a presented frame or some other way halt the streaming of frames to the monitor when a frame is repeated once but hasn’t started streaming the next presented frame yet? This will at least solve the issue of a frame repeated more than once and prevent later presented frames from being displayed later in time than they should have.

[SubstantialCt8690]

Just FYI, I did post the same question on BlurBusters over 2 weeks ago but haven't gotten any comment.

[ToastyX]

I think your thread is getting missed because you posted in the General forum instead of the Software Developers / Low-Lag Code / Game Programming forum. Maybe you can message Chief Blur Buster (Mark Rejhon) since he's the expert on this.

I still think it's a scheduling issue, so vsync might cause a missed refresh if the CPU happens to be busy with something else. The only way I can think of to get around this is to disable vsync, and then busy wait and time the vsync yourself using D3DKMTGetScanLine or some other method to determine where the refresh is happening, but this will waste CPU cycles on one core.

He talks about this stuff in his beam racing threads, which require precise timing to pull off:

https://forums.blurbusters.com/viewtopic...=22&t=3972
https://forums.blurbusters.com/viewtopic...=22&t=4213