Could a CPU microcode update increase input lag? (Ivy Bridge)

[utplayer]

There was a Windows update in 2015, KB3064209, that contains microcode updates for at least Nehalem through Haswell. Shortly after its release, it has been made not available automatically, likely because of at least one known issue - the update bricks Windows specifically on machines with Pentium G3258 and i3-4010U processors. This apparently was a problem with Windows 10 early on as well, because it contained this update by default.

Anyway, because I was curious if it would change anything, I've decided to test it on a Win7 x64 machine with an i7-3770k. As expected, it bumps the microcode revision from 17 to 1B. This is still pre-Spectre microcode, so it shouldn't affect performance, and at least in my benchmarking performance is identical indeed. In my perception though when this update is installed, input lag seems to be ever so slightly higher. All that it does under Win7 is changing the mcupdate_GenuineIntel.dll in the System32 folder from a 2010 to a 2015 dated version, and it's trivial to uninstall the update and get the old microcode back upon a reboot.

I don't have any way of testing this definitively, but is there any possibility that a graphics driver could be tuning itself to the presently used microcode revision during installation, and a microcode update could throw it off somehow?

[utplayer]

Sorry for the bump, but I still think I'm onto something with this. I have since went back and forth between these microcode revisions about 10 times and always perceive the mouse to be a tad more responsive with the older one. I should also mention that I'm on a 60 Hz monitor, so maybe that exacerbates the difference a bit more than a high refresh rate screen. If anyone has an old machine like that still around I'd certainly be very interested in reports.