yochdog
Legendary
Offline
Activity: 2044
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 24, 2012, 09:56:33 PM |
|
How often to Shares for the week, as well as combined shares update?
Mine seem to be frozen at the moment.....
ALSO, when a worker goes offline, does it disappear from the worker lines or simply go to 0 MH/s?
|
I am a trusted trader! Ask Inaba, Luo Demin, Vanderbleek, Sannyasi, Episking, Miner99er, Isepick, Amazingrando, Cablez, ColdHardMetal, Dextryn, MB300sd, Robocoder, gnar1ta$ and many others!
|
|
|
CoinLab (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 24, 2012, 10:49:56 PM |
|
At the end of each block, we roll up all the shares you earned and add it to the total displayed in the web interface. This process takes up to 90 seconds after block completion. Because of this, particularly long blocks will delay the stats from updating. You can get real-time stats through the API. Replace <username> and <password> and paste this line into Command Prompt or Terminal: curl -v --data '{"method": "minerstats", "params": [], "id": "sample"}' --user protected_<username>:<password> -D - http://pool.coinlab.com:8332
|
|
|
|
urandom
Newbie
Offline
Activity: 2
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 25, 2012, 01:18:36 PM |
|
Anyone noticed huge percentage of rejects (~5% in my case) last days? Previous weeks I had almost zero rejects. Running cgminer on two rigs.
|
|
|
|
TheHarbinger
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: 378
Merit: 250
Why is it so damn hot in here?
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 25, 2012, 01:53:35 PM |
|
No increase in rejects here. I just wish they would fix the hashrate display. ![Undecided](https://bitcointalk.org/Smileys/default/undecided.gif)
|
12Um6jfDE7q6crm1s6tSksMvda8s1hZ3Vj
|
|
|
jamesg
VIP
Legendary
Offline
Activity: 1358
Merit: 1000
AKA: gigavps
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 25, 2012, 01:59:04 PM |
|
No increase in rejects here. I just wish they would fix the hashrate display. ![Undecided](https://bitcointalk.org/Smileys/default/undecided.gif) It's nice that the graph is right at least... Coinlab, could you move the rollNTime header to expire=120 instead of expire=60. Most other pools I've been on use 120 seconds without issue.
|
|
|
|
jjiimm_64
Legendary
Offline
Activity: 1876
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 25, 2012, 04:00:22 PM |
|
I had to switch away from coinlab for now, i get much more return from other pools.... but i need the loyalty points.. so not sure what to do
|
1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
|
|
|
jamesg
VIP
Legendary
Offline
Activity: 1358
Merit: 1000
AKA: gigavps
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 25, 2012, 04:29:08 PM |
|
I had to switch away from coinlab for now, i get much more return from other pools.... but i need the loyalty points.. so not sure what to do
Hi CoinLab, Are you rolling your own pool software? Why is the pool having issues where it would push miners away? Thanks, gigavps
|
|
|
|
CoinLab (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 25, 2012, 06:58:04 PM |
|
I had to switch away from coinlab for now, i get much more return from other pools.... but i need the loyalty points.. so not sure what to do
Hi CoinLab, Are you rolling your own pool software? Why is the pool having issues where it would push miners away? Thanks, gigavps Yep, the pool is all in-house software. It appears that a recent optimization may have conflicts with older mining clients. We were noticing a lot of miners were doing old work longer than they should have been, so we now send a long-poll push every 60 seconds, regardless of whether or not the miner is finished with its current work. This allows us to update the work your miner is working on with transactions submitted after work started. Newer mining clients handle this fine and can be told by our server to submit the "stales" (same block, less up-to-date transactions), but it appears some older clients see the new work, drop any unsubmitted shares, and start work on the new work. The dropping of these shares appear to be causing the decrease in performance for some miners using older clients. We're testing now to try to reproduce this in house. Before this change, the average submitted work was 120 seconds old, now it is ~ 30. This means our blocks will include more transactions that were recently submitted to the Bitcoin network. Faster transaction processing time is better for the network, so we want to keep this fix in, but we also want to find a solution that lets everyone keep mining productively.
|
|
|
|
jjiimm_64
Legendary
Offline
Activity: 1876
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 25, 2012, 07:49:23 PM |
|
I had to switch away from coinlab for now, i get much more return from other pools.... but i need the loyalty points.. so not sure what to do
Hi CoinLab, Are you rolling your own pool software? Why is the pool having issues where it would push miners away? Thanks, gigavps Yep, the pool is all in-house software. It appears that a recent optimization may have conflicts with older mining clients. We were noticing a lot of miners were doing old work longer than they should have been, so we now send a long-poll push every 60 seconds, regardless of whether or not the miner is finished with its current work. This allows us to update the work your miner is working on with transactions submitted after work started. Newer mining clients handle this fine and can be told by our server to submit the "stales" (same block, less up-to-date transactions), but it appears some older clients see the new work, drop any unsubmitted shares, and start work on the new work. The dropping of these shares appear to be causing the decrease in performance for some miners using older clients. We're testing now to try to reproduce this in house. Before this change, the average submitted work was 120 seconds old, now it is ~ 30. This means our blocks will include more transactions that were recently submitted to the Bitcoin network. Faster transaction processing time is better for the network, so we want to keep this fix in, but we also want to find a solution that lets everyone keep mining productively. Time for me to update my mining software ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) If it aint broke dont fix it... but it appears broke now ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
|
|
|
TheHarbinger
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: 378
Merit: 250
Why is it so damn hot in here?
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 25, 2012, 07:52:23 PM |
|
The only reason I can see for someone using "older" mining software is if they are using something like BAMT. And to be honest, it's not that hard to update that to the newer software. I do know that there is an issue with a BAMT fix and newer versions of cgminer, but that's not to hard to get around either.
|
12Um6jfDE7q6crm1s6tSksMvda8s1hZ3Vj
|
|
|
jjiimm_64
Legendary
Offline
Activity: 1876
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 25, 2012, 07:58:10 PM |
|
The only reason I can see for someone using "older" mining software is if they are using something like BAMT.
I would disagree with this on a number of levels.. cgminer version 2.3.6 has been solid. I can run a rig multil million shares without issue. I upgraded to a 2.5 something or another and had problems, so I went back to what worked and stayed there. But with upcoming asics, this coinlab issue, and general consensus, sounds like it is finally time to upgrade.
|
1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
|
|
|
jjiimm_64
Legendary
Offline
Activity: 1876
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 25, 2012, 08:06:01 PM |
|
We're testing now to try to reproduce this in house.
Just a suggestion, but you may want to try and point 50Gh at one worker, not just one 7970.
|
1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
|
|
|
jamesg
VIP
Legendary
Offline
Activity: 1358
Merit: 1000
AKA: gigavps
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 25, 2012, 09:02:37 PM Last edit: October 25, 2012, 10:50:06 PM by gigavps |
|
Yep, the pool is all in-house software. It appears that a recent optimization may have conflicts with older mining clients.
I'm just wondering if you would be able to focus more development efforts on the HPC stuff if you used a proven OSS pool like eloipool (eclipsemc.com and eligus.st use this software) or ecoinpool (used by ozco.in). http://gitorious.org/bitcoin/eloipool/trees/masterhttps://github.com/p2k/ecoinpoolWe were noticing a lot of miners were doing old work longer than they should have been, so we now send a long-poll push every 60 seconds, regardless of whether or not the miner is finished with its current work
I see no reason why you would need to send a long poll every minute if you are keeping long poll connections open and properly sending responses on those connections when a block change is recognized. It seems to me that if miners are continuing to roll old work, it's because of the server's long poll implementation. EDIT:By sending out a long poll every minute, you are also asking miners to abort the perfectly good work that they are working on. This means more wasted computing cycles compared to other pools which, in turn, means less shares submitted.
|
|
|
|
jjiimm_64
Legendary
Offline
Activity: 1876
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 26, 2012, 03:00:55 AM Last edit: October 26, 2012, 04:43:26 AM by jjiimm_64 |
|
The only reason I can see for someone using "older" mining software is if they are using something like BAMT. And to be honest, it's not that hard to update that to the newer software. I do know that there is an issue with a BAMT fix and newer versions of cgminer, but that's not to hard to get around either.
Here is another reason NOT to upgrade: speed: I downloaded 2.7.7, use the exact same config file. started.. rig went from 1117 to about 1050. I said, oh yah, I forgot to copy over my old bin files to keep the faster old driver files...not much change.. so i did a test. here is 2.3.6 run for about 2.6 hours cgminer version 2.3.6 - Started: [October 25, 2012, 8:30 pm] Rig:miner14 miner14 (5s):1115.78 (avg): 1115.95 Mh/s | H: 121.38 Q:3416 A:2262 R:8 HW:0 E:?% U:15.59/m TQ:? ST:1 SS:? DW:618 NB:30 LW:10799 GF:2 RF:0 Connected to http://test.ozco.in:8332 with LP as user ? Value: GPU 0: 72.5C 3350RPM 61% 134 | 224.6/224.4Mh/s | 99% | 500Mhz 600Mhz 1V A:451 R:1 HW:0 U:3.11/m I: 7 GPU 1: 73.5C 2187RPM 32% 106 | 317.7/317.5Mh/s | 99% | 700Mhz 300Mhz 0.889V A:641 R:6 HW:0 U:4.42/m I: 7 GPU 2: 73.0C 1929RPM 30% 103 | 317.7/317.5Mh/s | 99% | 700Mhz 300Mhz 0.889V A:648 R:0 HW:0 U:4.47/m I: 7 GPU 3: 73.5C 2877RPM 70% 144 | 255.7/256.7Mh/s | 99% | 800Mhz 300Mhz 0.99V A:522 R:1 HW:0 U:3.60/m I: 7
I am running the new one now, will post in a little while. edit: this is 2.7.7 with the older bin files: hashrate is slower, but the shares per minute seem good. will redo in about an hour shares down to 14.8 25min in update: down to 14.4 now. 45minutes in update: down to 14.29...ive had enough cgminer version 2.7.7 - Started: [October 25, 2012, 11:00 pm] Rig:miner14 miner14 (5s):1002.94 (avg): 1002.97 Mh/s | H: 112 Q:148 A:854 R:1 HW:0 E:?% U:14.29/m TQ:? ST:0 SS:? DW:31 NB:8 LW:1971 GF:1 RF:0 Connected to http://test.ozco.in:8332 with LP as user ? Value: GPU 0: 73.5C 3437RPM 62% 136 | 209.8/209.8Mh/s | 99% | 500Mhz 600Mhz 1V A:187 R:0 HW:0 U:3.13/m I: 7 GPU 1: 73.5C 2113RPM 31% 105 | 283.1/283.1Mh/s | 99% | 700Mhz 300Mhz 0.889V A:239 R:0 HW:0 U:4.00/m I: 7 GPU 2: 71.5C 1931RPM 30% 102 | 283.0/283.2Mh/s | 99% | 700Mhz 300Mhz 0.889V A:262 R:0 HW:0 U:4.38/m I: 7 GPU 3: 74.5C 2609RPM 32% 107 | 227.1/226.9Mh/s | 99% | 800Mhz 300Mhz 0.99V A:166 R:1 HW:0 U:2.78/m I: 7
And that is why you dont just upgrade. I would turn a 54g farm into a 51 gig farm.. if I can even get it all to work. I just tried on one of my 5x7970 rigs and it crashed when starting. probably because i have the good beta driver running from January. edit: again: so, as it turns out, i have the newer drivers on this rig, which from what i am reading is not optimal for 5 and 6x cards......
|
1jimbitm6hAKTjKX4qurCNQubbnk2YsFw
|
|
|
-ck
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 26, 2012, 06:35:54 AM |
|
edit: again: so, as it turns out, i have the newer drivers on this rig, which from what i am reading is not optimal for 5 and 6x cards......
Summary: PEBKAC. Please don't blame cgminer upgrades. I don't like spending thousands of hours coding and people thinking it's making things worse for them.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
-ck
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 26, 2012, 06:37:06 AM |
|
EDIT: By sending out a long poll every minute, you are also asking miners to abort the perfectly good work that they are working on. This means more wasted computing cycles compared to other pools which, in turn, means less shares submitted.
This is very true. Extra longpolls are very wasteful.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
CoinLab (OP)
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 26, 2012, 07:12:51 PM Last edit: October 26, 2012, 07:35:13 PM by CoinLab |
|
EDIT: By sending out a long poll every minute, you are also asking miners to abort the perfectly good work that they are working on. This means more wasted computing cycles compared to other pools which, in turn, means less shares submitted.
This is very true. Extra longpolls are very wasteful. OK. We are going to backing this change out now.
|
|
|
|
mckoss
Newbie
Offline
Activity: 52
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 26, 2012, 09:11:01 PM |
|
An update on our LONGPOLL experiment. I've removed the extra LONGPOOL flushes - your LONGPOLLs will now only update when we know about a new Block to mine on. I agree that this was a misuse of LONGPOLL - but let me explain my reason for trying it. Our pool has a guarantee of accepting work - even if it is stale - for a fixed amount of time from when we generated the work for the miner. Right now, this is set to 60 seconds. This information is implied by our getwork headers: X-Mining-Extensions: longpoll rollntime submitold X-Roll-Ntime: expire=60 X-Long-Polling: /listenChannel Server: CoinLab Affiliate Pool
Notice that we specify a 60 second expire time in X-Roll-Ntime. That's telling miners that not only can they increment the timestamp 60 times, but also that they should NOT be submitting this work more than 60 seconds in the future (if they do - they risk getting a stale). I don't know if other pools have the same kind of strong guarantee of accepting stale work, but we've implemented a "Grace Period" - we will accept even stale work for 60 seconds after the end of a block - but only if you received the work within the last 60 seconds. We notice many miners do not update their work frequently. According to the semantics of the X-Roll-Ntime extension, a miner should cease mining on blocks older than expire seconds old. My aggressive sending of LONGPOLL flushes was my attempt to get miners to update their work each minute. Here's a snapshot of our internal metrics. https://i.imgur.com/FMf0Y.pngBefore the change (at 12:15 PST today), you'll see that we were flushing each 60 seconds, which results in relatively few stale shares when each new block is found (called "generation start" in the chart). After the change, you can see no more frequent long-poll flushes, but relatively more stales at the start of a new block. There are a few miners on our pool working on very old work - note the work age graph (darker bands indicate older work shares). A properly written miner on our pool should not be submitting work much more than 60 seconds from the time it is received. We are seeing shares on work that is over an hour old in the extreme (a very buggy miner), but also over 5 minutes from several miners on our pool. If you're getting a significant number of stales while mining on our pool - let us know what mining client (and version) you're running; we'd like to eliminate stales completely from our pool.
|
|
|
|
-ck
Legendary
Offline
Activity: 4214
Merit: 1644
Ruu \o/
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 26, 2012, 09:32:03 PM |
|
An update on our LONGPOLL experiment. Notice that we specify a 60 second expire time in X-Roll-Ntime. That's telling miners that not only can they increment the timestamp 60 times, but also that they should NOT be submitting this work more than 60 seconds in the future (if they do - they risk getting a stale). I don't know if other pools have the same kind of strong guarantee of accepting stale work, but we've implemented a "Grace Period" - we will accept even stale work for 60 seconds after the end of a block - but only if you received the work within the last 60 seconds.
We notice many miners do not update their work frequently. According to the semantics of the X-Roll-Ntime extension, a miner should cease mining on blocks older than expire seconds old. My aggressive sending of LONGPOLL flushes was my attempt to get miners to update their work each minute. Ok I see what's wrong here. The expire= parameter with x-roll-ntime is how many seconds after the getwork is sent that the miner is allowed to roll time for... it is NOT how many "seconds of rolling equivalent" they're allowed to add to the timestamp. That should be limited only by what bitcoin would accept, which is a maximum of 7200 seconds.
|
Developer/maintainer for cgminer, ckpool/ckproxy, and the -ck kernel 2% Fee Solo mining at solo.ckpool.org -ck
|
|
|
jamesg
VIP
Legendary
Offline
Activity: 1358
Merit: 1000
AKA: gigavps
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 26, 2012, 09:33:01 PM |
|
An update on our LONGPOLL experiment.
Please stop "experimenting" with the live pool. I've removed the extra LONGPOOL flushes - your LONGPOLLs will now only update when we know about a new Block to mine on.
I agree that this was a misuse of LONGPOLL - but let me explain my reason for trying it.
Thanks. Our pool has a guarantee of accepting work - even if it is stale - for a fixed amount of time from when we generated the work for the miner. Right now, this is set to 60 seconds. This information is implied by our getwork headers:
I'm not sure why you guarantee aka pay for work if it is stale. I would rather you didn't and lowered your fee. As for why some miners are working on really old work: This is most likely a problem with your long poll implementation.Specifically I would look to see if your server is closing connections without sending any kind of response, aka timing out connections. cgminer is coded to keep a long poll connection open for 1 hour.
|
|
|
|
|