|
Alas both load balance and rotate are the poor cousins of the pool management strategies and none of the issues you described are ideal or expected. I shall look at them further, but the sheer nature of the lack of use of these strategies in the wild means the bugs are only now showing up and may or may not be fixable.
|
|
|
|
|
Code for the modminer has been pulled into the master tree for cgminer. The next cgminer version will have full support for this hardware.
|
|
|
|
You mean set it up to 10? I thought that was supposed to be a bad idea.
Nothing to lose by trying. CPU usage often shoots up but it depends on the device and the driver combination, and bear in mind you will only be running 1 thread so it is slightly different. You can always change it on the fly from the menu and see. |
|
|
|
Sounds like you want me to fix a possible bug by adding a feature instead?
Just throwing ideas out there since nobody seems to be in a hurry to try and figure it out.  Yah I know, I'm not ignoring you, I just can't see wtf is happening for you. The performance advantage of 2 threads versus 1 isn't that huge mind you, so I'd suggest just bumping up the intensity by 1 on the dedicated mining GPUs and use 1 thread until I find the bug (whatever it is). No one needs the level of control to set the number of threads on a per-gpu basis really... |
|
|
|
Is there a way that you could make the threads per GPU definable with a comma separated value? It seems like that could fix my problem; my display GPU looks like it's still trying to run 2 threads even though it's supposed to be dynamic.
Sounds like you want me to fix a possible bug by adding a feature instead? |
|
|
|
I saw this error when downclocking memory too far..
How far down is too far ? I am running 300Mhz Mem Clocks on 15 7970s and have not had a problem... A small performance loss, but the power (and heat) savings more than makes up for it. Difference is you're running stock engine clock speeds which he may not be. At higher engine speeds voltage will be dynamically adjusted within the card and perhaps the power balance is shifted without enough memory speed. They're not really "tuned" internally to run these weird combinations of low voltage, high engine speed and low memory speeds. |
|
|
|
Has anyone gotten - Error -6 (trying to establish Command Queue), what happens it that is drops GPU1 and it says DEAD under the mega-hash performance and I only get output from GPU0. Even it I try, restart GPU, it doesn't work. I have to quit and then open CGminer again and that gets it back up. It seems to happen every 36 hours or so.
#define CL_OUT_OF_HOST_MEMORY -6 Looks like you're overloading the memory bandwidth for that hashrate. |
|
|
|
|
Intensity is the amount of work in one go the GPU has to do before it can return its results. It needs to be large enough to keep the device fully utilised yet not so overloaded that the device becomes unresponsive. The faster the GPU, the higher the sweet spot is. Ram is of no use to mining whatsoever. They could even mine fine with only a few MB of ram.
|
|
|
|
Today i update the driver to 12.6 beta, remove the includet sdk and install the 2.1 sdk.
Now the prob is, that cgminer seem to work with ~350mh/s, but there are no shares at all?!?
wtf...
2.1 sdk does NOT work with the newer 12.x drivers at all. They are simply incompatible I'm afraid. |
|
|
|
|
Try running it in text mode only to see if you're one of the unlucky ones getting bitten by the windows version of the text interface that crashes (i.e., start it with the -T parameter).
|
|
|
|
|
Calm down guys, for fuck's sake it's not like he's a botnet operator asking for help (which has happened).
|
|
|
|
|
If you change driver/sdk combo and wish cgminer to use the new combination for its performance, you must delete any .bin files generated by cgminer first, or extract the cgminer archive afresh (for the same effect).
|
|
|
|
|
Hoppable prop pools will not be wanting to give out that much information... of course that's their problem.
|
|
|
|
|
I ran 6970s fine with 7970s, albeit on linux.
|
|
|
|
|
32 bits? Only 4 devices will work on 32 bit operating systems. If not, then increase your PCI latency to 64 or something like that I've heard it said...
|
|
|
|
As each pool has a different idea about when the block changes, if I choose the first pool's block change to discard all work from all pools then there can be quite a long period across block changes where cgminer throws out lots of work because it will continue to consider it from the old block. I had to relax the stale testing for load balance to prevent this work from being thrown out. On the other hand it's almost certainly what's leading to higher stales at every longpoll/block change. People generally get scared when they see a huge dip in hashrate across longpoll and start blaming cgminer for not keeping the devices busy. It probably makes more sense to throw out the work and accept the dip in hashrate so I can do that next version, but no matter what I choose, someone will complain  you don't want to break p2pool + other pool combinations because p2pool is unique in how it does most things This really doesn't have much to do with p2pool as p2pool is impossible to use as anything other than the primary pool, or a backup pool in pure failover-only mode. Using p2pool in load balance with it as anything other than the primary would be a mess for shares going to p2pool. |
|
|
|
You can use "--rotate" and get similar results to "--load-balance". The miner works on one pool for the time you specify and then rotates to the next.
Yeah, I was thinking about that. That's a good idea as rotate is much more robust since it has a firm concept about which pool is the primary. |
|
|
|
I think I might have found what's been causing my high stales, though not specifically...
It seems with load-balance I get very a poor stale rate, which seems to get worse the more pools involved. with 3 pools I get around 1.5% stale, with 5 it's up to 3-4%. When it's fail-over-only I'm looking at < 0.5%
Trouble is, the CGminer reported stats are not the same as the pools report. it seems the pools (some more than others) often report a share as valid to cgminer, then decide in it's own stats that it's stale.
I have a 10Mb debug log file taken over 1.5hrs if it'll be useful to diagnose anything.
Would that possibly explain the dips every now and then my hashrate as reported by the pool (i.e. Eclipse) takes (really short and then it comes up again) while my cgminer seems to be working at a constant rate? No. Hash rate reported by your pool is your hashrate*luck for that period and can and will fluctuate wildly. |
|
|
|
I think I might have found what's been causing my high stales, though not specifically...
It seems with load-balance I get very a poor stale rate, which seems to get worse the more pools involved. with 3 pools I get around 1.5% stale, with 5 it's up to 3-4%. When it's fail-over-only I'm looking at < 0.5%
Trouble is, the CGminer reported stats are not the same as the pools report. it seems the pools (some more than others) often report a share as valid to cgminer, then decide in it's own stats that it's stale.
I have a 10Mb debug log file taken over 1.5hrs if it'll be useful to diagnose anything.
As each pool has a different idea about when the block changes, if I choose the first pool's block change to discard all work from all pools then there can be quite a long period across block changes where cgminer throws out lots of work because it will continue to consider it from the old block. I had to relax the stale testing for load balance to prevent this work from being thrown out. On the other hand it's almost certainly what's leading to higher stales at every longpoll/block change. People generally get scared when they see a huge dip in hashrate across longpoll and start blaming cgminer for not keeping the devices busy. It probably makes more sense to throw out the work and accept the dip in hashrate so I can do that next version, but no matter what I choose, someone will complain |
|
|
|
|
Show Posts
