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

iFA88

full member

Activity: 237

Merit: 100

Quote from: organofcorti on June 02, 2013, 05:45:57 AM

Quote from: iFA88 on June 02, 2013, 05:35:49 AM

Quote from: KNK on June 02, 2013, 05:22:59 AM

Exactly and you should reset the score for all miners at specific time, because the total score is a sum of all the miner's scores

EDIT: I guess you have missed my previous post to you - https://bitcointalksearch.org/topic/m.2330839

I see, but u should understand, when u reseting all scores, then we lost information.
That means when the all score is reset at 1:00:00 then its all newly, what i have shared before i would that lose. Because i would have then 0 score.
The users score should NOT be reseted!

Perhaps you missed this:

Quote from: organofcorti on June 02, 2013, 05:29:37 AM

The "reset" just normalises all the scores. No information is lost. If no "reset" happened, you'd receive the same score and the same reward.

Or maybe you didn't understand?

Then, i think i dont understand.
For me says reset thah reseting scores to zero.

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

Quote from: iFA88 on June 02, 2013, 05:35:49 AM

Quote from: KNK on June 02, 2013, 05:22:59 AM

Exactly and you should reset the score for all miners at specific time, because the total score is a sum of all the miner's scores

EDIT: I guess you have missed my previous post to you - https://bitcointalksearch.org/topic/m.2330839

I see, but u should understand, when u reseting all scores, then we lost information.
That means when the all score is reset at 1:00:00 then its all newly, what i have shared before i would that lose. Because i would have then 0 score.
The users score should NOT be reseted!

Perhaps you missed this:

Quote from: organofcorti on June 02, 2013, 05:29:37 AM

The "reset" just normalises all the scores. No information is lost. If no "reset" happened, you'd receive the same score and the same reward.

Or maybe you didn't understand?

iFA88

full member

Activity: 237

Merit: 100

Quote from: KNK on June 02, 2013, 05:22:59 AM

Exactly and you should reset the score for all miners at specific time, because the total score is a sum of all the miner's scores

EDIT: I guess you have missed my previous post to you - https://bitcointalksearch.org/topic/m.2330839

I see, but u should understand, when u reseting all scores, then we lost information.
That means when the all score is reset at 1:00:00 then its all newly, what i have shared before i would that lose. Because i would have then 0 score.
The users score should NOT be reseted!

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

The "reset" just normalises all the scores. No information is lost. If no "reset" happened, you'd receive the same score and the same reward.

KNK

hero member

Activity: 692

Merit: 502

Exactly and you should reset the score for all miners at specific time, because the total score is a sum of all the miner's scores

EDIT: I guess you have missed my previous post to you - https://bitcointalksearch.org/topic/m.2330839

iFA88

full member

Activity: 237

Merit: 100

Quote from: KNK on June 02, 2013, 05:06:00 AM

I mean just before it is reset, because it based on time and not some value it will always be different, so ... wrong end results
The numbers are just for example

score = score + exp(round_time/C)
The result is only a number ^^
With these method, when the round time too long is, then the value would overflow.

KNK

hero member

Activity: 692

Merit: 502

I mean just before it is reset, because it based on time and not some value it will always be different, so ... wrong end results
The numbers are just for example

iFA88

full member

Activity: 237

Merit: 100

Quote from: KNK on June 02, 2013, 04:59:01 AM

Quote from: iFA88 on June 02, 2013, 04:08:28 AM

So when the duration is on 1:00:00 then we reset the Total Score variable (we dont reset the user score variable!) and we set the "spin" to 1
on 2:00:00 we reseting again, and set the spin to 2
on 3:00:00 to 3 and so follow..
and when the block founded, then we calculate from these method:
reward = ( user score / spin ) / total score * 25
All is done?!

This will lead to wrong results: on spin 1 the total score is 1234567890, but on next spin it is 1934567890 - they are never equal

How are u calculated this? On the spin increment the total score reset it to 0.

KNK

hero member

Activity: 692

Merit: 502

Quote from: iFA88 on June 02, 2013, 04:08:28 AM

So when the duration is on 1:00:00 then we reset the Total Score variable (we dont reset the user score variable!) and we set the "spin" to 1
on 2:00:00 we reseting again, and set the spin to 2
on 3:00:00 to 3 and so follow..
and when the block founded, then we calculate from these method:
reward = ( user score / spin ) / total score * 25
All is done?!

This will lead to wrong results: on spin 1 the total score is 1234567890, but on next spin it is 1934567890 - they are never equal

iFA88

full member

Activity: 237

Merit: 100

Quote from: Trongersoll on June 01, 2013, 02:11:14 PM

Quote from: iFA88 on June 01, 2013, 12:47:19 PM

Quote from: Lucko on June 01, 2013, 12:38:08 PM

Quote from: Trongersoll on June 01, 2013, 12:27:13 PM

I think we agree? cool!

From what I understand what you are saying it that reset doesn't happens for everyone at the same time. I think it dose. And it happens when total score gets to big. The error accrue during reset because some other system is imputing new share that was found.

Why is the total score not in double integer? Or a byte integer what is increase every time when score is reset, then when block found is divided from user score?!

You would have to ask the programmer. Most likely there is not a "type" that is large enough to handle the number we are dealing with. We can't say for sure what is happening, we can only take a WAG(Wild Ass Guess) based on what we are seeing. No one but Slush can answer your question and he is Missing I Action at the moment.

Why not? double integer has 18446744073709600000 max volume. Thats not enough?
But when not enough then the optimal solution would a extra byte.
When the current TOTAL SCORE variable is full, then we have to do only increase a variable (declare name with= "spin") with 1.
So when the duration is on 1:00:00 then we reset the Total Score variable (we dont reset the user score variable!) and we set the "spin" to 1
on 2:00:00 we reseting again, and set the spin to 2
on 3:00:00 to 3 and so follow..
and when the block founded, then we calculate from these method:
reward = ( user score / spin ) / total score * 25
All is done?!

iFA88

full member

Activity: 237

Merit: 100

VeeMiner

hero member

Activity: 752

Merit: 500

bitcoin hodler

I usually get around 0.028 BTC per block - these two blocks are clearly wrong:

18309 2013-06-01 01:48:37 5:15:09 49659498 53882 0.00748170 238964 25.05830000
18318 2013-06-01 11:29:04 1:58:52 18263762 20562 0.01771251 239049 25.09950000

bspurloc

hero member

Activity: 569

Merit: 500

239177 orphaned.

Grr etc. oh well, at least it isn't because some flawed logic in an equation

oroboras

full member

Activity: 238

Merit: 100

Phew, it found a block at 99.*something*%

Kruncha

sr. member

Activity: 644

Merit: 250

Quote from: oroboras on June 01, 2013, 05:52:09 PM

Getting so close to a score reset again... I don't want it to, after last times screw up. Please find a block in the next 5 minutes or so!

You lucky guy Grin

EDIT: and us...

K.

oroboras

full member

Activity: 238

Merit: 100

Getting so close to a score reset again... I don't want it to, after last times screw up. Please find a block in the next 5 minutes or so!

Trongersoll

hero member

Activity: 490

Merit: 501

Quote from: iFA88 on June 01, 2013, 12:47:19 PM

Quote from: Lucko on June 01, 2013, 12:38:08 PM

Quote from: Trongersoll on June 01, 2013, 12:27:13 PM

I think we agree? cool!

From what I understand what you are saying it that reset doesn't happens for everyone at the same time. I think it dose. And it happens when total score gets to big. The error accrue during reset because some other system is imputing new share that was found.

Why is the total score not in double integer? Or a byte integer what is increase every time when score is reset, then when block found is divided from user score?!

You would have to ask the programmer. Most likely there is not a "type" that is large enough to handle the number we are dealing with. We can't say for sure what is happening, we can only take a WAG(Wild Ass Guess) based on what we are seeing. No one but Slush can answer your question and he is Missing I Action at the moment.

Lucko

hero member

Activity: 826

Merit: 1000

Quote from: KNK on June 01, 2013, 01:35:16 PM

Quote from: Lucko on June 01, 2013, 12:25:12 PM

When reset accusers some workers don't get reseted. I guess it has something to do with time the share is submitted and calculated during reset(score=score+share*value)

If this is what is happening, then all that is needed is a mutex_lock/unlock around the score update/reset functions, which is an easy fix. Another option is to trigger second reset if some of the miners has 50+% from total score, which is a workaround, but might be easier to implement depending on the pool structure.
I doubt Slush wouldn't have fixed something simple like this until now, but he is busy with other things lately, so it is possible that he have just missed it.
My personal guess is that it is probably time/clock based and some of the backends is not reset, because it's time is off - that would also explain the situation with the total score not being reset few times too.

I looked at logs(from api on my account) from the time I was figuring out is it me or is it the pool and I was once on wining side of the error. At time of the reset only one of my miners got reseted and other had about the same score. My estimated reword jumped to over 3 BTC, but the round finished and blocked was recalculated... So I'm sure that workers don't get reseted but not sure what is the reason... But I think it is a valid guess...

EDIT: And fixing the bug is easy finding it is not. Sometimes you need another set of eyes.

KNK

hero member

Activity: 692

Merit: 502

Quote from: Lucko on June 01, 2013, 12:25:12 PM

When reset accusers some workers don't get reseted. I guess it has something to do with time the share is submitted and calculated during reset(score=score+share*value)

If this is what is happening, then all that is needed is a mutex_lock/unlock around the score update/reset functions, which is an easy fix. Another option is to trigger second reset if some of the miners has 50+% from total score, which is a workaround, but might be easier to implement depending on the pool structure.
I doubt Slush wouldn't have fixed something simple like this until now, but he is busy with other things lately, so it is possible that he have just missed it.
My personal guess is that it is probably time/clock based and some of the backends is not reset, because it's time is off - that would also explain the situation with the total score not being reset few times too.

Lucko

hero member

Activity: 826

Merit: 1000

Topic: [4+ EH] Slush Pool (slushpool.com); Overt AsicBoost; World First Mining Pool - page 686. (Read 4382755 times)