Reading Con Kolivas' original original scrypt/GPU tuning instructions for sgminer and cgminer helped immensely for milking extra MH/s out of my mining rig, but it left me with some questions in the area of overclocking. Specifically, the following section didn't quite line up with what I had observed:
“Second, absolute engine clock speeds do NOT correlate with hashrate. The ratio of engine clock speed to memory matters, so if you set your memory to the default value, and then start overclocking as you are running it, you should find a sweet spot where the hashrate peaks and then it might actually drop if you increase the engine clock speed further.”
While I did see general trends that matched with this description, my memory clock didn't seem to increase hashing output it a clear "more is better" sort of way. This nagged at me for a few days, and I finally decided to do something about it.
As a first step, cgminer2rrd was born. This was initially meant to take information from the cgminer/sgminer API and record it into RRD databases, then provide a means of rendering graphs. I later added a helper script to run through a set number of overclocking settings while collecting stats so I could find ideal clock settings. While extremely helpful for tuning things that only have one input (e.g. intensity or threadcount), the graphs as rendered were lacking somewhat for overclocking. Seeing the relationship of two inputs (core/mem clock) over time was extremely difficult.
Fortunately I started playing with R, and ended up with an insanely useful histogram output, which made it immediately clear.
Our theory, based on the output of this testing, is that the documentations claims about the ratio between core and clock speed is only half the story. We also think that the firmware of the cards is automatically adjusting memory latency settings based on the memory clock setting. While this has the benefit of making the card more clockable, without exposing the latency values, it causes overclocking to significantly decrease performance at certain settings.
The result of this can be somewhat extreme - at some settings, you can gain or lose 22% of your hash rate with a 1MHz change in memory clock! Additionally, due to the cyclic-looking nature of the performance, there exist lower-clockrate settings that have extremely similar performance to higher clockrate settings while using significantly less power.