Epoch
Legendary
Offline
Activity: 922
Merit: 1003
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2012, 12:04:29 AM |
|
It also behaves differently when Singles go offline; 2.3.6 just exited (which was good) but 2.4.1 and 2.4.2 just mark them as 'OFF' and do not exit (bad). This was requested, and seemed logical. Would it be more acceptable to you, if it automatically reenabled the devices when they're plugged back in? Luke, one benefit of exiting is that cgminer can then be executed in a 'forever loop' script such as this, which is useful for automated and unattended error recovery (in lieu of something like akbash): :loop cgminer <params> waitfor xx seconds goto loop Because cgminer is re-run automatically by the scrpt, it re-enables all the Singles. This was the behavior with 2.3.6, and worked well. If a Single is unplugged, it won't be detected when the new cgminer starts... so you get the same thing, minus the ability to enable it later. Is there something else going on here? I understand that if a Single is not connected when cgminer is run, the ability to enable it later is lost. But in the case where the Single 'crashes' or experiences a temporary power failure (i.e. a 'power glitch' which caused the Single to reboot), a script like the above works well to recover from that. I'll be the first to admit that it is very primitive and will not address all possible issues, but having cgminer exit when a Single goes offline seems to be, IMHO, a more attractive option for automation purposes.
|
|
|
|
Luke-Jr
Legendary
Offline
Activity: 2576
Merit: 1186
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2012, 12:14:45 AM |
|
It also behaves differently when Singles go offline; 2.3.6 just exited (which was good) but 2.4.1 and 2.4.2 just mark them as 'OFF' and do not exit (bad). This was requested, and seemed logical. Would it be more acceptable to you, if it automatically reenabled the devices when they're plugged back in? Luke, one benefit of exiting is that cgminer can then be executed in a 'forever loop' script such as this, which is useful for automated and unattended error recovery (in lieu of something like akbash): :loop cgminer <params> waitfor xx seconds goto loop Because cgminer is re-run automatically by the scrpt, it re-enables all the Singles. This was the behavior with 2.3.6, and worked well. If a Single is unplugged, it won't be detected when the new cgminer starts... so you get the same thing, minus the ability to enable it later. Is there something else going on here? I understand that if a Single is not connected when cgminer is run, the ability to enable it later is lost. But in the case where the Single 'crashes' or experiences a temporary power failure (i.e. a 'power glitch' which caused the Single to reboot), a script like the above works well to recover from that. I'll be the first to admit that it is very primitive and will not address all possible issues, but having cgminer exit when a Single goes offline seems to be, IMHO, a more attractive option for automation purposes. If your Single is crashing, you should probably use the warranty while you can to get it replaced with one that works... I suppose I can look into automatic recovery for people with power glitches anyway tho ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif)
|
|
|
|
mdude77
Legendary
Offline
Activity: 1540
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2012, 12:17:13 AM |
|
Agreed. Having to support multiple OS's is a pain. And there will be casualties. I can accept that.
A most enlightened response. Thanks. All I can do is try my best within reasonable effort. This is all display related, right? The under the hood engine still works, it's all about the display, correct? If so, is all this information available via the API? Making a windows based GUI front end to monitor (and control) my miners is on my list of things to do. That would help the windows guys (yes, we still exist, and aren't likely going anywhere anytime soon). M
|
I mine at Kano's Pool because it pays the best and is completely transparent! Come join me!
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4228
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2012, 12:23:21 AM |
|
Agreed. Having to support multiple OS's is a pain. And there will be casualties. I can accept that.
A most enlightened response. Thanks. All I can do is try my best within reasonable effort. This is all display related, right? The under the hood engine still works, it's all about the display, correct? If so, is all this information available via the API? Making a windows based GUI front end to monitor (and control) my miners is on my list of things to do. That would help the windows guys (yes, we still exist, and aren't likely going anywhere anytime soon). M Yes I already said that the best way of working with many devices is to just use cgminer as a backend and work through the API using a different front end, which is why I see no point killing myself over the limited text interface. There are already quite a few front ends that do that, even on windows.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
Epoch
Legendary
Offline
Activity: 922
Merit: 1003
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2012, 12:28:55 AM |
|
If your Single is crashing, you should probably use the warranty while you can to get it replaced with one that works... I suppose I can look into automatic recovery for people with power glitches anyway tho ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) The Singles I have work properly with their stock hardware ... I've been making hardware mods which take them closer to their limits, so I've experienced the odd lockup and have seen cgminer's response to that. 2.3.6 behaved differently than 2.4.1, which is essentially all I'm trying to say. I can work with either one but, given a choice, I'd prefer 2.3.6's behavior under this condition (which was simply to stop execution and exit). Automatic recovery would be welcome, though it may not address all possible error conditions. An external software watchdog polling the API would likely be more robust and there is already at least one solution in that vein.
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4228
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2012, 02:44:24 AM |
|
By the way, windows virus software must have reached an all time new record for false positives. When I was compiling the 2.4.2 version for release on a windows xp virtual machine, microsoft security essentials detected the cgminer executable as a potential threat as soon as it was created. Of course I just told MSE to ignore it, but that was impressive...
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
deadlyasp
Newbie
Offline
Activity: 25
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2012, 04:58:19 AM |
|
With Intensity (that is in the OP) It warns of the futility of going over I:9, is this still the case or would I be able to go higher with my 6870HD?
I use 2 6870s at dynamic and 9 for intensity. I definitely wouldn't recommend putting it above 9 because it sends your rejects through the roof. ![Tongue](https://bitcointalk.org/Smileys/default/tongue.gif) Thanks for the update! I thought maybe it had been answered before, but gods only know how many rejected I would waste while wading through almost 300 pages ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) Sent you a small donation for your trouble ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) Worked like a dream, even got a little hashrate boost! ![Shocked](https://bitcointalk.org/Smileys/default/shocked.gif)
|
|
|
|
Phraust
Full Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 206
Merit: 100
Mostly Harmless...
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 04, 2012, 09:16:38 PM |
|
Hey, just compiled 2.4.2 for OSX, here: http://bitcoin.phraust.com/CGMINER_2.4.2.zipUsing: ./configure CFLAGS="-O2" --enable-bitforce --enable-icarus --enable-ztex Just in case anyone needs it.
|
|
|
|
mdude77
Legendary
Offline
Activity: 1540
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2012, 12:11:52 AM |
|
Making a windows based GUI front end to monitor (and control) my miners is on my list of things to do. That would help the windows guys (yes, we still exist, and aren't likely going anywhere anytime soon).
M
Many web stats display/monitors are available. Nice charts and all. So I'd not waste time on this. My take on this is that charts are nice to look at but they don't make money. Your miner does. If you interested in something that would actively control your miner process, you might take a look at my akbash. It can be set to monitor many miner, Windows and GPU hardware statistics. When triggers (hash rates, hw errors, process handle count or working set, GPU H/W temp, utilization, faulty fans etc) are met, miner (or OS) is restarted, email notifications are sent. Most importantly, driver crashes and werfault conditions are detected. I'm not looking for charts, or a web interface. Frankly, I detest web interfaces. I like GUIs and databases. Thanks for the info though. ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) M
|
I mine at Kano's Pool because it pays the best and is completely transparent! Come join me!
|
|
|
P_Shep
Legendary
Offline
Activity: 1795
Merit: 1208
This is not OK.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2012, 12:16:15 AM |
|
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.
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4228
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2012, 12:31:06 AM |
|
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 ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif)
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
P_Shep
Legendary
Offline
Activity: 1795
Merit: 1208
This is not OK.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2012, 12:38:04 AM |
|
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 ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif) I was wondering if something like this was the case. Looking at the log that seemed to me what was happening, but I was having difficulty translating what was going on... (for one, the specific pool/device the message is about is rarely referenced in the logs!). If there's not much you can do, there's not much you can do! I'll just stick to fail-over then ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) I'd say taking the dip in hashrate would be better option though. I prefer not to start work than throw away work done... 1. You won't waste power calculated hashes you know will be stale. 2. You don't get stales appearing in the stats.
|
|
|
|
wogaut
Donator
Sr. Member
Offline
Activity: 448
Merit: 250
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2012, 01:19:12 AM |
|
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?
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4228
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2012, 01:24:32 AM |
|
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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
TheOtherGuy
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 71
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2012, 01:35:22 AM |
|
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.
|
1NDoRoTapFZNiUhzTPyFdKib66QLJfmcuR
|
|
|
P_Shep
Legendary
Offline
Activity: 1795
Merit: 1208
This is not OK.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2012, 01:38:45 AM |
|
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.
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4228
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2012, 01:39:37 AM |
|
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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
iopq
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2012, 01:40:46 AM |
|
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 ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif) you don't want to break p2pool + other pool combinations because p2pool is unique in how it does most things
|
|
|
|
-ck (OP)
Legendary
Offline
Activity: 4228
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2012, 01:43:06 AM |
|
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 ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif) 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.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
ZodiacDragon84
Sr. Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif) ![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 266
Merit: 250
The king and the pawn go in the same box @ endgame
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
June 05, 2012, 04:00:16 AM |
|
I cannot seem to get (--real-quiet) to run. Is there a way to make it run from the config file?
Kindest Regards
|
|
|
|
|