Feature request...
... I believe that because GPUs 1, 3, and 5 don't return fan values that cgminer is ignoring their temps w/r auto-fan. Assuming that cgminer can't tell via ADL or otherwise that two GPUs share a fan, I would like to able to tell that to cgminer and thus have my temp targets applied to (in my case) odd-numbered GPUs as well as to even-numbered ones.
I cannot code for a 5970 or 6990 without poking and prodding them with code, and since I don't own one, it's unlikely to happen in a safe manner. If I just guess, I'll likely do something which could be bad... I might've been unclear. I was suggesting that the user have the option to specify to the software, presumably via .conf or command line, that certain GPUs comprise a "fan group," i.e., share a fan, and also which of the group has the fan output and control. I don't know, something like, in my case, "fan-group" : "0,1/0, 2,3/2, 4,5/5" ...meaning GPUs 0 and 1 share a fan, the speed of which is readable and controllable via GPU 0; etc. What I'm thinking of would not require any additional hardware coding, but it would require additional fan-control logic within cgminer. No, that's actually unnecessary because the ADL does have information about shared thermal devices... interpreting the results would need prodding though. |
|
|
|
Feature request... [P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 69.5C 4535RPM | 357.0/363.8Mh/s | A:285 R:0 HW:0 U:5.02/m I: 9
GPU 1: 74.0C | 366.4/363.9Mh/s | A:299 R:0 HW:0 U:5.26/m I: 9
GPU 2: 67.5C 4108RPM | 372.9/363.8Mh/s | A:289 R:0 HW:0 U:5.09/m I: 9
GPU 3: 62.5C | 366.4/363.7Mh/s | A:262 R:0 HW:0 U:4.61/m I: 9
GPU 4: 68.0C 3564RPM | 370.8/363.6Mh/s | A:294 R:0 HW:0 U:5.18/m I: 9
GPU 5: 71.0C | 340.5/363.6Mh/s | A:318 R:1 HW:0 U:5.60/m I: 9
These are three 5970s. auto-fan is on with a target of 70C for all, 3C hysteresis. At this snapshot GPUs 1 and 5 ran 3C-4.5C hotter than their card-mates, and GPU 3 ran 5C cooler than its mate. I believe that because GPUs 1, 3, and 5 don't return fan values that cgminer is ignoring their temps w/r auto-fan. Assuming that cgminer can't tell via ADL or otherwise that two GPUs share a fan, I would like to able to tell that to cgminer and thus have my temp targets applied to (in my case) odd-numbered GPUs as well as to even-numbered ones. I cannot code for a 5970 or 6990 without poking and prodding them with code, and since I don't own one, it's unlikely to happen in a safe manner. If I just guess, I'll likely do something which could be bad... |
|
|
|
By the way, if you're using the donation option, and you've been having lots of communication issues lately, it's probably that  The pool your donations are going to is still having lots of teething problems with its migration. |
|
|
|
|
Those with "comm errors" that lead to failures, are you using the ubuntu 11.11 binary on an older ubuntu?
|
|
|
|
Yes, people have tried to insist all sorts of things to me  |
|
|
|
I just want to submit a possible bug with 2.1.1
I am a HUGE fan of cgminer and dev who is responsible for it
I have been using cgminer elusively on my 8 ghash rig since version 2.0.0
when I upgraded from 2.1.0 to 2.1.1 I am noticing my 5870s dying for some reason
I just watched one 5870 fan stop reporting RPM and then go to 127 Degrees and windows crashes
this happened three times in a row
I down graded back to 2.1.0 and the problem is not happening any more, that very same card is chillin at 57 degrees delivering a nice 432 mhash
I have also seen at least one 5870 die on all of my rigs since upgrading to 2.1.1
i downgraded back to 2.1.0 and have not seen any cards die as of yet
I will keep the thread upgraded if they die or not to see if my hunch is correct - that this is a problem with 2.1.1
thanks
Most unusual. There was no GPU speed or fan management code between 2.1.0 and 2.1.1... On the other hand, there was one change between 2.0.8 and 2.1.0. So not sure what you're seeing there at all. |
|
|
|
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... |
|
|
|
|
I for one welcome our new DGM overlords.
|
|
|
|
|
It's only needed if you grab a binary for 11.11 and use it on earlier. If you build it yourself it wont be needed...
|
|
|
|
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
GPU 0: 69.5C 4535RPM | 357.0/363.8Mh/s | A:285 R:0 HW:0 U:5.02/m I: 9
GPU 1: 74.0C | 366.4/363.9Mh/s | A:299 R:0 HW:0 U:5.26/m I: 9
GPU 2: 67.5C 4108RPM | 372.9/363.8Mh/s | A:289 R:0 HW:0 U:5.09/m I: 9
GPU 3: 62.5C | 366.4/363.7Mh/s | A:262 R:0 HW:0 U:4.61/m I: 9
GPU 4: 68.0C 3564RPM | 370.8/363.6Mh/s | A:294 R:0 HW:0 U:5.18/m I: 9
GPU 5: 71.0C | 340.5/363.6Mh/s | A:318 R:1 HW:0 U:5.60/m I: 9
I see U columns that are aligning! |
|
|
|
|
Happy New Year, new version 2.1.1, purely bugfixes and cosmetic changes. Links in top post.
- Include API examples in distribution tarball.
- Don't attempt to pthread_join when cancelling threads as they're already
detached and doing so can lead to a segfault.
- Give more generic message if slow pool at startup is the donation pool.
- Continue to attempt restarting GPU threads if they're flagged dead at 1 min.
intervals.
- Don't attempt to restart sick flagged GPUs while they're still registering
activity.
- Make curl use fresh connections whenever there is any communication issue
in case there are dead persistent connections preventing further comms from
working.
- Display pool in summary if only 1 pool.
- Adjust column width of A/R/HW to be the maximum of any device and align them.
|
|
|
|
Ha...you ever read the e-mail responses of Steve Jobs? I'll start 2.1.0 again with verbose and debug enabled, will that help?
Maybe |
|
|
|
Is there anything in 2.1.0 that would be causing sick/dead GPU's more frequently? No. |
|
|
|
I'll just stop trying.
That's the spirit |
|
|
|
How do you know which GPU cgminer is referring to in terms of which pci slot it is in?
is GPU 0 typically in slot 1 and then goes on from there?
Whatever order the driver returns... most motherboards it should go in order of ascending slot numbers. |
|
|
|
Heh, cgminer, the miner from the future.
For those using the donation option, note that your hashes are now directed back to ozcoin who have finally completed their long overdue migration to DGM payout.
Good as I was seeing a lot of rejects on the donation shares when you had it pointed at ARS and 24+ hours without any problems on the latest I installed yesterday so looks like you tracked it down whatever it was with that last release, I have yet to see a repeat of the behaviour. Edit: Just to be sure on this I have to re-compile from git to get the new pool enabled for you right? No, just restart, thanks! |
|
|
|
|
Heh, cgminer, the miner from the future.
For those using the donation option, note that your hashes are now directed back to ozcoin who have finally completed their long overdue migration to DGM payout.
|
|
|
|
The problem was solved for each machine by restarting cgminer.
I dont see anything common between the machines that could explain this.
Anyone have a clue? Pretty please?
When it happens again, go into the display menu and enable Verbose mode, Rpc debugging and Debug mode and see what is output. |
|
|
|
|
@DeathAndTaxes
Thanks man, you're one of the few then who understands how I feel. Don't take all the responsibility and kill yourself over it though.
|
|
|
|
Still missing some of the bounty  Who hasn't paid yet? From top post: Pledged so far (any additional limits/requirements marked): * DeathAndTaxes - 30 BTC <Paid> (+5 BTC more if integrated into the mainline instead of a fork <Paid>) * Red Emerald - 10 BTC <Paid>(+5 BTC more if integrated into the mainline instead of a fork) <Paid> * gnar1ta$ - 10 BTC <Paid> (+5 BTC more if integrated into the mainline instead of a fork <Paid>) * Chefnet - (+15 BTC only if integrated into the mainline instead of a fork) Unpaid: 5 BTC (15 BTC for integration into mainline) |
|
|
|
|
Show Posts
