Topic: [POOL][Scrypt][Scrypt-N][X11] Profit switching pool - wafflepool.com - page 105. (Read 465668 times)

The original block acceptance scheme always made sense to me:
- Low consistent rejects are easy to understand - no need to compare reject rates against the pool or optimize for various situations we might not encounter very often (e.g. very low diff coins).
- Rigs that don't go crazy on tuning could gain a 1-2% bonus for being directed more often forward fast switching coins
- Rigs that are tuned to the max and optimized for litecoin can mine... well, litecoin or dogecoin (we mine LTC/Doge most of the time right now anyway), and gain from 1-3% higher hashrates.
- Disadvantage honestly seem minimal (a few percentage change in profitability figures?)

With the newer reject scheme, something like this is impossible, because the miners that were selected for fast switching coins would be penalized by higher reject rates.

I have been getting tempted to script my miners to change intensity based on the difficulty of the coin they are mining... Because the other way to look at all this, is that when we mine litecoin, my (and your) rigs are losing up to 3% profitability by being under-tuned.  And we mine litecoin a lot these days.

All this said, we've been on this share reject scheme for a while now, and it's working fine I suppose.

---

Any chance you could generate another miner switching time graph, PoolWaffle?  Would be interested to see what that looks like now.

pool work? I can not open stats

As I quoted later, PoolWaffle later provided updates as to the severity of the issue.  "Jacked up miners" were less significant then originally considered.

PoolWaffle also published a chart a long time ago that showed graphed miner's switching times.  Let me dig it up and provide some proper background on this, if you insist.

The "jacked up miners" thing is debunked, as far as I am concerned.  The new scheme now serves mainly to (statistically) penalize shares for fast switching coins and creates imbalance on a profit switching pool that mines multiple coins at once.

These 'reject' rates should be tracked internally, sure, but they are of main relevance to the coin switcher - not the miners. This seems an ideal way to balance portions of a switching pool into segments - your fast switching miners could be thrown around to different coins, and maybe even receive a small bonus (1-2%?) for this.  The slower switching miners tuned for a longer block coin can mine litecoin or another higher diff coin.

Missing payments? 

Can someone help me out here before I panic

I have a couple of payments which are showing up in the "details" but haven't shown up in my wallet which is reporting that it is synchronised with the net:

2014-04-01 08:50:24   0.01733143   02dfa6cbcc43eedb627322b38c93e7d1801cc3cfa7a363257795ff6cb24fd4fb
2014-03-31 18:30:45   0.01372869   ecb3ef699145d32c3b09b91e286e27fab340295b19c1c0a571dfaecf3cc02e4d

Given that I have a payment from today I assume that the payment engine isn't stuck so where are these two payments?

Many thanks

Miles

Then why are people talking about it now lol?

Has profitability increased since the change or is it still pretty much 0.05 btc/mh per day

Is the new fairer stratum system live yet?

I have no need to re-read something that I already understand.

What? no... that's not what it meant.  Miners were getting paid for shares the same across the board - every share was considered equal unless it was 2 blocks behind.
 

Alrighty guys.

I spent all of yesterday frantically hacking out a new stratum server.  It looks to be stable, looks to be a TON faster than our existing one, and should allow us to increase profitability overall.

That last part needs some explaining.  And I want to make sure everyone reads this closely and fully understands the reasons behind what is going to change before spewing out the comments that I know will follow.

Our previous (currently running) stratum server had a bit of forgiveness built into the share rejecting algorithm.  This came to be as a way to handle shares that were submitted on the boundary of switching coins.  So when we switched coins, if you submitted a share immediately following a chain switch, we would still accept the share and check against that chain.  This had the unfortunate (but seemingly minimal) effect of allowing shares in split second after seeing a new block on the same coin chain as well.  Didn't seem like a major thing, so it was left (and everyone was happy with the lower reject rates).

While testing the new stratum server, it has become apparent that this may have had a decent bit of effect on our profitability (especially in regards to being able to mine smaller coins).  What this bit of leeway did, was make it so that miners could crank up their intensity on their miners to a point where the miner would be so busy looking for new shares, that it would delay the submitting of found shares by a slight margin ("slight" being undefined here).  However, when a coin switch happened, or when a new block was found, and we sent new work to the miner, the miner would be forced to do a pipeline flush (read "stop working" for a very short bit).  During that time, these jacked up miners would submit the shares they hadn't submitted yet.  We would accept them because they were coming in just after a switch, and we were being forgiving.  However, in most cases (block changes are far more often than coin switches), these shares had a 0% profitability (they were stale).

This became extremely apparent when watching share timings with the new stratum endpoint.  Assuming normal mining, shares should be submitted at a very even rate over time, with slight drops in valid shares immediately following a work restart (new block, coin switch), and a bump in stales during that time.  With the new server (which rejects these stale shares by default), we see a reasonably even amount of shares, and a huge bump (30-40%) of shares submitted immediately following a block change.  On faster coins, these block changes are every few seconds, and that delay makes a huge difference in profitability.

So, while everyone had lower reject rates due to this, miners taking advantage of it were getting more than their fair share of shares, and were dropping our profitability of the whole pool by not submitting shares as soon as they were found, as well as making mining small coins exponentially less profitable.

What does that mean for you?
When the new stratum servers go into production, you will see a bump in rejected shares, however this bump in rejected shares will be across the entire pool.  And in a PPLNS environment, all that matters is your rejected rate compared to everyone else's.  The second part of this is that miners that are currently taking advantage of the pool will either have insane reject rates, or need to configure their miner to actually submit shares on time, causing our overall profitability to go up.

I'm going to bet a lot of the miners doing this don't actually know they're doing it (and neither did I until recently obviously), they've most likely kept pushing their device further and further, and since they never got higher reject rates, everything seemed fine.  If you're one of these miners, when the new servers go live, you'll likely see a decent bump in reject rate (more in line with other pools).  You'll need to re-tune your miner to aim for more accepted shares (rather than just raw number of shares).

This new stratum server is in testing, and will likely be released later today/tomorrow assuming everything goes fine.

Let the hate spewing begin.

Please re-read PW's explanation of the difference between the way the previous stratum implementation and new stratum implementation works: https://bitcointalksearch.org/topic/m.5762701

The pool was being overly forgiving in giving credit to shares that were actually stale after a coin switch.  This means miners were being paid for shares that did NOT have corresponding profit for the pool to pay us with.

How was this fair again?

Your argument on low-diff coins and relative rejects between the two has absolutely nothing to do with what I was saying.

phzi, we all know the real reason you think the old system was more preferable.  It was because you purposefully overtuned your miners to submit as many shares as possible, regardless of whether they were valid, in order to claim more shares for yourself.  You have already brazenly admitted to gaming the old more lenient system and essentially cheating fellow miners out of some of their rightful profits.

As for phzi, certainly didn't mean to call anyone out on the miner tweaking, just noticed it was happening, and wanted to fully explain what was going to happen with the new software (and why).  I honestly expected a bit higher than 2-3% overall (expected 5-7% and thus more complaining on the forum), but 2-3% seems to be taken really well.  From his perspective, everything he did made sense.[...]

So that would mean you were one of the miners who were taking up to 10% more of your fair share of profits from the pool, however unknowingly.  For the others who had their equipment tuned correctly for mining almost anywhere else than wafflepool, they were receiving up to 10% less of profits directly due to their efforts, depending upon the ratio of efficient to inefficient miners in the pool.  The actual percentages depend upon whether wafflepool was actually a pool of fools, and only poolwaffle knows that as he is the only one with access to the relevant statistics.

Clearly the new system is much fairer to the more ethical members of the pool, as payouts are distributed according to how may valid shares are submitted to the pool.

phzi, we all know the real reason you think the old system was more preferable.  It was because you purposefully overtuned your miners to submit as many shares as possible, regardless of whether they were valid, in order to claim more shares for yourself.  You have already brazenly admitted to gaming the old more lenient system and essentially cheating fellow miners out of some of their rightful profits.