It's the CPU MSR's and/or PLL feedbacks and any software which depends on them. Actual clocks do not change with these bugs, core limitations are well known by now.

Once I opened up Crystal CPUID to check my MSR values and a lot of them were totally blank (0's) where they shouldn't be at all.
It's the same with BarEdit/WPCREDIT access of NB registers, they totally whack out many times. The last time I checked that also was reading 0b for everything in the NB FID D4 register, whereas it should not be and was still running 9x multi as it showed. At those instances L3 performance and access becomes very bad and slower than stock.

If I could capture it, I'd show you some much higher MHz to show you the scale of the problem. Dilemma is, when the [fake] high MHz show up in all software the system freezes for 2-3 seconds at a time and so the PrntScrn is never saved until after it restores from freezing. The way to test the bug is to test the system on multiple boards really.

BTW what config are you now running on the GBT? Any more oc on HT, NB or CPU?