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

[desired_username]

Are these going to be fixed?

18321 is still incorrect, 18317 and 18 are way off too.

[SebaS-DG]

18323    2013-06-01 15:28:47    0:19:51    3080262    97    0.00076830    239084    25.19121000    100 confirmaciones pendientes
18322    2013-06-01 15:08:56    1:50:42    17158976    588    0.00062108    239080    25.18504000    96 confirmaciones pendientes
18321    2013-06-01 13:18:14    1:35:10    14691906    509    0.00000118    239063    25.20347868    79 confirmaciones pendientes
18320    2013-06-01 11:43:04    0:09:52    1544066    45    0.00067210    239053    25.00150000    69 confirmaciones pendientes

[oroboras]

18322    2013-06-01 15:08:56    1:50:42    17158976    1462    0.00219536    239080    25.18504000    97 confirmations left
18321    2013-06-01 13:18:14    1:35:10    14691906    766    0.03116995    239063    25.20347868    80 confirmations left

Well, that kinda makes up for all the loss I've had recently..... (the top one is about correct)

For once I was on the good side of the errors.

ok, maybe not.

It 'corrected'

18322    2013-06-01 15:08:56    1:50:42    17158976    1462    0.00219536    239080    25.18504000    92 confirmations left
18321    2013-06-01 13:18:14    1:35:10    14691906    none     none            239063    25.20347868    75 confirmations left

[matauc12]

21 now shows none. Seems to be getting corrected.

18 is also a little bogus for me, though a little less.

[weevil]

Well 18321 is showing NONE for me instead of 0.07-0.08.
Something is definitely WRONG Mr S
Please investigate

[matauc12]

21 is fixed for me.

[jerboa]

21 is fixed for me.

For me as well. ##309 is still screwed up

[PrintMule]

21 is fixed for me.

For me as well. ##309 is still screwed up

309 is already confirmed, to late to fix anything

[Lanidarc]

21 is fixed for me.

For me as well. ##309 is still screwed up

309 is already confirmed, to late to fix anything

Hardly, slush has several times fixed bad blocks after-the-fact by adding revenues to other blocks in the confirmation chain.

[PrintMule]

I would love to believe that

I don't

[Trongersoll]

Here is my guess as to what is happening. This is strictly a guess on my part. I'm sure i'll be corrected. Your mileage may vary.

What i think is happening is that the score reset to avoid wrap around is being done on an individual basis. when your score exceeds a certain number it is reset, but everyone elses isn't until they hit that number. This could account for the disparity in payouts. Or, resets for everyone take a long time relative to our input to the pool rate and some of our input is getting lost.

It also seems that things get worse when the pool's hashrate goes up. I'm wondering if perhaps someone has figured out how to play the system for their benefit. 

Fire away.

[Lucko]

21 is fixed for me.

For me as well. ##309 is still screwed up

309 is already confirmed, to late to fix anything

Hardly, slush has several times fixed bad blocks after-the-fact by adding revenues to other blocks in the confirmation chain.

This is not Slush fixing it. This is automatic. If error is big enough system finds it and fix it. I'm not sure but I think that if an error is less then 20-25% will not be fixed...

[iFA88]

Still problems with these blocks (what red color has)
18324    2013-06-01 16:44:55    1:16:08    11826947    525    0.00088458    239094    25.13869000    90 confirmations left
18323    2013-06-01 15:28:47    0:19:51    3080262    135    0.00124384    239084    25.19121000    89 confirmations left
18322    2013-06-01 15:08:56    1:50:42    17158976    41    0.00101832    239080    25.18504000    85 confirmations left
18321    2013-06-01 13:18:14    1:35:10    14691384    none    none    239063    25.20347868    68 confirmations left
18320    2013-06-01 11:43:04    0:09:52    1544066    none    none    239053    25.00150000    58 confirmations left
18319    2013-06-01 11:33:12    0:04:08    627852    none    none    239051    25.11800000    56 confirmations left
18318    2013-06-01 11:29:04    1:58:52    18263762    none    none    239049    25.09950000    54 confirmations left
18317    2013-06-01 09:30:12    0:01:59    310597    none    none    239033    25.04160000    38 confirmations left
18316    2013-06-01 09:28:13    0:34:49    5394754    none    none    239032    25.06220000    37 confirmations left
18315    2013-06-01 08:53:24    0:21:58    3473112    none    none    239027    25.33340000    32 confirmations left
18314    2013-06-01 08:31:26    1:17:10    11856454    118    0.00000000    239025    25.17790000    30 confirmations left
18313    2013-06-01 07:14:16    0:13:14    2031444    38    0.00055482    239015    25.10000000    20 confirmations left
18312    2013-06-01 07:01:02    2:09:08    19734291    221    0.00056050    239012    25.46190000    17 confirmations left
18311    2013-06-01 04:51:54    2:10:19    20307448    176    0.00015807    238993    25.26838085    confirmed
18310    2013-06-01 02:41:35    0:52:58    7941437    68    0.00008204    238975    25.10570000    confirmed
18309    2013-06-01 01:48:37    5:15:09    49659498    325    0.00005240    238964    25.05830000    confirmed
18308    2013-05-31 20:33:28    1:42:52    16633401    292    0.00000081    238930    25.00000000    confirmed
18307    2013-05-31 18:50:36    0:18:57    3010041    77    0.00063556    238919    25.26863000    confirmed
18306    2013-05-31 18:31:39    2:17:49    21231848    501    0.00078153    238916    25.31229000    confirmed
18305    2013-05-31 16:13:50    0:45:01    7410765    178    0.00087783    238901    25.26605000    confirmed
18304    2013-05-31 15:28:49    3:24:52    34544624    756    0.00051999    238894    25.04760000    confirmed
18303    2013-05-31 12:03:57    0:28:10    4669471    105    0.00061763    238858    25.16995099    confirmed
18302    2013-05-31 11:35:47    3:12:56    31259218    688    0.00045144    238855    25.28059996    confirmed
18301    2013-05-31 08:22:51    4:54:34    46714536    456    0.00057801    238831    25.38963413    confirmed
18300    2013-05-31 03:28:17    0:56:08    8883215    67    0.00008960    238800    25.64249344    confirmed
18299    2013-05-31 02:32:09    0:55:51    8791245    69    0.00020915    238796    25.29477058    confirmed
18298    2013-05-31 01:36:18    0:23:53    3809057    24    0.00007815    238791    25.45422788    confirmed
18297    2013-05-31 01:12:25    0:48:41    7718499    50    0.00023318    238788    25.08535000    confirmed
18296    2013-05-31 00:23:44    0:07:53    1254360    14    0.00030901    238783    25.00370000    confirmed
18295    2013-05-31 00:15:51    4:40:25    44440241    522    0.00018694    238780    25.00640000    confirmed

[Lucko]

Here is my guess as to what is happening. This is strictly a guess on my part. I'm sure i'll be corrected. Your mileage may vary.

What i think is happening is that the score reset to avoid wrap around is being done on an individual basis. when your score exceeds a certain number it is reset, but everyone elses isn't until they hit that number. This could account for the disparity in payouts. Or, resets for everyone take a long time relative to our input to the pool rate and some of our input is getting lost.

It also seems that things get worse when the pool's hashrate goes up. I'm wondering if perhaps someone has figured out how to play the system for their benefit. 

Fire away.

I don't know how to play it for my benefit but this is what I think is happening... 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)... I think that either second score stays the same or value is not reseted yet or both. And since worker has hi score you get more on that round. Depends how long from reset round ends...

[Trongersoll]

Here is my guess as to what is happening. This is strictly a guess on my part. I'm sure i'll be corrected. Your mileage may vary.

What i think is happening is that the score reset to avoid wrap around is being done on an individual basis. when your score exceeds a certain number it is reset, but everyone elses isn't until they hit that number. This could account for the disparity in payouts. Or, resets for everyone take a long time relative to our input to the pool rate and some of our input is getting lost.

It also seems that things get worse when the pool's hashrate goes up. I'm wondering if perhaps someone has figured out how to play the system for their benefit. 

Fire away.

I don't know how to play it for my benefit but this is what I think is happening... 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)... I think that either second score stays the same or value is not reseted yet or both. And since worker has hi score you get more on that round. Depends how long from reset round ends...

I think we agree? cool!

[Lucko]

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.

[iFA88]

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?!

[weevil]

18321 is now corrected to predicted value.
Thank you Mr S 

[Lucko]

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?!

Sorry I can't figure out what you are asking?

EDIT:

Still problems with these blocks (what red color has)
18324    2013-06-01 16:44:55    1:16:08    11826947    525    0.00088458    239094    25.13869000    90 confirmations left
18323    2013-06-01 15:28:47    0:19:51    3080262    135    0.00124384    239084    25.19121000    89 confirmations left
18322    2013-06-01 15:08:56    1:50:42    17158976    41    0.00101832    239080    25.18504000    85 confirmations left
18321    2013-06-01 13:18:14    1:35:10    14691384    none    none    239063    25.20347868    68 confirmations left
18320    2013-06-01 11:43:04    0:09:52    1544066    none    none    239053    25.00150000    58 confirmations left
18319    2013-06-01 11:33:12    0:04:08    627852    none    none    239051    25.11800000    56 confirmations left
18318    2013-06-01 11:29:04    1:58:52    18263762    none    none    239049    25.09950000    54 confirmations left
18317    2013-06-01 09:30:12    0:01:59    310597    none    none    239033    25.04160000    38 confirmations left
18316    2013-06-01 09:28:13    0:34:49    5394754    none    none    239032    25.06220000    37 confirmations left
18315    2013-06-01 08:53:24    0:21:58    3473112    none    none    239027    25.33340000    32 confirmations left
18314    2013-06-01 08:31:26    1:17:10    11856454    118    0.00000000    239025    25.17790000    30 confirmations left
18313    2013-06-01 07:14:16    0:13:14    2031444    38    0.00055482    239015    25.10000000    20 confirmations left
18312    2013-06-01 07:01:02    2:09:08    19734291    221    0.00056050    239012    25.46190000    17 confirmations left
18311    2013-06-01 04:51:54    2:10:19    20307448    176    0.00015807    238993    25.26838085    confirmed
18310    2013-06-01 02:41:35    0:52:58    7941437    68    0.00008204    238975    25.10570000    confirmed
18309    2013-06-01 01:48:37    5:15:09    49659498    325    0.00005240    238964    25.05830000    confirmed
18308    2013-05-31 20:33:28    1:42:52    16633401    292    0.00000081    238930    25.00000000    confirmed
18307    2013-05-31 18:50:36    0:18:57    3010041    77    0.00063556    238919    25.26863000    confirmed
18306    2013-05-31 18:31:39    2:17:49    21231848    501    0.00078153    238916    25.31229000    confirmed
18305    2013-05-31 16:13:50    0:45:01    7410765    178    0.00087783    238901    25.26605000    confirmed
18304    2013-05-31 15:28:49    3:24:52    34544624    756    0.00051999    238894    25.04760000    confirmed
18303    2013-05-31 12:03:57    0:28:10    4669471    105    0.00061763    238858    25.16995099    confirmed
18302    2013-05-31 11:35:47    3:12:56    31259218    688    0.00045144    238855    25.28059996    confirmed
18301    2013-05-31 08:22:51    4:54:34    46714536    456    0.00057801    238831    25.38963413    confirmed
18300    2013-05-31 03:28:17    0:56:08    8883215    67    0.00008960    238800    25.64249344    confirmed
18299    2013-05-31 02:32:09    0:55:51    8791245    69    0.00020915    238796    25.29477058    confirmed
18298    2013-05-31 01:36:18    0:23:53    3809057    24    0.00007815    238791    25.45422788    confirmed
18297    2013-05-31 01:12:25    0:48:41    7718499    50    0.00023318    238788    25.08535000    confirmed
18296    2013-05-31 00:23:44    0:07:53    1254360    14    0.00030901    238783    25.00370000    confirmed
18295    2013-05-31 00:15:51    4:40:25    44440241    522    0.00018694    238780    25.00640000    confirmed

Did you increase you hash rate? If so to can you give me a number on what it was and what it is.

[KNK]

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.