>It's not hard for me to understand, as input lag is accumulative, and thus, with enough samples, button-to-pixel testing methods (when properly executed), should reflect all contributing factors as a whole in the final results.
not only is it accumulative, it can be and is bottlenecked by multiple factors in the entire chain, number of samples doesnt matter if the method of testing is flawed and/or lacks necessary resolution, not to mention understanding of the entire chain. benchmarking is hard, making sure you are benchmarking correct is even harder
>Again, if done properly, and so long as it is outside the noise threshold of the testing method, it should show as part of the whole in the results.
it will show, but as you said, it needs to be measured properly(good equipment/good resolution/accurate measures), and on a proper setup for that specific measure (tuned/optimized F1 racing car, not a family power saving car)
>I'm aware that any possible RAM performance improvements via tuning/overclocking are accumulative and dependent on the whole health and optimization of your system across the board, software and hardware. I still don't see how this exempts any possible latency reductions via RAM tuning from being detectable by button-to-pixel testing methods (unless they were incredibly tiny, which admittedly wouldn't be great for your position on the matter). Again, it would simply be difficult to confirm attribution of it directly to the RAM in all cases.
In this entire thread I have never said its not visible. I have however said that due to wrong method on wrong subject (unoptimized) the results will be flawed and innacurate, although still there, in case of very bad testing method being performed they will be fully innacruate and wrong. RAM performance improvements for lower RAM latency are not accumulative, they are chrono-exponentional. Meaning, they scale with their space counterpart exponentionally by their time factor (latency). Like speed of light and Lorentz factor (
https://en.wikipedia.org/wiki/Lorentz_factor ). Meaning that RAM latency scales with how RAM read/writes are used, together with how much load there is on ram, what type of commands are scheduled (reads/writes), what the access patterns are, what the CPU caches are, what the OS is doing with interrupts/DPCs, what the OS is doing with thread scheduling, what the OS is doing with power saving things, and many other things that would take up entire page to write down. So that RAM latency is "accumulative" is a heavy understatement of what RAM latency affects.
>You're preaching to the choir. I had phases where I fixated on all these aspects, and (subjectively) tested extensively, only to find, for
me personally, it was a case of diminishing returns.
i am defending the truth and helping people lower their input lag as this is the goal of this subforum. i fail to see how tuning your system once that should even in most extreme cases take a week is a diminishing return if you will no doubt use it 3+ hours a day for atleast a year.
>As for CR1, in
my experience, this can reduce CPU overclock stability and sometimes greatly increase CPU temps when compared to stock CR2 (especially when you're overclocking CPU and RAM at the same time), and really isn't worth risking unless you know what you're doing (and most don't).
Well yeah, if you want to drive a F1 and go fast you need to know what you are doing, CR1 having effects on CPU overclock and other things is obvious since now your RAM uses your CPU IMC far more.
>That said, I'm not knocking your perspective or your claims. None of us here ("us" being everyone other than you) can
100% definitively know how much (or if) RAM tuning impacts input lag to a measurable degree over the whole latency chain. Many of us are just saying that it's too niche, inaccessible, and unisolatable to prioritize vs. the more immediate and obvious input lag reduction other avenues create, such as disabling V-SYNC, or to a lesser degree, reducing the pre-rendered frames queue, or even more simply, lowering settings and/or upping system specs to increase the average framerate.
Its not too niche since all the things you mentioned in that sentence are all affected by RAM latency, since it sits inside the base layer of how computers work. Its exact opposite of too niche, its too important to not do it since it affects EVERYTHING. there is no point in trying to chase lower latency through things that sit on layer 2/3/4 rather than primary layer. Its like trying to smash your head harder and harder to open the door instead of using the door knob.
>I think what you should ask yourself at this point is, what's your end game? What are
you going to do about it that you haven't already done?
My endgame is to raise awareness of the ongoing low quality engineering either for monetary or any other gain about RAM latency affecting input lag and help people get most of their systems. To do some lab work and collect evidence I need to have someone to present it to however being labeled mentally insane and other terms such as "placebo" is very insulting when i provide hard evidence from computer engineering pioneers rather than my own thoughts.
I dont really care about G-Sync, its a power saving feature of monitors due to serious lack of great quality software architecture/game developers as well as consumer hardware power saving features and other profit maximizing things.
I am not advocating anything, so far all I have provided were cold hard evidence from computer architecture, nothing I said was my opinion, and yet still people refuse to accept the objective raw truth presented due to lack of knowledge or other social fears it may result in. Although the few people in this thread who did the timings however far from perfect and reported back with claims that difference it makes is amazing show there is hope for people listening.