|
KNK
|
 |
June 01, 2013, 06:35:16 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. |
|
|
|
|
|
|
|
|
|
|
|
|
"This isn't the kind of software where we can leave so many unresolved bugs that we need a tracker for them." -- Satoshi
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
|
|
|
|
Lucko
|
|
June 01, 2013, 07:10:47 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. |
|
|
|
|
|
Trongersoll
|
|
June 01, 2013, 07:11:14 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. |
|
|
|
|
|
oroboras
|
|
June 01, 2013, 10: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!
|
|
|
|
|
|
Kruncha
|
|
June 01, 2013, 11:58:31 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  EDIT: and us... K. |
|
|
|
|
|
oroboras
|
|
June 02, 2013, 12:01:22 AM |
|
Phew, it found a block at 99.*something*%
|
|
|
|
|
|
bspurloc
|
|
June 02, 2013, 03:29:45 AM |
|
239177 orphaned.
Grr etc. oh well, at least it isn't because some flawed logic in an equation
|
|
|
|
|
|
VeeMiner
|
|
June 02, 2013, 08:58:49 AM |
|
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
|
|
|
|
|
|
iFA88
|
|
June 02, 2013, 09:01:22 AM
Last edit: June 02, 2013, 09:42:51 AM by 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?! 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. We have there 2 PC's, every PC has one GPU. #1 with 300 mhps #2 with 200 mhps. All PC's are 10-20% in use (movie watch, any game playing) in a 24h day, but they dont run the whole day. I work for 2 pools, one pps and the Slush pool for testing. I use cgminer with balance pool method. My avarage hash rate on slush pool is ~240 mhps from 2013-05-30 14:27. I work for the slush pool without any cheating, i dont have the block red colored (on the list) who i have changed the systems. I have only colored what i was on the whole block online, and the hash rate was fix, but i was punished with lower reward what did not deserve it. I dont have "mining rig" what only run miner the whole 24h day. I have personal computers what when they online then work for the pools. /sorry for bad grammar, i speak whole better in German and Hungarian language/ **EDIT** The my account page says: Average hashrate in last 10 rounds: 351 Mhash/s **EDIT** |
|
|
|
|
iFA88
|
|
June 02, 2013, 09:08:28 AM |
|
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?! |
|
|
|
|
KNK
|
|
June 02, 2013, 09:59:01 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 1 934567890 - they are never equal |
|
|
|
|
iFA88
|
|
June 02, 2013, 10:03:14 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 1 934567890 - they are never equal How are u calculated this? On the spin increment the total score reset it to 0. |
|
|
|
|
KNK
|
|
June 02, 2013, 10: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
|
|
|
|
|
iFA88
|
|
June 02, 2013, 10:10:21 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. |
|
|
|
|
|
organofcorti
Donator
Legendary
 Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
June 02, 2013, 10: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.
|
|
|
|
|
iFA88
|
|
June 02, 2013, 10:35:49 AM |
|
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
Legendary
Offline
Activity: 2058
Merit: 1007
Poor impulse control.
|
|
June 02, 2013, 10:45:57 AM |
|
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: 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
|
|
June 02, 2013, 10:59:58 AM |
|
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: 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. |
|
|
|
CJPOLO
Newbie
Offline
Activity: 34
Merit: 0
|
|
June 02, 2013, 11:13:43 AM |
|
Slush any news on blocks
18309 and 18318 in regards to miscalculations?
thanks
|
|
|
|
|
|
