Re: Car V2L = Clean eletricity?
Posted: 11 May 2026, 12:21
Tried it on the car and the noise signature in MouseTester was really different. So I'm 100% sure that the electrical supply affects the components.kyube wrote: ↑30 Apr 2026, 07:33Are you using your mouse in wireless or wired mode? Depending on that, it could be either EMI causing issues to your mouse in wireless mode (can happen even in wired mode) or it can be power quality related.
Wired is ideal.
That's a bit of a excessive & misleading claim, as I assume you mean the XV252QF (360=>390Hz OC mode), which is still bound by slow G2G RT in specific transitions.
However, getting a more consistent display (OLED) would be beneficial in troubleshooting this.
This is to iron out any potential G2G RT instabilities affecting your perception.
Tried on the car and the noise signature in the mouse tester was really different. So 100% sure eletricit affects the components. In V2L the car is an isolated island, so ground do not work properly.andrelip wrote: ↑29 Apr 2026, 15:36It usually changes from day to day. Over the past few years, I’ve been really chill about it and barely active here. I even thought it was placebo, or that the 14900K had solved it. But since I moved from a modern apartment to a house, it got much worse and consistently bad. My GC rank dropped from top 20 to 16, and my Faceit level went from 9 to 6.
Same PC, and I know it could be the game routing, the new ISP provider (despite perfect reports), a Windows update, me getting older, or other factors. But now I’m really starting to believe these “dirty electricity” claims.
That's way too many variables to be able to claim it's electricity related with absolute certainty IMO.
As you've mentioned, networking is a very variable. You could try playing some offline game, with all networking disconnected, to see if you can experience these symptoms you're feeling.
If you could test multiple PCs in that specific apartment, that would be great too.
5 different rigs (different CPU+MB+DRAM; rest should be identical) for a longer time frame (6 months) should reveal a clearer picture whether your issue is rooted in that or not.
It would also help if you'd try playing on XMP off, with overclock dialed in to the extent where you aren't unstable (as vague as the term stability is)
The last 2 components are essential and most users in these forums misinterpret unstable hardware for EMI-related issues.
"Unstable" hardware isn't solely hardware which BSODs on launch, there's whole spectrum of micro-issues which it can produce.
Hardware can also become "unstable" from too much stress-testing / degradation of internals. I've recently come across someone with a X3D CPU with this (potential) culprit, as the 3D cache is sensitive.
It's why I keep on being vocal about ECC UDIMMs & AM5 being a great way to iron out potential issues in that regard.
I tried to isolate as much as I could:
- Put everything on the exact same outlet to share ground potential.
- The PC is not connected by cable to anything other than the monitor.
- Tested potential between the PCIe brackets, case screws, and everything — all show continuity and the same potential.
- Moved from Ethernet to Wi-Fi 7 on the 6GHz band.
- Switched to a fiber optic HDMI cable (though there's still continuity between the connectors, so a minimal ground loop may occur — only ~0.01V difference).
- Modified MouseTester with Claude Code to avoid garbage collector pauses, list hooks on the USB devices, and identify other devices sharing the hub.
- Also modified MouseTester to send fake mouse input from an async thread, so I can isolate failed inputs from failed input *capturing*. It ran perfectly smooth with the injected inputs, which means any oscillation I see is actually coming from the real input path — not the measurement.
- Disabled RGB, Bluetooth, and other devices sharing the USB hub.
Final test: MouseTester now fluctuates between 999.98 Hz and 1000.02 Hz. The game feels butter smooth and micro-corrections feel perfect. I also disabled idle states to rule out power saving (stable 5400 MHz). Beyond frequency × time, the X, Y, and counts graphs are really revealing too — they expose batching and jitter patterns that the frequency plot alone can hide.
My diagnosis: what many people call "input lag" is actually erratic mouse polling. Sometimes the system batches inputs, causing both delays *and* batching artifacts with interpolation — and it's even worse because the rate oscillates.
This lines up with the fact that NVIDIA FrameView reports low input lag, and that AMD's Frame Latency Meter (FLM) injects fake frames during benchmarking and the game moves really fast under it. I strongly believe many "high input lag" complaints are actually *input* latency (polling-side) rather than frametime or PC-side input lag.
Next steps: Test each fix individually to see what actually moves the needle in MouseTester — including testing *without* the ground connection. Also compare against a PCIe card that supports 8000 Hz polling (ASM3142 - waiting for it to arrive).
Additional findings: The interpolated MouseTester noise have a wave oscillating at 16ms (before and after the fix). Initially I thought it was related to the 60Hz of my electrical network, but then I tested it on the car's V2L (which is 50Hz) at both PC and Monitor and it stayed at 16ms. Then I suspected the monitor refresh rate (it was 240Hz), so I dropped it to 24/30Hz — no change. And despite the lack of precision, it's so regular that it really looks like exactly 16ms, not 16.67ms.
