[ANN] CoinLab Protected Pool

[yochdog]

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? 

[CoinLab]

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:

Code:

curl -v --data '{"method": "minerstats", "params": [], "id": "sample"}'  --user protected_<username>:<password> -D - http://pool.coinlab.com:8332

[urandom]

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]

No increase in rejects here.  I just wish they would fix the hashrate display.   

[jamesg]

No increase in rejects here.  I just wish they would fix the hashrate display.   

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]

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

[jamesg]

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]

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]

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

If it aint broke dont fix it...  but it appears broke now

[TheHarbinger]

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.

[jjiimm_64]

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.

[jjiimm_64]

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.

[jamesg]

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/master

https://github.com/p2k/ecoinpool

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

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]

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

Code:

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

Code:

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......

[-ck]

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.

[-ck]

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.

[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]

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:

Code:

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.png

Before 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]

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.

[jamesg]

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.