An update on our LONGPOLL experiment.
Please stop "experimenting" with the live pool.
Point taken.
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.
Our server is configured to allow longpolls to be held open for up to 90 minutes; after that the connection is dropped (and the client should see the dropped connection so it can re-establish it). It's possible we have some other bug in our pool, but our median work age runs about 45 seconds - so it seems the majority of miners are having no problem getting recent work. Regardless of long-poll connections dropping, our headers clearly indicate (to me) that the work should be refreshed each 60 seconds. So even if we do have a bug where miners are silently having their long-polls dropped, they should be unilaterally fetching new getwork every 60 seconds.
As to the policy of accepting older work - we wanted to remove any consideration of communication latency being a barrier to adopting our pool. We assume the risk of latency we introduce into the system - as a miner, you get credit for all work you do (as long as you get reasonably fresh work from us - i.e., no more than 60 seconds old). We felt that places the incentives on us to improve our pool performance, but doesn't penalize miners when we have latency issues.