Topic: [ANN] CoinLab Protected Pool - page 32. (Read 97861 times)

I suggest you ignore the timestamp entirely so long as it's within 2 hours of the getwork generation since that's how the spec is implemented by mining software and other pools alike.

The spec seems to imply (to me) BOTH the allowed values of the timestamp AND a deadline time for which they will be accepted.  As a practical matter, we even accept work with larger timestamp rolls as long as the block being worked on is still current.

Please stop "experimenting" with the live pool.


Thanks.


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.

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.

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:


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.



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.

OK.  We are going to backing this change out now.

This is very true. Extra longpolls are very wasteful.

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.

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

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


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

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


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.

Just a suggestion, but you may want to try and point 50Gh at one worker, not just one 7970.

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.

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.

Time for me to update my mining software

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

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.

Hi CoinLab,

Are you rolling your own pool software? Why is the pool having issues where it would push miners away?

Thanks,
gigavps

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

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.

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

Anyone noticed huge percentage of rejects (~5% in my case) last days? Previous weeks I had almost zero rejects. Running cgminer on two rigs.