GPU / MEM clock ratio?

[cicada]

Hey all,

I'm just wondering if anyone has done any experimentation to find a proper GPU / MEM clock ratio for these radeon cards..

I know that the clocks are decoupled and can be set individually, but for streamlined operation (making sure the GPU isn't waiting for a memory tick or vice-versa) it seems like there should be a clock ratio that gives best performance.  I'm not super familiar with GPU architecture, so I may be way off base, if anyone actually knows better please clarify.

For example, if there was a 3/1 clock ratio for GPU to MEM, 999/333 might perform better than, say, 1000/333 due to misaligned cycles.

If there's any merit to this idea, it may only show up in long-term averages; it's quite possible there'd be no obvious effect untill the cycles were seriously misaligned, which might happen in only 1/100 cycles.

Also note these numbers are all bogus, I didn't do any real math

Also note it's likely any effect here would end up adding up to < 1MH/s, but it could also be the difference between a nice, stable hashing speed vs one that bounces around +/- 10MH/s

So, has anyone done such research?  If you've only experimented with different memory clocks, but kept track, that'd be useful info as well.  With enough data we might glean useful results.

[mike678]

The 3/1 ratio seems pretty accurate. I have 5830's running at 1030/350 and 5850's running at 940/325. If I push the mem any higher it doesn't seem to effect the megahash you get.

[cicada]

The 3/1 ratio seems pretty accurate. I have 5830's running at 1030/350 and 5850's running at 940/325. If I push the mem any higher it doesn't seem to effect the megahash you get.

My hunch is a 3/1 or 4/1 ratio, but 'pretty accurate' isn't the same as actually accurate

I'd like to think we'll find for each card model or family there's a best ratio to use.  On my 5830s  999/333 seemed very stable, but still fluxuated a bit (+/- 5MH/s).  There are a lot of variables here though - that could also be due to worksize or latency requesting the next job, etc.

Mining MH/s may not be the best measurement for what I'm looking for..

[cicada]

I should probably clarify that what I'm looking for are speeds where there's an actual alignment of GPU clock ticks to Memory clock ticks, not the clock speeds that happen to work well for you. 

Finding such a number could allow us to find a 'peak efficiency' where the GPU / MEM are never waiting for the other to swing, potentially increasing GPU load and average hashrates.

Logic would dictate that any integral ratio would work - 3/1 ratios would be 3 GPU cycles for each 1 memory cycle, for example, but hardware doesn't always line up like that.

[cicada]

Well, after a little more research it turns out this probably does not matter much.

In applications with significant memory usage, clock alignment might have some effect on throughput, as the GPU may be stuck waiting on the next memory register to fill.  This is partially why boosting the memory clock gives you better framerates in games.  Lining up the clocks would help ensure a just-filled register will be available immediately.

In our case, where memory bandwidth / throughput requirements are tiny, we can stack up a bunch of instructions and don't have to worry about starving the GPU of work.  This means any desynchronization is going to have very little to no effect on overall hashrate.  The GPU spends significantly more time on processing the current instruction set than reading in the next.

I believe the goal then is just 'find stable numbers you think are pretty'

[NightAss]

but if you can underclock stuff thats not needed for hash rate you can over clock othere parts to get better hash and keep temps down

[glendall]

Really! 3 to 1 ratio? I knew ppl underclocked their GDDR memory but didn't realize it was by this much.

Does anyone know if the ratio holds true for scrypt mining?

[crazyates]

Really! 3 to 1 ratio? I knew ppl underclocked their GDDR memory but didn't realize it was by this much.

Does anyone know if the ratio holds true for scrypt mining?

Yep, but that ratio is not exact. For SDK, it was pretty much a 3/1 ratio. For 2.5, my 5xxx cards seemed to like a flat 300.

Things changed with 2.6 and newer (we're on 2.8 now). Also, LTC (scrypt) does NOT like lower memory clocks. In fact, it's the opposite: you want as high of a memory clock as you can run stable.