[4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool

[digital]

I know slush has an ongoing project related to switching over to DGM.  He has been working on it for quite a while now (in his spare time, lol), but I'm not sure how close he is to completing it.

I'm not saying that there aren't any good suggestions out there, but I'm guessing he will just finish that project before implementing any other changes to the scoring algorithm.  And in my opinion, that would probably be the best for everyone.  We could say goodbye to loosing 25% on rounds under 10 minutes...

[1713585350]

1713585350

[1713585350]

1713585350

[1713585350]

1713585350

[1713585350]

1713585350

[Kruncha]

I am happy with the score based calculation as well, re-introducing PPS would not be a good idea. Supporting multiple payout plans would just add unnecessary complexity and demand a lot of effort.

Having said this, I do have some thoughts on the periodic resets:

• I could not find the periodic reset documented at https://bitcointalk.org/index.php?topic=1976.msg50002#msg50002 which is the "official description" of how rewards are calculated AFAIK.
• Theoretically, the exponential nature of the scoring algorithm without the resets would do a great job against hopping.
• In practice, for long running rounds, the scores might get very large, causing an arithmetic overflow. Maybe this is the only reason for the resets, but I am just guessing. If so, a mathematically correct fade out instead of the reset might be a viable option.

I might be missing something, so just correct me in case...

Cheers,
   T

The resets make no difference to the score. Your proportion is still the same. The only difference the resets make is that they mean Slush doesn't have to deal with numbers with 100 digits.

Well, they do make a difference, as it had been pointed out before. My initial thought was to perform the following instead of the reset:

1) Divide by a big number & round everyones score to maintain the proportions but get rid of a lot of digits.
2) Adjust the constant C (currently always 300) according to the big number used for the division - logarithmic. (so at the end, the algorithm maintains the same curve, scaled down)

I do not want to raise a flame war, and note that I was not complaining either - but am open to any discussion on the maths behind this.

Cheers,
   T

I'm not quite sure what is it you think the reset does. Can you explain your thoughts on it, preferably with a link to Slush saying something similar?

Basically, it means when the score resets to zero, any slow miners that don't submit a share, loose all their shares value (this is to prevent pool hopping, I get that).

If i have 300 shares and the score resets, my shares are only worth anything if i get another one share in before the end of the round.

K.

[organofcorti]

I am happy with the score based calculation as well, re-introducing PPS would not be a good idea. Supporting multiple payout plans would just add unnecessary complexity and demand a lot of effort.

Having said this, I do have some thoughts on the periodic resets:

• I could not find the periodic reset documented at https://bitcointalk.org/index.php?topic=1976.msg50002#msg50002 which is the "official description" of how rewards are calculated AFAIK.
• Theoretically, the exponential nature of the scoring algorithm without the resets would do a great job against hopping.
• In practice, for long running rounds, the scores might get very large, causing an arithmetic overflow. Maybe this is the only reason for the resets, but I am just guessing. If so, a mathematically correct fade out instead of the reset might be a viable option.

I might be missing something, so just correct me in case...

Cheers,
   T

The resets make no difference to the score. Your proportion is still the same. The only difference the resets make is that they mean Slush doesn't have to deal with numbers with 100 digits.

Well, they do make a difference, as it had been pointed out before. My initial thought was to perform the following instead of the reset:

1) Divide by a big number & round everyones score to maintain the proportions but get rid of a lot of digits.
2) Adjust the constant C (currently always 300) according to the big number used for the division - logarithmic. (so at the end, the algorithm maintains the same curve, scaled down)

I do not want to raise a flame war, and note that I was not complaining either - but am open to any discussion on the maths behind this.

Cheers,
   T

I'm not quite sure what is it you think the reset does. Can you explain your thoughts on it, preferably with a link to Slush saying something similar?

Basically, it means when the score resets to zero, any slow miner that doesn't submit a share, looses all their shares value (this is to prevent pool hopping, I get that).

If i have 300 shares and the score resets, my shares are only worth anything if i get another one share in before the end of the round.

K.

Unless Slush has changed the way the reset works, that is an incorrect description.

[TiborB]

Well, they do make a difference, as it had been pointed out before. My initial thought was to perform the following instead of the reset:

1) Divide by a big number & round everyones score to maintain the proportions but get rid of a lot of digits.
2) Adjust the constant C (currently always 300) according to the big number used for the division - logarithmic. (so at the end, the algorithm maintains the same curve, scaled down)

I do not want to raise a flame war, and note that I was not complaining either - but am open to any discussion on the maths behind this.

Cheers,
   T

I'm not quite sure what is it you think the reset does. Can you explain your thoughts on it, preferably with a link to Slush saying something similar?

Unfortunately I did not see this reset documented when Slush explained the scoring calculation (to which I did include the link). We observed that score resets are happening periodically, I assume the reason is to prevent an arithmetic overflow.

The cheapest way (in terms of both db performance and implementation effort) of performing a reset is zeroing out all the scores and simply carrying on the calculation without touching C or scaling back the round time (both of which would be the same). This would obviously not maintain the same characteristics, especially, if the round ends very close to the reset. What I have written is 'scaling down' rather then resetting existing scores, I hope the difference is clear - to maintain the proportions of the scores while also getting rid of digits.

Again, I am drawing conclusions based on observations since I could not find info about how resets are performed - the conclusions might therefore be right or wrong, and I try to be correct/careful about the wording as well. Does anyone know more details of how exactly the scores are currently reset?

Cheers,
   T

[Kruncha]

I am happy with the score based calculation as well, re-introducing PPS would not be a good idea. Supporting multiple payout plans would just add unnecessary complexity and demand a lot of effort.

Having said this, I do have some thoughts on the periodic resets:

• I could not find the periodic reset documented at https://bitcointalk.org/index.php?topic=1976.msg50002#msg50002 which is the "official description" of how rewards are calculated AFAIK.
• Theoretically, the exponential nature of the scoring algorithm without the resets would do a great job against hopping.
• In practice, for long running rounds, the scores might get very large, causing an arithmetic overflow. Maybe this is the only reason for the resets, but I am just guessing. If so, a mathematically correct fade out instead of the reset might be a viable option.

I might be missing something, so just correct me in case...

Cheers,
   T

The resets make no difference to the score. Your proportion is still the same. The only difference the resets make is that they mean Slush doesn't have to deal with numbers with 100 digits.

Well, they do make a difference, as it had been pointed out before. My initial thought was to perform the following instead of the reset:

1) Divide by a big number & round everyones score to maintain the proportions but get rid of a lot of digits.
2) Adjust the constant C (currently always 300) according to the big number used for the division - logarithmic. (so at the end, the algorithm maintains the same curve, scaled down)

I do not want to raise a flame war, and note that I was not complaining either - but am open to any discussion on the maths behind this.

Cheers,
   T

I'm not quite sure what is it you think the reset does. Can you explain your thoughts on it, preferably with a link to Slush saying something similar?

Basically, it means when the score resets to zero, any slow miner that doesn't submit a share, looses all their shares value (this is to prevent pool hopping, I get that).

If i have 300 shares and the score resets, my shares are only worth anything if i get another one share in before the end of the round.

K.

Unless Slush has changed the way the reset works, that is an incorrect description.

I'm running just 100mhs, Slush hasn't changed anything, I'm not trying to be shitty, it's just how it is. Hopefully Slush can confirm.

I'm not here to cause greif, I want to help...

K.

[joolzg]

I know slush has an ongoing project related to switching over to DGM.  He has been working on it for quite a while now (in his spare time, lol), but I'm not sure how close he is to completing it.

I'm not saying that there aren't any good suggestions out there, but I'm guessing he will just finish that project before implementing any other changes to the scoring algorithm.  And in my opinion, that would probably be the best for everyone.  We could say goodbye to loosing 25% on rounds under 10 minutes...

why, 10 minute rounds are good for everyone, so losing 25% is not good. I would like 24 hours of just 10 minute blocks, but to lose 25% of my reward is not what i would like.

Is there some rational behind this?

joolz

[digital]

I know slush has an ongoing project related to switching over to DGM.  He has been working on it for quite a while now (in his spare time, lol), but I'm not sure how close he is to completing it.

I'm not saying that there aren't any good suggestions out there, but I'm guessing he will just finish that project before implementing any other changes to the scoring algorithm.  And in my opinion, that would probably be the best for everyone.  We could say goodbye to loosing 25% on rounds under 10 minutes...

why, 10 minute rounds are good for everyone, so losing 25% is not good. I would like 24 hours of just 10 minute blocks, but to lose 25% of my reward is not what i would like.

Is there some rational behind this?

joolz

That's how pool hopping works.  The pool hoppers will come in for the first x minutes of a round.  If a bock is found they profit, if it's not found after x minutes, they leave and go somewhere else, or mine solo. 

It's a simplified description of pool hopping, but it results in a lower payout on short blocks for the miners that are here all day every day.  If you go down the list of payouts, you will see a pattern where blocks under 10 minutes will have a lower than average payout.  This is the reason for that.

[digital]

And don't get me wrong, everyone loves short blocks.

It would just be even better if they met the average payout.  And that's why slush has been looking into the DGM scoring algorithm.

[Kruncha]

I know slush has an ongoing project related to switching over to DGM.  He has been working on it for quite a while now (in his spare time, lol), but I'm not sure how close he is to completing it.

I'm not saying that there aren't any good suggestions out there, but I'm guessing he will just finish that project before implementing any other changes to the scoring algorithm.  And in my opinion, that would probably be the best for everyone.  We could say goodbye to loosing 25% on rounds under 10 minutes...

why, 10 minute rounds are good for everyone, so losing 25% is not good. I would like 24 hours of just 10 minute blocks, but to lose 25% of my reward is not what i would like.

Is there some rational behind this?

joolz

A block is worth roughly (25BTC at time of writing) and as long as you stick with Slush, you'll get the best rewards, because he pays for success, and the more people mining with him means more success.

K.

[Hippie Tech]

I am happy with the score based calculation as well, re-introducing PPS would not be a good idea. Supporting multiple payout plans would just add unnecessary complexity and demand a lot of effort.

Having said this, I do have some thoughts on the periodic resets:

• I could not find the periodic reset documented at https://bitcointalk.org/index.php?topic=1976.msg50002#msg50002 which is the "official description" of how rewards are calculated AFAIK.
• Theoretically, the exponential nature of the scoring algorithm without the resets would do a great job against hopping.
• In practice, for long running rounds, the scores might get very large, causing an arithmetic overflow. Maybe this is the only reason for the resets, but I am just guessing. If so, a mathematically correct fade out instead of the reset might be a viable option.

I might be missing something, so just correct me in case...

Cheers,
   T

The resets make no difference to the score. Your proportion is still the same. The only difference the resets make is that they mean Slush doesn't have to deal with numbers with 100 digits.

That's not true, if the score resets on a slow miner and they don't submit a share before the end, they loose everything.

K.

That's called variance.  That slow miner could theoretically grab another share or two between the reset and the round ending and end up with a higher score than normal too.  You never know when the shares are gonna come.  You just can't say that you always loose out, because it's simply not the case.

+1 Timing/ luck is everything.

Last month I decided to have some fun and set the 6870 and 5850 set to diff-42 and the 7870 to diff-105 shares. My then 1070 mhash/s at diff-1, would have averaged 0.005 - 0.008 at the time if I'm not mistaken.

[TiborB]

I know slush has an ongoing project related to switching over to DGM.  He has been working on it for quite a while now (in his spare time, lol), but I'm not sure how close he is to completing it.

I'm not saying that there aren't any good suggestions out there, but I'm guessing he will just finish that project before implementing any other changes to the scoring algorithm.  And in my opinion, that would probably be the best for everyone.  We could say goodbye to loosing 25% on rounds under 10 minutes...

Thanks for sharing this. For the reference of others readers, a description of Double Geometric Method can be found here: https://bitcointalk.org/index.php?topic=39497.0
I enjoyed reading it. Note points on periodic rescaling and logarithmic scale.

Cheers,
   T

[Lucko]

Well there are some things in slush method that I couldn't find described anywhere and I figure them out or someone told me on IRC.

One if a worker goes offline for more then 30 minuts don't turn it on agen till end of a block. If you do restart it it will reset scores for all the workers. I don't get why we have this one. So I just start it with a diffident username from the working worker or put it on a backup PPS pool till the end of a block...

If you have a slow miner(CPU) it can affect your payouts dramaticly(probably because it didn't send any results in for 30 minutes). And never in a good way from my experiences(OK it could be also good but so small that I didn't notice)... I get more since I stop CPU mining with separate worker... I just add a CPU on a GPU worker and it is fine...(I know waist of electricity but I don't pay it per KWh).

So this is just my 2 cents in help for new users...

[Lanidarc]

Slush's pool numbers looking good! Currently second most capable pool 

Also nice to see the stratum use go to 97%

http://i34.tinypic.com/34is1hf.jpg

[Lucko]

Also nice to see the stratum use go to 97%

Good and bad. NMC mining is getwork only... I like to get something exstra...

[Lucko]

Also nice to see the stratum use go to 97%

Good and bad. NMC mining is getwork only... I like to get something exstra...

Are you sure about NMC being getwork only? In only use stratum and NMC seems to work fine for me.

Yes they are getwork only but everyone who has NMC address gets them. Even if you don't contribute anything to solution... You get them based on a BTC rewords...

[Camello_AR]

Also nice to see the stratum use go to 97%

Good and bad. NMC mining is getwork only... I like to get something exstra...

Are you sure about NMC being getwork only?

NMC is mined only vía getwork, but pays to everyone that have an NMC address. In the past days with stratum gone off and miners switched to GetWork, the NMC payouts increased significatly

[TiborB]

Also nice to see the stratum use go to 97%

Good and bad. NMC mining is getwork only... I like to get something exstra...

Are you sure about NMC being getwork only?

NMC is mined only vía getwork, but pays to everyone that have an NMC address. In the past days with stratum gone off and miners switched to GetWork, the NMC payouts increased significatly

Ok, that is clear now. Thanks.

Cheers,
   T

[OlgaA524]

Well there are some things in slush method that I couldn't find described anywhere and I figure them out or someone told me on IRC.

One if a worker goes offline for more then 30 minuts don't turn it on agen till end of a block. If you do restart it it will reset scores for all the workers. I don't get why we have this one. So I just start it with a diffident username from the working worker or put it on a backup PPS pool till the end of a block...

If you have a slow miner(CPU) it can affect your payouts dramaticly(probably because it didn't send any results in for 30 minutes). And never in a good way from my experiences(OK it could be also good but so small that I didn't notice)... I get more since I stop CPU mining with separate worker... I just add a CPU on a GPU worker and it is fine...(I know waist of electricity but I don't pay it per KWh).

So this is just my 2 cents in help for new users...

So what you are saying is - it is better to have 1 fast worker then fast worker and a slow worker? Hmm... maybe that explains how my return varies from block to block for up to 30% even though I do not turn off my workers and their speed doesn't change. Under current algorithm it seem to be better to assign slower workers to some PPS pool   

PS. I like Slush's pool but the return does vary significantly from block to block under seemingly the same conditions from my side.

[Kruncha]

Well there are some things in slush method that I couldn't find described anywhere and I figure them out or someone told me on IRC.

One if a worker goes offline for more then 30 minuts don't turn it on agen till end of a block. If you do restart it it will reset scores for all the workers. I don't get why we have this one. So I just start it with a diffident username from the working worker or put it on a backup PPS pool till the end of a block...

If you have a slow miner(CPU) it can affect your payouts dramaticly(probably because it didn't send any results in for 30 minutes). And never in a good way from my experiences(OK it could be also good but so small that I didn't notice)... I get more since I stop CPU mining with separate worker... I just add a CPU on a GPU worker and it is fine...(I know waist of electricity but I don't pay it per KWh).

So this is just my 2 cents in help for new users...

So what you are saying is - it is better to have 1 fast worker then fast worker and a slow worker? Hmm... maybe that explains how my return varies from block to block for up to 30% even though I do not turn off my workers and their speed doesn't change. Under current algorithm it seem to be better to assign slower workers to some PPS pool   

Or assign your worker to the same account...

K.

[OlgaA524]

So what you are saying is - it is better to have 1 fast worker then fast worker and a slow worker? Hmm... maybe that explains how my return varies from block to block for up to 30% even though I do not turn off my workers and their speed doesn't change. Under current algorithm it seem to be better to assign slower workers to some PPS pool   

Or assign your worker to the same account...

K.

Not sure what you mean. I have 3 workers on the same account.