Vardiff is awesome, it really is. We get good estimates of hashrates, miners always see shares submitted, etc. The down side of it, is a massive amount of overhead on the server side. We need to track all of the miners, their recently submitted shares, and their difficulties separately (memory). And then every 15-30 seconds or so, we need to calculate some averages (cpu time), push them to the clients (bandwidth), and then constantly check to make sure they're obeying them. The change from vardiff --> 512 was more of a necessity at the time. Tons more hashrate came on (and actually, this is _way_ more influenced by a large number of small miners, than by 1 big one - as we track it on a per connection level, high-hashrate single connection is tons lighter than 500 small guys), and our load spiked, bandwidth spiked (which caused orphaned blocks increase), and the simplest answer at the time was to hard-lock difficulty. After doing it, we noticed our server requirements are about 1/4, our orphan rate dropped significantly (2-3%), and overall there wasn't a _ton_ of backlash (some is to be expected, and I had to explain variance repeatedly).
Poolwaffle!
OK, we understand that vardiff uses cpu power. But why fixed 512? You know that this kills cpu miners. What would change if you would allow to set it lower and the default would be 512?
And those who are saying that higher diff only makes higher variance: I can have tens of machines running at 20-30 khash/s each. And yes my (say) weekly average share will be the same. But think about PPLNS! I lose the advantage of the LN part!
If i only find shares every 5-10 rounds then i will run like PPS.
And please don't misunderstand me, i highly appreciate and adore your work, and i also understand the need to change as the pool grows, but its frustrating to see my profitability plunge.
Edit: It's easy to misunderstand the PPLNS part. The sentence would be correct as: If i only find shares every 5-10 rounds then i won't benefit of PPLNS's "luck equalizer" effect.
Show Posts
