5970 mining thread

[Red Emerald]

I ran intensity 9 on one GPU and 7 on the other for a few weeks.  The one with 7 consistently had more accepted shares.  Anyone else try this?

Does anyone have any hard numbers about memclock energy savings?  I'm running 300 since that is the default bottom, but cgminer will let me go to 150.  I'll have to plug in my kill-o-watt and take some readings

Use -I 8 for 5xxx cards and -I 9 for 6xxx cards.  I believe that was the previous note in CGMiner.

Now it says: "NOTE: Running intensities above 9 with current hardware is likely to only
diminish return performance even if the hash rate might appear better. A good
starting baseline intensity to try on dedicated miners is 9. Higher values are
there to cope with future improvements in hardware."

Hm. I went back to running intensity 9 with memclocks down to 160.  I'm not sure if intensity 7 card doing better was just luck. since my hashrate went from 1071 to 1083.

[SlaveInDebt]

I ran intensity 9 on one GPU and 7 on the other for a few weeks.  The one with 7 consistently had more accepted shares.  Anyone else try this?

Does anyone have any hard numbers about memclock energy savings?  I'm running 300 since that is the default bottom, but cgminer will let me go to 150.  I'll have to plug in my kill-o-watt and take some readings

My rig w/ 3x 5970s uses 870w @ 825/160.  It uses 885w @ 825/300.  It uses 935W @ 825/1000.  That was about 6 months ago.  It is possible different driver versions have changed that somewhat.  160 seemed as stable and same speed as 300 so I have kept all the rigs @ 160.  15W isn't much (5w per card) but I guess every little bit helps.

I wonder if dropping the mem clocks to a lower value would also decrease the temps of VRMs...in theory, I would say yes.  Agree ?

In theory however temp is linear w/ power right?  Thus the smaller and smaller amounts of power reduction means smaller and smaller decreases in thermal output and thus temps.  It can't hurt though.

Memory has it's own power phase (vrm). Dropping memory clocks will reduce the heat load on the heat plate and over all reduce temps for the gpu vrm's and even gpu core.

[btc_artist]

Does dropping the memory clock affect the overall hash rate either up or down?  In my own testing it seems to not affect it one way or the other, but I haven't been very scientific.

[Red Emerald]

Does dropping the memory clock affect the overall hash rate either up or down?  In my own testing it seems to not affect it one way or the other, but I haven't been very scientific.

I haven't noticed any difference in hash rate with lower memory clocks.  I think a reduced memory clock can allow for a higher engine clock which can increase hash rates.

[P4man]

Does dropping the memory clock affect the overall hash rate either up or down?  In my own testing it seems to not affect it one way or the other, but I haven't been very scientific.

It depends on the miner app and settings. Ive seen some fancy chart that showed hashrate plotted against memory clock, and in most cases, hashrate actually decreased (only very very marginally, a few %) with increasing vram clock rates, though it wasnt quite a straight line. This is counter intuitive, but apparently had some solid theoretical explanation, something about caching algorithm, but I dont quite remember how it worked.

Cant seem to find that graph or thread, if someone knows it, Id love to see it again.

[Red Emerald]

So I dropped my memclocks and bumped my intensity.  Got a minor increase in shares per minute (which matters more than hashrate).  I'm tempted to bring GPU 1 up another 5 MHz to match GPU 0, but when I ran it like that before it crashed after a couple days.

GPU 0 and 1 are my 5970.  I'm really temped to buy a second card now that my paycheck cleared.

Code:

 cgminer version 2.1.0 - Started: [2011-12-30 04:16:36]
--------------------------------------------------------------------------------
 (5s):1081.5 (avg):1082.7 Mh/s | Q:59366  A:54757  R:1627  HW:0  E:92%  U:14.45/m
 TQ: 5  ST: 6  SS: 1  DW: 2356  NB: 396  LW: 2803  GF: 245  RF: 8
 Connected to http://goat1.zapto.org:8337 with LP as user redemerald1
 Block: 00000ada8101be812ceac86e64822a87...  Started: [19:20:00]
--------------------------------------------------------------------------------
 [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
 GPU 0:  74.5C 4364RPM | 382.5/381.8Mh/s | A:19264 R:592 HW:0 U:5.08/m I:9
 GPU 1:  70.5C         | 380.2/379.6Mh/s | A:19106 R:626 HW:0 U:5.04/m I:9
 GPU 2:  69.5C 1569RPM | 317.0/321.3Mh/s | A:16387 R:409 HW:0 U:4.32/m I:9
--------------------------------------------------------------------------------

GPU 0: 382.8 / 381.8 Mh/s | A:19264  R:592  HW:0  U:5.08/m  I:9
74.5 C  F: 85% (4354 RPM)  E: 830 MHz  M: 160 Mhz  V: 1.049V  A: 99% P: 0%
Last initialised: [2012-01-01 06:45:45]
Intensity: 9
Thread 0: 193.8 Mh/s Enabled ALIVE
Thread 3: 188.7 Mh/s Enabled ALIVE

GPU 1: 380.4 / 379.6 Mh/s | A:19105  R:626  HW:0  U:5.04/m  I:9
71.0 C  E: 825 MHz  M: 160 Mhz  V: 1.049V  A: 99% P: 0%
Last initialised: [2012-01-01 14:44:38]
Intensity: 9
Thread 1: 191.6 Mh/s Enabled ALIVE
Thread 4: 188.6 Mh/s Enabled ALIVE

GPU 2: 316.5 / 321.3 Mh/s | A:16385  R:409  HW:0  U:4.32/m  I:9
69.5 C  F: 43% (1575 RPM)  E: 1000 MHz  M: 160 Mhz  V: 1.162V  A: 99% P: 0%
Last initialised: [2011-12-30 19:46:43]
Intensity: 9
Thread 2: 161.8 Mh/s Enabled ALIVE
Thread 5: 154.2 Mh/s Enabled ALIVE

[E]nable [D]isable [I]ntensity [R]estart GPU [C]hange settings

[Eveofwar]

Does dropping the memory clock affect the overall hash rate either up or down?  In my own testing it seems to not affect it one way or the other, but I haven't been very scientific.

It depends on the miner app and settings. Ive seen some fancy chart that showed hashrate plotted against memory clock, and in most cases, hashrate actually decreased (only very very marginally, a few %) with increasing vram clock rates, though it wasnt quite a straight line. This is counter intuitive, but apparently had some solid theoretical explanation, something about caching algorithm, but I dont quite remember how it worked.

Cant seem to find that graph or thread, if someone knows it, Id love to see it again.

I believe the graph you were referring to, was based off of different "Vectors"  V2 vs V4, and so forth.  It showed the different hashrates at each memory & GPU clock, per vector.

I can't seem to find it either, but it was nice :/

[P4man]

Yep that was the one. Should have bookmarked it. IIRC, for some vector settings, hashrate increased with clocks, but the fastest performance was achieved with other settings and very low memory clocks.

[Proofer]

So I dropped my memclocks and bumped my intensity.  Got a minor increase in shares per minute (which matters more than hashrate). ...

Is there a theory about the relation between hash rate and shares/minute?  Overall they must correlate, but I've observed that the correlation is not perfect.

[-ck]

So I dropped my memclocks and bumped my intensity.  Got a minor increase in shares per minute (which matters more than hashrate). ...

Is there a theory about the relation between hash rate and shares/minute?  Overall they must correlate, but I've observed that the correlation is not perfect.

They correlate, but proportional to luck. So if you're "tuning' based on the value returned for shares/minute, then you're changing settings based on the luck of your most recent mining session, and nothing to do with hash performance...

[Red Emerald]

So I dropped my memclocks and bumped my intensity.  Got a minor increase in shares per minute (which matters more than hashrate). ...

Is there a theory about the relation between hash rate and shares/minute?  Overall they must correlate, but I've observed that the correlation is not perfect.

They correlate, but proportional to luck. So if you're "tuning' based on the value returned for shares/minute, then you're changing settings based on the luck of your most recent mining session, and nothing to do with hash performance...

Someone was talking about how they were getting higher hash rates when they changed one of their options (I think vectors) but were getting lower shares.  I thought they had done it over a long period of time, but it might have been them talking out their ass. They said something about the card having way more rejected shares than expected. When they changed their setting for vectors to something lower, their MH/s dropped a small amount but their submitted shares went up.  This would have been back in June, so I'm not sure what to even search.

[-ck]

Yes, people have tried to insist all sorts of things to me 

[DeathAndTaxes]

So I dropped my memclocks and bumped my intensity.  Got a minor increase in shares per minute (which matters more than hashrate). ...

Is there a theory about the relation between hash rate and shares/minute?  Overall they must correlate, but I've observed that the correlation is not perfect.

They correlate, but proportional to luck. So if you're "tuning' based on the value returned for shares/minute, then you're changing settings based on the luck of your most recent mining session, and nothing to do with hash performance...

Someone was talking about how they were getting higher hash rates when they changed one of their options (I think vectors) but were getting lower shares.  I thought they had done it over a long period of time, but it might have been them talking out their ass. They said something about the card having way more rejected shares than expected. When they changed their setting for vectors to something lower, their MH/s dropped a small amount but their submitted shares went up.  This would have been back in June, so I'm not sure what to even search.

Exactly.  IF rejected shares are the same then hashrate and share rate should correlate.  There is short term variance but over say 24 hours you shouldn't see a lower hashrate and higher share rate.

Now IF you have rejects not related to pool latency then your cards are trying to tell you something.  It is possible to drive the card to the point of failure such that despite the higher hashrate you have some many rejects that shares/min is lower.  Of course this should be immediately obvious with the giant ugly number next to R.

U (is in shares/ minute) = (hashrate * 60) / (2^32)

If you reject rate is >0% then it will affect U but the amount should be small because w/ modern miners there is no reason for a reject rate higher than 0.1%.

So for example 400 MH/s =  (400 * 1000^2 * 60) / (2^32) = 5.58 shares per min

[jjshabadoo]

Speaking of clocks and hash rates, I vastly over stated what I thought I could get earlier in this thread. Right now my cards won't go longer than 2-3 days at 800/300 or 800/160 and this is in a cold basement. One machine has a box fan blowing on it directly.

It has to be the ram, because my core temps don't go above 60c and most are in the low 50's. I'm starting to think these diamond brand 5970's from newegg just suck.

I just cranked them down to 725/160 since I won't be able to mess with my rigs for a while. I'm thinking I might have to go water cooling since I can probably get 900 or so.

DeathandTaxes, what hash rate do you get on your water cooled cards. I'd like to do some calculations on the difference to see if a water cooling investment is worth it.

[jjiimm_64]

It has been my experience that the 5970's run more stable with a little higher memory.  I used to run them at 420, i have since brought it down to 300.

I know I am not answering the water cooling question.  I would raise the mem back up a bit if it was me.  Also, did you burn them in at a lower clock before going above or at 800?  I did for all 21 of my 5970's.

I ran them at stock clock for a few hours, then at 750 for a while, then at 775 for a day.  after that I would run them at 800/300 for a stability check. (days).  after that maybe crank them up to 820 if the temps are OK.

just my 2 bitcents.

[jjshabadoo]

I appreciate the response Jimm and no I didn't burn them in intially, maybe that screwed me.

I'm just getting frustrated here as I have put in about 20 hours on these rigs the last 4-5 days and it's pissing me off that I can't even get 800 clock speeds after replacing all the TIM and pads, etc.

I know I did a good job with the TIM and pads because the GPU cores went down at least 5c on every card. If you guys could see how bad the stock pads and TIM was on these cards you'd know what I did should have helped A LOT.

I'm just thinking all the down time and restarts are costing me way more than if I just water cooled every damn card and called it a day.

It looks like it would cost me about $1000 per rig for three cards to water cool them.

I have 12 5970's and 8 5870's right now. The 5870's are at 900 with stock cooling and have run fine for 4 days.

Considering I could probably get the 5970's to 850 or 860, that's 125 mhz per core over stock for a total of 1500 mhz extra. Three cards at stock is getting me about about 2 GH/s at 850 I think I could get closer to 2.4 at least.

So that would be an extra 1.6 GH/s which gets about $200 per month at current prices. Now if you count shutdowns and the loss of revenue associated with all that, looks like about a 12 month return.

[Proofer]

...
I ran them at stock clock for a few hours, then at 750 for a while, then at 775 for a day.  after that I would run them at 800/300 for a stability check. (days).  after that maybe crank them up to 820 if the temps are OK.

But...

Speaking of clocks and hash rates, I vastly over stated what I thought I could get earlier in this thread. Right now my cards won't go longer than 2-3 days at 800/300 or 800/160 and this is in a cold basement

(Emphasis added for both quotes)

I was having cgminer report GPUs "SICK" -- thread idle for more than 60 sec., but immediately "cured" by killing/restarting the (two) GPU threads.  So I increased memclock from 150 to 300 and reduced engine clock from 800 to 725 (stock speed).  I was hopeful, but after about 10 hours one (of six) was just reported "SICK"...  This one is reporting about 68C.

Maybe I should just accept a certain rate of SICKness?  At 800/150 I was getting about seven such cases a day.

[jjiimm_64]

this is also not too scientific..  but some of the rigs I would just keep restarting, keep the clocks at whatever they were.  and eventually the rig would just kept running. still dont know why.

[-ck]

Now IF you have rejects not related to pool latency then your cards are trying to tell you something.  It is possible to drive the card to the point of failure such that despite the higher hashrate you have some many rejects that shares/min is lower.  Of course this should be immediately obvious with the giant ugly number next to R.

Just to be clear to others, the ugly number next to R is Hardware Errors. That's the only time overclocking too much or unlocking broken shaders and what not will actually decrease your effective useful hashrate even though apparently stable; when your cards starts making shit up.

[P4man]

Just to be clear to others, the ugly number next to R is Hardware Errors.

Surely you mean the number next to HW is hardware error, and the number next to R is rejects, right?