Blur Busters Forums

https://github.com/BoringBoredom/PC-Optimization-Hub

This is meant as a general guide for people who are starting their latency journey. Test things on your own and judge for yourself.

I can say there's decent tips and tricks there (At least as of 2020/12/08). Hope it remains good quality.

(I presume this is your content)

When I first saw 'r0ach' I basically clicked away. (Not that I personally see any gain by reading such articles, perfectly capable of performing optimizations myself)

It's a bit similar to all those 'gaming optimization' communities on discord with their competitive discord servers where mostly children reside that have no clue what they are doing, under the leadership of some cultist leader which has trouble with correct english himself, and often create these dubious 'game tools' to optimize windows by basically just making use of built-in windows configuration features.

The fact that most of these so called optimization guides have some truth and fact in it purely because there's so much information clogged up, the chance of some elements exist that are either 'good' or 'correct' is relatively probable.

Other elements look really not-obvious yet they really are; The more you eliminate the less issues and contention / distortion / conflicts you will experience (In general), so performance, latency can benefit from that.

But until these claims are all either proven (if not already by others), I'd take much of with a grain of salt.

Ofcourse there's also the placebo effect and the 'it can't hurt so might as well' philosophies.

Very hypocritical coming from someone with an "optimization script" linked in his signature I explicitely mentioned "Test things on your own and judge for yourself." because I don't agree with everything but for the most part the resources are very useful.

MT_ wrote: ↑

09 Dec 2020, 17:33

The fact that most of these so called optimization guides have some truth and fact in it purely because there's so much information clogged up, the chance of some elements exist that are either 'good' or 'correct' is relatively probable.

This be true, and even this forum area admittedly is mixed between the "out there" stuff and the "real stuff".

Our philosophy is that we welcome discussions from the various "Milliseconds Matters" communities. Some ideas are placebo while others are really legitimate, and sometimes what was formerly placebo ends up becoming real (like 1000Hz mice was 15 years ago, and the discussions around the benefits of new 8000Hz mouse).

As articles such as The Amazing Human Visible Feats Of The Millisecond now genuinely illustrates, we're familiar with "death-by-a-million-nanoseconds" -- when a system gets so bogged down with noisy buses and all, it starts really jittering things.

As display refresh rates go up, things become human-visible above the noisefloor, thanks to the "Vicious Cycle Effect". Certain effects that take less than a millisecond are now much more human-visible than they used to be twenty years ago because it is amplified by "lowblur + high-resolution + high-refreshrate" that was never simultaneously possible before.

Hey, higher refresh rates were once passed off as placebo, but virtually everyone with 240Hz+ monitors, see the benefits of higher refresh rates, even if they complain about the cons (color quality, slow pixel response, etc). And the audacious idea that a strobe backlight eventually allowed certain LCDs to outperform OLED/CRTs in motion blur (whether it be 119Hz PureXP+ Ultra or the the Quest 2 crosstalkless 0.3ms LCD VR strobe).

With a researcher mind too, one has to be cognizant that there is a lot of unproven stuff that needs a lot of proving. Eventually proof pops up here and there for some things and not for others. Thus we like to keep these kinds of topics open, although I want to keep rivalries out, and stick to the Blur Busters "Be Nice" rules (reminder to you two, and no retaliation, please). There can be a lot of extreme stuff going on in these communities, and sometimes we have to cherrypick what really works from what doesn't work.

Now, as much as some high enders may rivalry around, Blur Busters Forums is meant to also be a generally safe place for newbies too -- unabashedly so.

MT_ wrote: ↑

09 Dec 2020, 17:33

The more you eliminate the less issues and contention / distortion / conflicts you will experience (In general), so performance, latency can benefit from that.
[...]
'it can't hurt so might as well' philosophies.

...and...

Brainlet wrote: ↑

09 Dec 2020, 18:29

"Test things on your own and judge for yourself." because I don't agree with everything but for the most part the resources are very useful.

See! You both sort of agree there a room and place for various potentially-obscure optimizations -- although with different mindsets/respectfulnesses in how the guides are approached. Yes, one take personal issue at a different word/phrase in the same post, but if you ignore and read the most sensible favourite sentence in other parts of the posts -- you see the essential agreements admist the the fog of disagreements. Fine, people bicker/argue/fight, but there's always room for agreement. We're fans of the same technology devices (aka computers) after all.

Anyway, these forums welcome people to try these things out (at own risk) and generate useful provable statistics/data that can help lift all boats of computer optimization. Just be tactful/respectful in those "it works" vs "it doesn't work" disagreements and posts.

Carry on, though stick to Blur Busters worthy discussion.

As monitor refresh rate goes up and mouse sensors allow higher DPIs humans also start to notice smaller latency differences. There is no doubt that humans can notice a 1ms latency difference in dragging tasks (yes, dragging a mouse across the pad to move a cursor on the screen is very similar to drawing tablets, except you don't get to directly see how hard the cursor lags behind). When it comes to "placebo" it should always be kept in mind that depending on hardware and configuration the impact might not be significant enough compared to the total system latency to have a very noticeable effect, resulting in "placebo". And of course, it might also just be placebo but you will never find out without eliminating bigger latency bottlenecks beforehand.

Excellent links!

Brainlet wrote: ↑

09 Dec 2020, 20:31

And of course, it might also just be placebo but you will never find out without eliminating bigger latency bottlenecks beforehand.

Also, occasionally in situations where it is hard, sometimes a slight amount of latency to add smoothing becomes necessary -- people who use things like RTSS Scanline Sync to get perfect frame pacing, slightly more lag than VSYNC OFF but lots less lag than VSYNC ON.

Such tradeoff decisions in optimization are now continually being made. Also, for example, in virtual reality where you might need, say, 1ms of better movement-processing in order to better perfect 1:1 vertigo sync between real life motions and virtual motions. Sometimes engineers are confronted with a decision between "1ms tape-delayed-but-perfect vertigo sync" versus "0ms-delayed jittery motion that is dizzying/nauseous" from the VR movement sensors, etc. Such tough compromises occur when displays become bigger, more realistic, and more immersive (or even strapped to a face).

We believe in letting users decide how to optimize (latency priority, smoothness priority, compromises, etc), since sometimes they are opposing optimization goals for certain settings.

<Future Talk>
Also, the discussion about the potential High Definition Mouse API now recommends sensor-side timestamping, as a workaround to avoid pollrate overheads from eating up CPU cores (e.g. 8KHz-20KHz sensorreads embedded into 2KHz poll rate).

Basically, with the theoretical HD Mouse API for future game software (which 2 mouse vendors now liked after I emailed them about it), it is possible to have a software application receiving 20,000 timestamped sensor reads per second at only 2000Hz poll rate. That's still technically lower lag than 1000Hz, consumes less CPU than 8000Hz mouse poll rate, while giving more mouse deltas to software than an 8000Hz poll rate, so an acceptable smoothness-vs-latency balance with both concurrently still improving. Or purists can sensor-and-poll match, if they wish.

One still get latency reductions relative to, say, 1000Hz mouse, even if not latency reductions all the way down to 1/8000sec-1/20000sec. That said, the API is flexible on the tradeoff on latency-prioritization and temporal-resolution prioritization (by giving up some of the further latency decreases).

The different use cases of smoothness-vs-latency is delicate. Esports competition prioritizes on the latency aspect, while reality-emulation (maximum motion quality) on perfect smooth 1:1 stutterfree sync with real life (whether emulating reality on a screen, TV, monitor or VR). The latency-versus-smoothness tradeoff hits lots more brick walls as we get closer and closer to retina refresh rates, and some divergences can become necessary in some use cases.
</Future Talk>

Though the above API talk is not always relevant in today's tweaking -- smoothness-vs-latency tradeoffs is already becoming a tougher optimizing job with ever higher frame rates at ever higher refresh rates.

For readers -- Know what priorities you are optimizing for (latency priority, smoothness priority), since a few percent of settings you're tweaking (e.g. 5% or 10% of them) may change, like how HPET-like settings makes certain software better and other software worse, etc.

Some of the stuff seems pretty hokey but hey, an open minded person who measures the results empirically will learn more than a closed minded person. But to do that you need actual objective tools, not "feel".

For instance, one of your links is to custom resolutions (https://www.monitortests.com/forum/Thre ... tility-CRU). I'd be very wary of that - monitors often will accept timing patterns that they are not designed for, but do bad things with them (read, buffer them and display them under supported timing with extra lag added). I'd suggest linking to the more affordable monitor lag testing tools out there:

piLagtester (~free)
piLagTesterPRO ($40)
Time Sleuth ($75).

Disclaimer: I'm the author of the first two (see my sig for links).

While I agree that evidence based measurements are very important I also dislike the current approach of click to photon measurements. Imagine I told you to measure your framerate by pressing a button every 2 seconds and getting back the last frametime. Even average FPS counters (which have 100% of the frametime data) are very inaccurate and don't represent what's actually going on (min/max/0.1%/1% etc). To get somewhat accurate data you would have to automate measuring every 2 seconds, 24/7 for a week or two and it still wouldn't account for realistic gameplay (static scenario, no mouse movement involved) while also missing a lot of data (and potentially being affected by the (maybe not so rare these days) EMI/power issues that occur randomly). I believe humans are more qualified to detect latency improvements than simple click to photon measurements. When I first heard about Reflex Analyzer I thought the implementation would be vastly different. I expected a dedicated clock running inside compatible mice which timestamp sent packets and pass the data on all the way to the module inside the monitor which runs a dedicated clock as well which then timestamps the received data, finalizing the mouse-to-displaymodule (excluding display) latency (which would also show which packets get grouped into which frame). I am pretty disappointed to say the least.

Also, not all pixels refresh at the same time -- and there's sync technology lag behavior changes on the SAME panel, where the bottom edge can become less lag than top edge, whenever you change settings and/or strobe settings.

Also, some behaviors distorts gametime:photontime too, so you can even have more stutter for one edge of the screen than the opposite edge of the screen.