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

[aagert]

Well, don't panic, guys. Poolwaffle should soon wake up and make things right.

[1714929785]

1714929785

[1714929785]

1714929785

[1714929785]

1714929785

[1714929785]

1714929785

[1714929785]

1714929785

[Zamboniman]

Looks like we switched to doge...

[LordShanken]

So sad that wafflepool seems to be mining mincoin at the moment although it is not even in the top ten of profitable coins...

[rallasnackbar]

Looks like we switched to doge...

Some are, one of my miner is on a coin with diff 410K

[rallasnackbar]

So sad that wafflepool seems to be mining mincoin at the moment although it is not even in the top ten of profitable coins...

You cant really trust that list, but yes, mincoin is low. But i see 42 as higher then doge

http://www.coinwarz.com/cryptocurrency

[poolwaffle]

Sorry guys, was on an 11 hour flight.

Servers have been restarted, as well as the switcher.  I'll be looking into exactly what caused it in a bit here (need a nap), and will be getting more watchdog processes up to try to stop this from happening again (thought we had them working, apparently not).

[haploid23]

Where is the server located? I'm US west, and I'm getting a huge 230ms ping.

HOWEVER, despite this huge ping times, my rejected is less than 2%, whereas middlecoin gives me 6% rejected with only 65ms ping.

Lastly, does lowering the mining intensity from 20 to 18 on a card like the r9 290 reduce the rejected percentage? I know doing this on Middlecoin has huge benefits, so I'd like some confirmation on wafflepool as well.

[zneww]

Lowering your intensity on any pool would drop your rejects.

[comeonalready]

Lowering your intensity on any pool would drop your rejects.

I believe this to be specious advice, though I cannot with absolute certainty claim otherwise.  Read this, investigate further, and then decide for yourself.

Intensity is used to spawn GPU threads as a simple 2^value setting.
  I:13 =    8192 threads
  I:15 =   32768 threads
  I:17 =  131072 threads
  I:18 =  262144 threads
  I:19 =  524288 threads
  I:20 = 1048576 threads
Notice how the higher settings increase thread count tremendously.

In short, if raising intensity increases your rejects my x%, but it simultaneously increases your hashpower by more than x%, then you're better off despite the rejects.  And there are other causes for rejects too, outside of your control.  As such, you have to expand your time horizon before jumping to any conclusions.

[zneww]

My specious advice is not specious. Its fact. Thanks tho

[Speedie]

Lowering your intensity on any pool would drop your rejects.

I believe this to be specious advice, though I cannot with absolute certainty claim otherwise.  Read this, investigate further, and then decide for yourself.

Intensity is used to spawn GPU threads as a simple 2^value setting.
  I:13 =    8192 threads
  I:15 =   32768 threads
  I:17 =  131072 threads
  I:18 =  262144 threads
  I:19 =  524288 threads
  I:20 = 1048576 threads
Notice how the higher settings increase thread count tremendously.

In short, if raising intensity increases your rejects my x%, but it simultaneously increases your hashpower by more than x%, then you're better off despite the rejects.  And there are other causes for rejects too, outside of your control.  As such, you have to expand your time horizon before jumping to any conclusions.

It seems odd on the face of it, but decreasing intensity can actually result in higher accepted shares as well as lower rejects despite what may or may not be a lower raw hash rate. The formula for time taken to complete a specific set of work sent to the GPUs is expressed as ((2^I) / (hash rate *1000)).

Assume that a card is giving you 600KH/s.

At I18 it will take 0.4369s
At I19 it will take 0.8738s
At I20 it will take 1.7476s

"Aha" you say, "but it will take a little more than half the time to complete half the work each time you drop the intensity because the hash rate will drop slightly". True because there is a need to send work back and forth more often, and that introduces some slight inefficiency. But you also have a good chance to produce an accepted share within that smaller block of work and submit it before the work is stale, and that's why you can end up with both higher accepted shares and lower rejects.

For reference, I ran 9 identically configured 4MH/s rigs for 24 hours, each pointed at the same pool that gave them the same work difficulty (1024). The results expressed as average per rig were as follows:

I18 Accepted Work: 3,371
I19 Accepted Work: 3,405
I20 Accepted Work: 3,391

I18 Reject Rate: 1.84%
I19 Reject Rate: 3.17%
I20 Reject Rate: 4.34%

Since we get paid for accepted shares, I19 was the clear winner despite a marginally slower hash rate (approx. 4KH/s per GPU).

[zneww]

Welll....for the answer. Lower intensity will give you lower rejects. And less accepted shares. Doesn't take a rocket scientist.


Great info btw tho

[Speedie]

Welll....for the answer. Lower intensity will give you lower rejects. And less accepted shares. Doesn't take a rocket scientist.


Great info btw tho

Part in bold is not true. I18 or 19 will often result in higher accepted shares too.

[phzi]

Lowering your intensity is unlikely to significantly reduce your stales (most common rejects you will get on say middlecoin) on wafflepool, because wafflepool still accepts shares that are 1 block behind (just not 2 blocks behind).  Stop assuming stuff guys...

Also, stop using the old intensity system... xintensity will give you much more granularity and probably increase your hashrate a bit too.

[zneww]

Welll....for the answer. Lower intensity will give you lower rejects. And less accepted shares. Doesn't take a rocket scientist.


Great info btw tho

Part in bold is not true. I18 or 19 will often result in higher accepted shares too.

What? 18 and 19 get higher shares then 17. Thats what I said?

[Speedie]

Welll....for the answer. Lower intensity will give you lower rejects. And less accepted shares. Doesn't take a rocket scientist.


Great info btw tho

Part in bold is not true. I18 or 19 will often result in higher accepted shares too.

What? 18 and 19 get higher shares then 17. Thats what I said?

Didn't see any mention of 17 in your post? Specifically I was referring to the generalization that lower I equals lower accepted shares. 19 or 18 will often result in higher accepted shares than 20 as well as less rejects.

[zneww]

sorry I didnt mean 17 im high

[Speedie]

Also, stop using the old intensity system... xintensity will give you much more granularity and probably increase your hashrate a bit too.

Amen to that! Having spawned threads set as a perfect multiple of shaders is simply far more efficient. I also found that on my 7950s it let me run 2 threads at X4 with a 13KH/s improvement per GPU.

[comeonalready]

For reference, I ran 9 identically configured 4MH/s rigs for 24 hours, each pointed at the same pool that gave them the same work difficulty (1024). The results expressed as average per rig were as follows:

I18 Accepted Work: 3,371
I19 Accepted Work: 3,405
I20 Accepted Work: 3,391

I18 Reject Rate: 1.84%
I19 Reject Rate: 3.17%
I20 Reject Rate: 4.34%

Since we get paid for accepted shares, I19 was the clear winner despite a marginally slower hash rate (approx. 4KH/s per GPU).

I really like the types of test you've performed.  Though I'm not certain you've completely isolated the effects of variable conditions upon your results, as each rig was given its own unique stream of data to process, so the test inputs were not identical.   And without doing a whole bunch of math I don't particularly care to do, that approximately 4/10's of a percent improvement may very well be within the margin of error for the test conditions.  There are also factors such as gpu asic quality and other little things that may ultimately mean that your nine identically configured rigs are not truly identical.  But the real problem is that no one (as far as I know) has yet released a pool server emulator that can stream identical test data sets to separate mining rigs in order to obtain results of greater precision.  But the bottom line here is that even if you did not get it exactly right, you're really damn close, and what very little is left to tweak may not really be worth the effort, especially if it means taking your rigs off the live network in order to run tests for some statistically relevant period of time, and then even if you did, invariably some pieces of hardware are bound to fail eventually, and then you would have to revalidate your findings with additional testing all over again.

Anyway, the only reason I originally chimed in was because the advice given was a simple "lower is better" generalization, when in fact there are many more variables in play.

[qsrab]

I have a unconfirmed doge balance of about 400. Something is wrong. Either we found too small of block or payouts are wrong. With the small pool hash and large doge blocks it should be thousands