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

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

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.

"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.

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).


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.

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...

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.

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?

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!

yes

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.

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

This should minimize stales.

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!

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.

+1 for Yes

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.

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.

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.

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?

Conversion was disabled last night.  I was halfway through the code changes for better trading practices, but they weren't done, and I didn't want to test them half-asleep.  They've been re-enabled this morning, and I made sure everything that could be traded was traded before processing payments.

Leaf is syncing blockchain, expected to be added later today

Is there any problems with conversion? A lot of confirmed DOGE has been sitting around for a while and there was a long period last night - about 10 hours - where there was no increase in BTC balance, only in unconverted. Theres also a couple of other coins with long-term unconverted balances on them.

Also can we add leaf coin ASAP its on Cryptsy and very profitable