• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

Weird gpu memory clock issue 1080Ti [solved]


Staff member
May 28, 2005
4,574 (0.91/day)
Southampton, UK
System Name Raisin
Processor Ryzen 7 1800X
Motherboard Asus prime B350 (Crosshair VI Hero swapped out temporarily)
Cooling 2x 240mm rads, Corsair ML fans, EKWB pump/res and GPU block. XSPC Raystorm pro CPU block
Memory G.Skill TridentZ DDR4-4266 16GB @ 3333MHz CL14 1T
Video Card(s) EVGA 1080Ti FE. WC'd & TDP limit increased to 360W. 2076mhz/6200mhz
Storage Samsung 960 Evo 500GB + Corsair 120GB ssd (linux) + WD Black 2TB storage drive.
Display(s) Asus ROG Swift PG278QR 27" 1440P 165hz Gsync
Case Phanteks Enthoo Pro M
Audio Device(s) Phillips Fidelio X2 headphones / basic Bose speakers
Power Supply EVGA Supernova 750W G3
Mouse Logitech G602
Keyboard Cherry MX Board 6.0
Software Win 10 & Linux Mint 18.3
Benchmark Scores https://hwbot.org/user/infrared
I'm a bit confused here, most monitoring software seems to report the memory clock on my 1080Ti incorrectly. AFAIK the default memory clock should be 1376mhz, in Afterburner, GPUZ Sensor tab & HWInfo all show it as 1250mhz, the only place I see it being reported differently (1376) is the GPUZ front page (although the GPU clocks are wrong on that tab).

In afterburner when initially opened or clocks reset to default, it always shows memory at 5000mhz/1250mhz. I can go up to the max +1000mhz without losing stability, it appears as though the +1000 (250mhz actual) gets applied correctly, and software will now show 6000mhz/1500mhz. I think this is actually doing 1376 + 250 for 1626mhz.

Driver version 399.24, latest AB, latest GPUZ. Older versions were showing the same.

Any ideas? Help would be appreciated :)

stock clocks.jpg

Edit - I'm downloading a driver 416.34 to see if that changes anything, will update shortly.

Edit2 - Well that was weird, after installing the fresh drivers it was initially all reporting correctly, and memory clocks were dropping at idle instead of holding 3d clocks like it was previously.. I started upping the memory frequency while running heaven, at somewhere around +800mhz it bluescreened, and after rebooting is now exhibiting the same issues as before.

I wonder if that means it really has dropped the memory clock to 5000(1250) instead of 5500(1376), which is why +1000 was stable. Whereas pre-crash on fresh drivers it was at 5500(1376) and therefore +1000 was too much. I don't know why a reboot doesn't reset it though, very odd.

Edit 3 - Just reinstalled 416.34 again, cleaned with DDU first, AAAAND it didn't fix it this time, still stuck on incorrect clocks since crashing earlier. This is so weird :( I give up for now.

So just to summarize, since this has got a bit packed with edits..

After a failed OC on the memory of my 1080ti (too high, causing blue screen). After the system restarts it is permanently at 5000mhz in AB, so that's 500mhz UNDER what it should be, and also it's locked at that frequency and not dropping to 2D clocks.

Restarting doesn't correct it,
going from driver 399.24 to 416.43 did correct it, after which it's at 405mhz under no load and 5508mhz under load.
The same thing happened after nudging up the memory frequency again.. this time reinstalling 416.43 did not fix it. Maybe only installing a different driver fixes it?

I'll keep playing around.

Okay, back to normal after installing the driver for the 4th time. I don't even know why sometimes this works and sometimes not. I think I'll be careful to stay below +700mhz memory to avoid this happening again.

Here's the correct behavior:
Idle - Stock load - +700 load
correctidle.png correctloadstock.png correctloadoc.png

Is this like a safemode or something? Go too far on memory frequency and it drops the memory clock by -500mhz? So annoying how that state persists.

Found it! It went into that weird state again.. I found the service/process causing it, a service installed with solidworks, "swvisualize.boostservice.exe"/VizBoostService. Closing this causes the clocks to drop back to normal. Things are still fine after a restart but it's likely going to do it again, so I think I'll change the service startup to manual.

Last edited: