Bitcoin Forum
October 07, 2024, 10:53:01 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 [327] 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 ... 1154 »
  Print  
Author Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool  (Read 4382503 times)
Kruncha
Sr. Member
****
Offline Offline

Activity: 644
Merit: 250



View Profile
April 22, 2013, 03:12:35 PM
 #6521

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
Donator
Legendary
*
Offline Offline

Activity: 2058
Merit: 1007


Poor impulse control.


View Profile WWW
April 22, 2013, 03:18:18 PM
 #6522

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.

Bitcoin network and pool analysis 12QxPHEuxDrs7mCyGSx1iVSozTwtquDB3r
follow @oocBlog for new post notifications
TiborB
Member
**
Offline Offline

Activity: 83
Merit: 10


View Profile
April 22, 2013, 03:24:23 PM
 #6523


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
Sr. Member
****
Offline Offline

Activity: 644
Merit: 250



View Profile
April 22, 2013, 03:25:21 PM
 #6524

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
Member
**
Offline Offline

Activity: 76
Merit: 10


View Profile
April 22, 2013, 03:25:53 PM
 #6525

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
Hero Member
*****
Offline Offline

Activity: 490
Merit: 500


View Profile
April 22, 2013, 03:30:09 PM
 #6526

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.

If I help you out: 17QatvSdciyv2zsdAbphDEUzST1S6x46c3
References (bitcointalk.org/index.php?topic=): 50051.20  50051.100  53668.0  53788.0  53571.0  53571.0  52212.0  50729.0  114804.0  115468  78106  69061  58572  54747
digital
Hero Member
*****
Offline Offline

Activity: 490
Merit: 500


View Profile
April 22, 2013, 03:31:13 PM
 #6527

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.

If I help you out: 17QatvSdciyv2zsdAbphDEUzST1S6x46c3
References (bitcointalk.org/index.php?topic=): 50051.20  50051.100  53668.0  53788.0  53571.0  53571.0  52212.0  50729.0  114804.0  115468  78106  69061  58572  54747
Kruncha
Sr. Member
****
Offline Offline

Activity: 644
Merit: 250



View Profile
April 22, 2013, 03:32:09 PM
 #6528

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
aka Amenstop
Legendary
*
Offline Offline

Activity: 1624
Merit: 1001


All cryptos are FIAT digital currency. Do not use.


View Profile WWW
April 22, 2013, 03:37:08 PM
 #6529

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
Member
**
Offline Offline

Activity: 83
Merit: 10


View Profile
April 22, 2013, 03:44:37 PM
Last edit: April 22, 2013, 04:01:12 PM by TiborB
 #6530

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
Hero Member
*****
Offline Offline

Activity: 826
Merit: 1000



View Profile
April 22, 2013, 04:44:50 PM
 #6531

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
Newbie
*
Offline Offline

Activity: 48
Merit: 0



View Profile
April 22, 2013, 04:49:35 PM
 #6532

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

Also nice to see the stratum use go to 97%

http://i34.tinypic.com/34is1hf.jpg
Lucko
Hero Member
*****
Offline Offline

Activity: 826
Merit: 1000



View Profile
April 22, 2013, 04:57:06 PM
 #6533

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
Hero Member
*****
Offline Offline

Activity: 826
Merit: 1000



View Profile
April 22, 2013, 05:04:02 PM
 #6534

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
Newbie
*
Offline Offline

Activity: 43
Merit: 0



View Profile
April 22, 2013, 05:06:38 PM
 #6535

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
Member
**
Offline Offline

Activity: 83
Merit: 10


View Profile
April 22, 2013, 05:11:36 PM
 #6536

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
Newbie
*
Offline Offline

Activity: 54
Merit: 0



View Profile
April 22, 2013, 05:24:00 PM
 #6537

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   Huh

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
Sr. Member
****
Offline Offline

Activity: 644
Merit: 250



View Profile
April 22, 2013, 05:26:45 PM
 #6538

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   Huh

Or assign your worker to the same account...

K.
OlgaA524
Newbie
*
Offline Offline

Activity: 54
Merit: 0



View Profile
April 22, 2013, 05:43:14 PM
 #6539


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   Huh

Or assign your worker to the same account...

K.

Not sure what you mean. I have 3 workers on the same account.
Lucko
Hero Member
*****
Offline Offline

Activity: 826
Merit: 1000



View Profile
April 22, 2013, 05:46:11 PM
 #6540


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   Huh

Or assign your worker to the same account...

K.

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

Worker accaunt...
Pages: « 1 ... 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 [327] 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 ... 1154 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!