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

[poolwaffle]

A few more quick updates:

1) Leafcoin has been added.  It forked earlier today, so a ton of people are on the wrong branch, I've confirmed we're on the correct one.

2) A few coins were disabled.  Our host had some issues yesterday, and a few of the blockchains got corrupted on endpoints, they're removed from mining while syncing, and will be added later tonight.  These are: philosopherstone and diamond.

3) Tagcoin is disabled for the forseeable future.  It always looks to have great profitability, but every time we turn it on, we get ~50% orphans.  Until this gets sorted out, it will be disabled and tested here and there.

4) Elacoin is disabled for now until Cryptsy processes our existing deposits.  I don't want to be stuck mining something if they never confirm at the exchange.


I want to get in some code later that will notice blockchain problems on our endpoints.  Right now, we have to disable mining a coin completely if one of the endpoints needs to resync the blockchain.  I'd prefer to have it just disabled on one endpoint (and mine the 2nd most profitable during that time).


Which brings me to something that I need your guys' input on:
Recently we've been a bit below what I would hope for earnings (0.01 instead of 0.013ish).  I think this has to do with our current reject policy.  We currently accept slightly stale shares, what that means is that when a block switch happens (or a coin switch, same thing from server side), we keep accepting shares for 1-old block switch (we'll call these "1-stale" shares).  If a share is "2-stale" (stale by 2 block switches) it is rejected.  This was originally a "nice" thing to have on the server, as it makes users who join see fewer rejects, and earlier on, our profitability switcher was not nearly as aggressive as it is now in terms of coin switches (was switching every 30-60 seconds or so, now much faster).

I think some of our profitability deficit comes in from this policy.  By allowing 1-stale shares, users have no incentive to tune their miner for the most number of valid shares, but instead, tweak their miner for raw number of shares (regardless of if they are 1-stale or not).  This leads to miners to unfortunately crank up their miners as much as they can (higher intensity, queues, etc), to get higher hashrates, but this also leads to a larger number of 1-stale shares as a result.

By rejecting 1-stale shares (which extremely rarely lead to solved blocks), the overall reject rate of the pool will definitely increase (in line with other switching pools), but after configuring miners correctly to reduce rejected shares, overall effective hashrate (block finding) will most likely increase, as well as profitability.

Since this is a reasonably major change (not code wise, but end user perception wise) I'd like some input before I do it, that said, I really do think it is work doing.

tldr We should reject "1-stale" shares for better profitability, but some users will be all "WTF MY REJECTS ARE HIGHER NOW!!!?!".  Should we reject "1-stale" shares Yes/No?

[1714653639]

1714653639

[1714653639]

1714653639

[1714653639]

1714653639

[pallas]

The payout is what really counts: if somebody chooses your pool because of low rejects, and then he sees lower than expected revenue, he'll switch anyway.

[Ledningen]

IMO: I think it's bothersome to adjust my miners for low reject rates, when I want to mine on multipools. Therefore, I think it's great that you don't have to do that in this pool.

[Vbs]

(...)
tldr We should reject "1-stale" shares for better profitability, but some users will be all "WTF MY REJECTS ARE HIGHER NOW!!!?!".  Should we reject "1-stale" shares Yes/No?

Yes!

At least for a few days (a week maybe?) so that you can have some real data to see how those stales affect profitability overall.

[ShibeonBarkmont]

tldr We should reject "1-stale" shares for better profitability, but some users will be all "WTF MY REJECTS ARE HIGHER NOW!!!?!".  Should we reject "1-stale" shares Yes/No?

+1 for Yes

[Vbs]

Actually, there should be a variable time interval for accepting stales depending on the coin being mined. There is a higher probability of stales contributing to finding blocks on faster coins (lower diff) than on slower ones (higher diff).

You could stop accepting stales when the probability of finding a block for a particular coin falls below a threshold (50%?). This will depend on the coin's diff and pool's hashrate still on it.

[Zoella]

tldr We should reject "1-stale" shares for better profitability, but some users will be all "WTF MY REJECTS ARE HIGHER NOW!!!?!".  Should we reject "1-stale" shares Yes/No?

I'll admit, I get quite a few stale submits on low diff coins. I'll just have to play around with my settings to get things working more smoothly. Although I saw this right after reading your post and thought it was kind of humorous timing.

 [2014-02-11 06:46:09] Stratum from pool 0 detected new block
 [2014-02-11 06:46:16] Found block for pool 0!
 [2014-02-11 06:46:16] Pool 0 stale share detected, submitting as user requested
 [2014-02-11 06:46:16] Accepted 6395b453 Diff 168K/128 BLOCK! GPU 1 pool 0
 [2014-02-11 06:46:21] Accepted 01f8445a Diff 130/128 GPU 1 pool 0

EDIT:
I like Vbs' idea!

[Vbs]

poolwaffle, are you sending "Clean Jobs == true" on the stratum work packet? (params[8] == true)

This should minimize stales.

[poolwaffle]

poolwaffle, are you sending "Clean Jobs == true" on the stratum work packet? (params[8] == true)

This should minimize stales.

Yep.  We send it on every work change request that isn't difficulty adjustment (which we send again after 30 seconds with the flag if the user isn't respecting the new difficulty).

But we're seeing a TON of shares submitted a significant amount of time after the clean jobs request.  A lot of them 15-20 seconds after telling them the old work isn't valid, and those shares are still being accepted, which leads me to the guess that people have pushed their miners to max out hashrate (and in this case accepted shares) rather than actual accepted shares.

[comapro]

tldr We should reject "1-stale" shares for better profitability, but some users will be all "WTF MY REJECTS ARE HIGHER NOW!!!?!".  Should we reject "1-stale" shares Yes/No?

yes

[qsrab]

If the 1 block old shares have any chance of resulting in a valid block (they do) they should be accepted! Rejecting them only makes profitability "look" higher while it is actually lower. You were the only pool doing this right don't be like the crap pools!

[qsrab]

poolwaffle, are you sending "Clean Jobs == true" on the stratum work packet? (params[8] == true)

This should minimize stales.

Yep.  We send it on every work change request that isn't difficulty adjustment (which we send again after 30 seconds with the flag if the user isn't respecting the new difficulty).

But we're seeing a TON of shares submitted a significant amount of time after the clean jobs request.  A lot of them 15-20 seconds after telling them the old work isn't valid, and those shares are still being accepted, which leads me to the guess that people have pushed their miners to max out hashrate (and in this case accepted shares) rather than actual accepted shares.

Most of the late shares are probably from people mining on high intensity. Why not give 5 seconds of time rather than 1 block of time?

[poolwaffle]

If the 1 block old shares have any chance of resulting in a valid block (they do) they should be accepted! Rejecting them only makes profitability "look" higher while it is actually lower. You were the only pool doing this right don't be like the crap pools!

The problem is, there are times when it is possible, and there are times when it is not possible.  The times where it is possible is _significantly_ less than the times that it isn't.

Coin1 --> Coin2 :: "1-stale" still possibly a block find
Coin1 --> Coin2, Coin1 moves to a new block :: "1-stale" not useful
Coin1 --> Coin1 (new block) :: "1-stale" not useful

Also, it depends a lot on the actual hashrates that come through.  For example, if we allow "1-stale" shares, and say 1% of them would be valid blocks, thats awesome, we get 1% more blocks, hooray!  However, if by accepting those "1-stale" shares, we end up having miners over-tuning their cards (because they get more shares) by 2% (extremely conservative estimate), yeah, we're finding those 1% more blocks, but we're losing 2% of our overall power.  Not only are we losing out overall as a pool, the people tuning their cards heavier are actually taking a larger slice of the pie than they should (they're contributing less valid shares, and getting more accepted).

I don't see a downside of rejecting 1-stale shares except for the negative of users getting pissed that their reject rate skyrockets overnight.

[poolwaffle]

Most of the late shares are probably from people mining on high intensity. Why not give 5 seconds of time rather than 1 block of time?

Exactly my point.  Just curious though, we have pretty good geo-coverage now, whats the advantage of 5 seconds over 1 second (or 0 seconds)?  Just sort of playing devils advocate, but what that essentially does is just moves the needle a _little_ closer.  If we chose 5 seconds, why not 4?  4 would encourage users to tweak for better (more accepted shares), and then if 4 is better than 5, why not 3? etc...

[Vbs]

poolwaffle, are you sending "Clean Jobs == true" on the stratum work packet? (params[8] == true)

This should minimize stales.

Yep.  We send it on every work change request that isn't difficulty adjustment (which we send again after 30 seconds with the flag if the user isn't respecting the new difficulty).

But we're seeing a TON of shares submitted a significant amount of time after the clean jobs request.  A lot of them 15-20 seconds after telling them the old work isn't valid, and those shares are still being accepted, which leads me to the guess that people have pushed their miners to max out hashrate (and in this case accepted shares) rather than actual accepted shares.

I see.

Since avg_time_block = (coin_difficulty * 2^32) / pool_hashrate_on_coin, you could, for example, reject stale share submissions after avg_time_block doubles (meaning more than 50% of the pool has already switched over to the new coin).

If the 1 block old shares have any chance of resulting in a valid block (they do) they should be accepted! Rejecting them only makes profitability "look" higher while it is actually lower. You were the only pool doing this right don't be like the crap pools!

The problem is the probability of finding a block in the old coin tends very quickly to zero, as less and less miners are mining the old coin.

Once more than 50% of miners have switched, stales should be discarded.

[qsrab]

Most of the late shares are probably from people mining on high intensity. Why not give 5 seconds of time rather than 1 block of time?

"Coin1 --> Coin2, Coin1 moves to a new block :: "1-stale" not useful"

I don't know that 5s is better than 10s or 1s, but its better than 0s because submitting a block from the 1-stale share could orphan the coin1 block that another pool or miner found.

Actually 5s is probably too long. Something like 1s or 2s would penalize poorly configured miners without throwing away the legitimate hashes that happen every with every new block.

[poolwaffle]

Here's a quick graph put together showing how long switches are taking:

http://wafflepool.com/switcher_time

Just from an arbitrarily picked timestamp, 2 minute sample.  Things to note:
1) It takes about a full second for the switcher to get all the servers on the right coin (done sequentially currently).
2) It takes the actual stratum server about 0.01 seconds to broadcast to all the miners  the new coin information (+ latency per miner)
3) About 25% of our mining power switches over to the new coin within a few seconds (reasonable), and the other 75% catches up about 10 seconds after a switch (I thought it was longer, hadn't actually graphed it yet).

Thoughts?  10 Seconds seems like a long time when a lot of alt-coin block times are 30-40 seconds.

[qsrab]

looks like accepting the old block for 3-5 seconds is reasonable but not more or less

[Krasen]

If only we could see some other multipool switcher time ... ?

Looking at the graph its very strange, and my inner feeling is that the problem is not with the miners, but with your configuration for the switcher. Something, somewhere is delaying the switch for the miners.

It takes about 3 seconds for the majority to stop mining and then after the first 7 seconds, a new 3 seconds for the majority to mine the new coin. I think we must look closeley what happens those 7 seconds of mining the new coin. Its not that some miners are very slow for the switch, but appears that some miners are Very fast to mine the new coin ?

Sorry if i'm talking stupid things that make no sense.

[poolwaffle]

Not to derail this (definitely important), but another major thing we need to discuss is Cryptsy.

Most of our current trading is done through cryptsy, since they provide an API that lets us do (almost) everything we need to do (deposit, check balances/prices, trade).  The only thing that has to be done manually is to withdraw BTC each day for payouts.

They've however, gotten slower and slower over the past days, to the point that we have ~2btc in Elacoin that still hasn't shown up (>1500 confirmations), and ~4 btc in Dogecoin that haven't shown up (>300 confirmations).

I've halted sending new amounts to cryptsy for now, as I don't want to have any more in limbo, and have started looking into what it would take to manually trade on another exchange.  Unfortunately, none of the exchanges support all of our coins (or even most of our coins), but we can always split them to multiple exchanges.  This again brings up the risk of taking time between earning coins, and being able to trade them (manually), but that seems like less of a serious detriment as cryptsy is causing the same issue (we send coins, and don't get to trade them for a many hours).

Here are the exchanges I've found, and what of our coins they support:
Vircurex:
DGC, DOGE, LTC, WDC

Bter:
LTC, BTB, CNC, DGC, DOGE, MEC, NET, TAG, WDC

MCX:
LTC, FTC, MNC, WDC

CoinEx:
CAP, CAT, DGC, DOGE, FTC, LKY, LOT, LTC, MEC, MNC, MOON, PHS, PXC, WDC

CoinsE:
ALF, DOGE, ELC, FTC, FRK, GRD, GLC, LTC, MEC, NET, SBC, SPT, TAG, WDC


CoinEx/CoinsE look to have the most matches, but for our speed, the depth is a joke (many coins sub 1 btc bid depth).  Not sure trading there is even worth it (we'd destroy their depth super quickly).

Anyone have any ideas on other exchanges that have better depth?