All things Nvidia GPU

The achievable graphics clocks are not incremented decimally.  They jump in "bins" of 13Mhz, or at least they did up to Turing generation.  Not sure what the bin increment is on Ampere or Ada. The bins are a result of the internal clock generators resolution in the binary realm.

Each "bin" is a position along the VTP or voltage-temperature-power curve. When the temperature and power values allow, the GPUBoost mechanism in the firmware boosts the graphics clocks up into the next bin and holds it there as long as the temperature is still under the throttling limit and the power limit isn't exceeded and the graphics loading is held constant.

The bins are why you don't get an immediate 1:1 jump in the clocks when you enter an increase in offset.  You can continue to add 5Mhz half a dozen times and not see any change in the clocks.  Then the 6th increase in clocks make the graphics clock jump up by 13Mhz.

If you try an get too agressive, irrespective of causing actual image or compute errors, the clocks will jump up to a higher value for a quick burst and then immediately drop back and likely below the original clocks because you tried to jump up the VT curve too far and the firmware pulled the reins back and said whoah.

You should try and use smaller incremental offsets until you can keep the card consistently in an elevated bin under load and it doen't jump around.

When you increase the memory clocks you are speeding up the data transfer between cpu memory and gpu memory. The higher the clocks and the wider the memory bus is the more data can be transferred back and forth more quickly which speeds up the calculations.  But modern Nvidia gpus use on board error correction to validate memory transfers.  If the memory block does not transfer correctly, the gpu is asked to send the data again twice or more times until the result received is the same as what was sent.  Too many retries in data transmission of the same data packets slow the actual calculation down.  So you can push the memory data transfer rate too far and that is counter-productive.

You always need to keep at least one to two cores free to service the background processes or to make the data transfer between main memory and gpu memory.  Remember modern cpu architeture is all about time-slicing service requests from processes.  And that operates in a round-robin fashion for the most part.

If your data isn't ready when the cpu tells the gpu . . . . OK, its' your turn for my attention, it just cycles your request to the back of the queue until your turn comes around again.