Memory OC On Nvidia Wrong Values

[SimpleHeuristics]

RTX 4090 default memory clock is 10500MHz for 21gbps. To get to 12000MHz as reported by MangoHud I have to move the slider to 13500MHz. If I slide it to 12000 the vram clocks only get to 11250MHz so +750.

I was using a command line utility prior to LACT implementing NVML and also had to set an offset of 3000MHz which is I guess the actual double data rate to get 24gbps.

[ilya-zlobintsev]

LACT uses the same NVML offset functionality under the hood. So it's expected that the behaviour is the same.

There are no mentions in nvidia's documentation regarding if the clock offset value is double data rate or not. But if the offsets are reported in single data rate and the clockspeeds in double, then this would make sense, and LACT should automatically double the actual offset value for memory.

I will investigate this further, as always applying this rule might not be correct for VRAM types other than GDDR6.

[Bulletdust]

I'm also noticing some oddities regarding Nvidia memory overclocks running an RTX 2070S.

If I set a frequency of 7019 MHz under LACT, MangoHud reports a memory frequency of 7009 MHz.

[ilya-zlobintsev]

I've added a workaround for this in 740e388, now the offset will be automatically multiplied by 2.

Unfortunately these seems to be no information regarding this or how to even detect the type of memory a card has, so for now it's just hardcoded to double the offset only on geforce 40 series cards. The list can be expanded if someone confirms other generations that exhibit this behaviour.

Note: the memory clock setting will get reset after updating to avoid instability due to applying an offset that's double the old value.

[SimpleHeuristics]

Looks like this might need to be re-opened for the 570.86 drivers as the behaviour of NVML looks like it changed again. Not only that it changed for clocks too it seems, at least for LACT.

After updating to this driver my profiles remained intact, but the sliders jumped

Essentially the +1500MHz VRAM Offset has set itself to a +3000MHz VRAM Offset (10.5K -> 13.5K instead of 12.0K)

Using mangohud in game it still reports the correct offset of 1.5K and final frequency of 12K

The new weird thing is that the core clock offsets are now also doubled on the LACT interface. A +120MHz has become +240MHz, but in game frequencies line up with +120MHz.

As an aside, wouldn't it make more sense on the Nvidia interface to only display offsets rather than offset + some base value? I believe most windows based Nvidia OC tools usually just show offsets for the most part. The actual frequency that the core runs at is not what LACT will display, it'll vary dynamically based on the boost algorithm.

[ilya-zlobintsev]

This would make sense if they changed the interpretation of vram offset values, however lact does not alter the core offset value in any way, so this might be an unintended side effect on the driver's side.

As an aside, wouldn't it make more sense on the Nvidia interface to only display offsets rather than offset + some base value?

Yup, this would make more sense. The current UI was made for AMD which uses pure min/max clock values instead of offsets.

[ilya-zlobintsev]

With #461 the UI now has direct offset configuration, including being able to set it for each p-state separately rather than as one global value.

[SimpleHeuristics]

That looks very good. Very granular controls. I'm sure it will also benefit people who use may use their cards for AI related work at lower power states but need the memory as fast as possible.

Shame that nvml doesn't seem to offer voltage control to push past the stock limits but there's very little gain to be had there anyways!

[sonophilos]

I'm having a similar issue, or possibly the same issue, on Bazzite 41 with the version of LACT installed by the ujust install-lact command (presumably 0.7.0)

On my RTX 3070, the base max memory clock is shown as 7001MHz - so, not doubled as it should(?) be. My target max memory clock is 8000MHz. If I enter 8000MHz in the max memory clock field and hit Apply, the value shown in the max memory clock field jumps to 8499MHz, but the max power state only goes up to 7500MHz, and this is what is displayed in system monitors and MangoHUD. The value required to get the max memory clock field to display 8000MHz is 7667MHz, but this setting results in the max power state showing 7334MHz. The value required to get the max power state to display 8000MHz is 9000MHz, which results in the max memory clock field displaying 9999MHz.

I really don't want to accidentally fry my GPU if, for example, updating this utility to be consistent in the UI results in me accidentally applying double the overclock my VRAM can take. I hope this report helps. I've enclosed my debug snapshot.

LACT-v0.7.0-snapshot-20250212-152148.tar.gz

[PcChip]

I'm having a similar issue on a 4090 with driver 570.86.16 on CachyOS

when I drag the core and memory sliders and click Apply, it seems to set a random value - sometimes higher and sometimes lower than intended. Kind of scary since I don't know how high it's actually going to go when I click apply!

running Lact 0.7.0-release (commit b818f39)

[ilya-zlobintsev]

@sonophilos @PcChip you should try out the test release, it uses newer nvidia driver functionality and it directly shows a memory offset in the ui, which is what the value being configured actually is, rather than the calculated max clock.

You will still need to have the offset value at double the effective frequency difference, that's just how the driver works.

[sonophilos]

@ilya-zlobintsev I’m not comfortable running the test release. I will leave the clock settings at stock until the test release has been tested and confirmed working on my hardware.

You specifically said you wanted feedback from users on other generations than the 40 series. I’m on a 3070, and reporting behavior that looks an awful lot like it might apply triple the VRAM OC my hardware can handle. I’m not going to be the one to test that and permanently destroy their GPU to do so, sorry.

[neon-sunset]

@sonophilos are you confusing voltage adjustment with VRAM clock setting?

[sonophilos]

@neon-sunset No. I won’t be touching voltage settings nor core clock speeds. Memory OC has a similar risk factor, which I’m starting to get the sense nobody here is taking seriously.

[neon-sunset]

@sonophilos You could easily start with a simple google search's first result: https://www.techpowerup.com/forums/threads/is-vram-overclocking-safe.263378/

The only risk is system instability, if it's something beyond visualization issue. This is also a second account in this conversation that makes this sort of claim. Whatever your (a person or a group) gripe is, please take it elsewhere. Thank you. Lastly, this is an OSS project led by a single person that requires non-trivial amount of maintenance effort. If you'd like to contribute, feel free to do so. If you're not interested - that's okay too.

[sonophilos]

@neon-sunset I saw the other hidden post, which was rude and did not address the issue I’m raising directly (which, if I understand correctly, is a display issue only). I am not part of a group with a gripe.

If you continue down the thread you quoted from the first google result a bit further than the first reply, you would see a reply saying that no modifications like this are 100% safe. Nearly every overclocking utility disclaims that the user is responsible if they cause damage to their hardware, and I acknowledge that risk in using this utility in the first place.

I simply want to make sure that I don’t actually apply a +3000MHz memory overclock if this display issue is fixed in a future version, and it actually respects the setting the UI incorrectly shows.

Are we on the same page here? I am genuinely trying to help.

[PcChip]

if you think overclocking the core or RAM can damage your hardware then you shouldn't be here

Personally I don't believe it can, since a simple reboot will set them back to stock settings and the card will be fine (unless LACT auto-applies the crazy config on login, which I have had happen before)

However, voltage increases can damage hardware

[sonophilos]

@PcChip Alright, then I guess I shouldn’t be here.

I do not understand the incredibly hostile response I’ve gotten to my concern, which I think is reasonable. I am, however, an end user with very little experience beyond gaming and trying to get the best experience out of gaming on Linux. LACT came recommended highly for that purpose. I’d like to believe I’m the target audience, or at least a demographic worth giving a shit about.

Again, I am genuinely trying to contribute here. Is anyone suggesting that my report of the display issue is not a valid contribution? Is the fact that I’m concerned about causing damage invalidating to that contribution?

I have never had this kind of an exchange with a developer or their contributors before. This is unprecedented and very unpleasant.

[PcChip]

maybe it's because your reply to the dev came off as unpleasant

[sonophilos]

I’ve revisited my first reply to the dev, and I think I see where the response is coming from. I apologize if I came across as brusque, this is an issue of mine I’ve been trying to improve on.

If that first reply to the dev had ended at the first sentence, would we have had any of this conflict? I’ve left it intact, so the replies make sense and so the dev can make their own judgment about this if they choose.

I really am trying to contribute here. If the only thing I was able to bring to the table is ‘this issue occurs on the 30 series cards also’, and you’d like me to leave it at that, I can do that.

Thank you for the time and consideration you put into this project and into addressing this issue.

[ilya-zlobintsev]

@sonophilos your concerns regarding hardware damage are understandable, but I'd like to clear up a few things up, both technical and project-related:

that looks an awful lot like it might apply triple the VRAM OC

The issue in the first place is the opposite - changing the memory clockspeed only has the effect of half the configured change for what the actual clockspeed it ends up being. This is the behaviour of vram clock offsets in the Nvidia driver. In the current latest stable LACT version this indeed looks confusing, because the value gets shown as a max clockspeed, despite in reality being an offset setting.

In the test version this was updated to show it directly as an offset in the UI (which should avoid confusion about the clockspeed not matching what the gpu actually runs at), while also allowing it to be changed per-pstate rather than as a global max value. Due to this setting being different compared to the old "max clockspeed" one, it gets reset to stock with the new update regardless, so there is no risk of the old setting starting to apply the values in a new way.

permanently destroy their GPU

Generally speaking, and as previously mentioned, clockspeed changes don't cause hardware damage - running at clockspeeds beyond normal can cause system instability, crashes and visual glitches, but won't kill the hardware. Increasing the voltage can cause damage, but custom voltages are not possible on Nvidia on Linux in the first place.

Obviously instability is still bad, which is why as I've mentioned before, the update that changes how the settings are applied also resets any existing ones to stock.

I will leave the clock settings at stock until the test release has been tested and confirmed working on my hardware.

This is a volunteer-based community project (95% of it being just me), which is why by definition there cannot be any guarantees or assurances. I do not have access to every GPU model or the time to test every possible hardware configuration (though thankfully, for the most part Nvidia behaviour has been fairly uniform across GPU generations). There might not be anyone else who will test the same exact hardware before you.
Obviously best effort is put during development into making sure LACT doesn't do anything stupid, but as a whole the "This program comes with absolutely no warranty" clause applies.

Ultimately, LACT is just a convenient way to utilize GPU driver functionality without having to write custom python/bash scripts. It does not talk to the GPU in some low-level way that would greatly risk hardware damage (e.g. custom VBIOS or power tables overrides). It simply shows you what's provided by the driver and lets you configure it, respecting reported limits.

FYI starting with the 570 driver nvidia's own nvidia-settings control panel supports clock control under wayland, so you can use that if you want. Under the hood it utilizes the same driver functionality as the test version of LACT, so it's likely to exhibit the same behaviour.

[sonophilos]

Thank you for your thorough response, @ilya-zlobintsev . I appreciate the time you took to make sure I’m better informed now than I was when I reported in.

I can confirm sudo nvidia-settings does let me change memory clock, and that the offsets appear to be double data rate - so, +2000MHz offset achieves +1000MHz as reported by system monitors and MangoHUD. The change doesn’t appear to persist through reboots, which I imagine is what I’d need a custom script for.

Edit: I've installed the test version 0.7.1 for Fedora 41 via rpm-ostree install and it appears to have correctly replaced the stable release 0.7.0 from Bazzite 41's ujust install-lact. I can now confirm the offset value in LACT does indeed have the same behavior as the nvidia-settings panel, except this setting does persist through reboots.

I acknowledge I read the part of the readme that indicated why a flatpak/appimage were not feasible for this application, and also the part of Bazzite's guide that strongly discouraged me from using rpm-ostree in this way.

Thanks again for the work you put into this, and for your considerate response here.

[BlueGoliath]

@neon-sunset I saw the other hidden post, which was rude and did not address the issue I’m raising directly (which, if I understand correctly, is a display issue only). I am not part of a group with a gripe.

If you continue down the thread you quoted from the first google result a bit further than the first reply, you would see a reply saying that no modifications like this are 100% safe. Nearly every overclocking utility disclaims that the user is responsible if they cause damage to their hardware, and I acknowledge that risk in using this utility in the first place.

I simply want to make sure that I don’t actually apply a +3000MHz memory overclock if this display issue is fixed in a future version, and it actually respects the setting the UI incorrectly shows.

Are we on the same page here? I am genuinely trying to help.

Yes, no one ensures damage from usage because it isn't safe. People online don't know what they're talking about.

This is why showing the raw offset value is important. Unfortunately Nvidia's API was bugged but really it should have been hidden behind an experimental option setting. The developer knew it was broken. The way the app applies the offset on top of P0 max clocks was extremely wrong to begin with. It's extremely rare that your GPU actually hits max P0 graphics clocks naturally, and that could have been verified using a variety of videos and resources online.

Nevermind the above clock issues, LACT consumes nearly 500MB of RAM and causes system micro stuttering when the historical charts are maximized despite having only 4 charts! This is now the third(?) GUI app sprawling 3 different languages(Python, C++, and now Rust) made by other people where the original developer can neither do basic QA nor people in The Community(TM) can contribute despite trash talking me, someone who has.

If no one can ensure that everything works correctly then the best thing to do is just to not do anything. Damaging other people's hardware is not OK(not just overclocking BTW, but also fan control). It's understandable that the developer doesn't have a warehouse of GPUs to test against, but over half the issues are just bad code.

And, for the record, overvolting/undervolting is possible on Linux. Just because you aren't willing to figure it out does not mean it isn't possible.

[ilya-zlobintsev]

@BlueGoliath your attitude is not productive for actually resolving any of the issues, but here's a couple of answers:

The way the app applies the offset on top of P0 max clocks was extremely wrong to begin with.

It was shown as a max clock only for UI purposes as a "maximum possible" clockspeed. And it is no longer being done in favour of showing more accurate per-pstate offsets and using newer NVML functionality (nvmlDeviceSetClockOffsets instead of nvmlDeviceSetGpcClkVfOffset).

LACT consumes nearly 500MB of RAM and causes system micro stuttering when the historical charts are maximized despite having only 4 charts

This issue only started to manifest itself with the GTK vulkan renderer that doesn't handle high res textures well, which only became the default on GTK's side recently. The resolution was reduced in #467 to avoid this lag.

And, for the record, overvolting/undervolting is possible on Linux. Just because you aren't willing to figure it out does not mean it isn't possible.

Then please indulge me on how to do this in a way that doesn't rely on the X11 NVCONTROL extension (so it actually works on modern systems) and isn't just altering clocks/power limits in hopes that the GPU decides to run at a different voltage. Because numerous feature request threads and workaround scripts point otherwise.