[POOL][Scrypt][Scrypt-N][X11] Profit switching pool - wafflepool.com

[jedimstr]

Please re-read PW's explanation of the difference between the way the previous stratum implementation and new stratum implementation works: https://bitcointalk.org/index.php?topic=433634.msg5762701#msg5762701

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

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.

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.
 

I'm quoting PW directly... so don't know where you're getting your info except from thin air... again I made it easy for you by linking directly to where PW said this before implementing the new Stratum.

Here, let me make it even easier for you:

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.

So... please, enlighten me where my paraphrase of what Poolwaffle said previously was wrong?  Sounds pretty identical to me.

[1714311371]

1714311371

[dogechode]

Is the new fairer stratum system live yet?

[jedimstr]

Is the new fairer stratum system live yet?

I believe it's been live for two weeks.

[dogechode]

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

[jedimstr]

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

*shrug*

Probably people starting to notice their higher reject rates and confused due to their recollections of the artificially low reject rates from days of yore.  Without seeing that explanation post, I'd be confused too.

[poolwaffle]

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

Please run a resync on your wallet.  Both were broadcast successfully and confirmed on the network.  If your wallet isn't showing them, its likely a wallet issue (normally fixed with a resync, or a new wallet)
https://blockchain.info/tx/02dfa6cbcc43eedb627322b38c93e7d1801cc3cfa7a363257795ff6cb24fd4fb
https://blockchain.info/tx/ecb3ef699145d32c3b09b91e286e27fab340295b19c1c0a571dfaecf3cc02e4d

[phzi]

<snip>
So... please, enlighten me where my paraphrase of what Poolwaffle said previously was wrong?  Sounds pretty identical to me.

As I quoted, 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 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.

[poolwaffle]

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.

This is roughly correct, and a decent bit of the reason the new switcher assigns rotating sections of the pool.  Having a 10% reject rate on a certain coin is worth it if that coin is 11% more profitable overall, however, during that time obviously the miner getting the 10% reject rate is at a slight disadvantage, as long as that slight disadvantage rotates around the pool evenly, everything works out fine.  I haven't seen anything yet to raise suspicion that users are abusing this, but it wouldn't be tough to either credit the X% over average stalerate that a faster coin should yield, or to detect it to begin with.  Due to the short amount of time we actually mine coins that have fast block times to begin with, trying to abuse it is probably not very effective anyway, but I'll definitely start adding some monitoring for it and see if anything comes up.

[phzi]

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.

[Multipulty]

pool work? I can not open stats

[phzi]

pool work? I can not open stats

No problems here.  Web frontend and stratum are up.

[Thirtybird]

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.

If your miner displays U (utility), do a test... (If it doesn't use mine and ask your dev to put it into yours).  Utility is the difficuly shares accepted by the pool divided by how long the miner has been running.  Everyone has been brainwashed into the "The higher the WU, the better" - it's only slightly hogwash.  If certainly does help your adjust your miner to achieve higher results, but what REALLY matters is the shares being accepted by the pool.  Try this with any coin you like, but do this test fairly.  Run normally, with an xIntensity of 32, 64 or even 128, record your U after 6 hours.  Stats normalize over a very long time - I would say 24 hours, but I would accept 6..  Then, restart your miner with your xIntensity 11000 or whatever you're saying works better.  I am genuinely interested if this type of tactic improves your _accepted_ share rate.  Do this on litecoin or whatever pool you think this works on.  From what I've seen of the code I'd like to know if it's just a trick that occurs with the system timer or if you really are getting more accepted shares.

Please, post your results!

[LPCobris]

Hi!
Well this was a long time coming...

Im shutting down 75% of my mining farm... Im just letting 25% on just to keep the "candle" on...
with the low profitability atm on alt coin + low value of BTC, i can´t pay the energy that it takes to mine the coins...

I will wait until the end of the month to see if the situation improves... If not... i will sell my systems and maybe get some ASIC Scrypt... they don´t hash much, but also don´t consume too much... 7w is a major plus.

Best Regards,

LPC

[Multipulty]

Site statistics does not work?
or is it just me?

[toxic0n]

New version of Waffle Widget has been released: (or will be shortly once Google Play shows the new version)

https://play.google.com/store/apps/details?id=com.inductiveconcepts.wafflewidget

• Fixed - Issue with display of some balances
  
• Added - Support for configurable refresh interval! You can now set refresh periods in one minute increments. Please don't set this too short as it may drain your battery

Coming soon:
Other currencies
Multiple workers
Customizable colors

(depends on whether I'm going out this weekend   )

[phzi]

<snip>

Please, post your results!

I have done this sort of test on many pools - yes, increasing threads (via xintensity) will increase your actual share output (with diminishing returns as the values get higher).

On a litecoin pool, running xintensity 1100 instead of 500 or 80 or etc results in increased accepted work.

[JHammer]

Why is Clever Mining Kicking our ass?   

And what does PW have going on to make WP better?

[phzi]

Why is Clever Mining Kicking our ass?   

And what does PW have going on to make WP better?

CM's returns have been slightly below WP for the last 4 days, so not sure what you're talking about.

You can read back in this thread about some of the many potential projects PoolWaffle has planned.

[JHammer]

Why is Clever Mining Kicking our ass?   

And what does PW have going on to make WP better?

CM's returns have been slightly below WP for the last 4 days, so not sure what you're talking about.

You can read back in this thread about some of the many potential projects PoolWaffle has planned.

https://bitcointalk.org/index.php?topic=514242.0

[ak111in]

Site statistics does not work?
or is it just me?

You can try www.wafflepoolmonitor.com for graphs.