kabopar
|
 |
December 21, 2013, 10:41:48 AM |
|
Hi, i have a short question:
# Block found at Duration Total shares Your shares Your BTC reward Block # Block value Validity 21229 2013-12-21 00:36:48 9:39:26 4091124633 17590 0.00000000 276127 25.12559563 34 Bestätigungen ausstehend
My miner can't finished the block couse of an hardware problem but is it true that i get no reward or will it be calculated later?
thanks
deagel
It depends when did your hardware stop working, Slush uses an exponentially decaying function, the formula is somewhere in the FAQ or on this thread. In some cases the reward is reported as zero or low, then it is updated to the correct value. This may happen even if your system was hashing the full time. If you stopped hashing a long enough time before the block was found, then your reward will reduce to almost nothing. On the other hand if you hopped to another pool or had a hardware problem, but got back to Slush enough time before the end of the block, then you'll get essentially the full reward as if you were there 100% of the time...
|
|
|
|
deagel
Member

Offline
Activity: 67
Merit: 10
|
 |
December 21, 2013, 10:50:53 AM |
|
Hi, i have a short question:
# Block found at Duration Total shares Your shares Your BTC reward Block # Block value Validity 21229 2013-12-21 00:36:48 9:39:26 4091124633 17590 0.00000000 276127 25.12559563 34 Bestätigungen ausstehend
My miner can't finished the block couse of an hardware problem but is it true that i get no reward or will it be calculated later?
thanks
deagel
It depends when did your hardware stop working, Slush uses an exponentially decaying function, the formula is somewhere in the FAQ or on this thread. In some cases the reward is reported as zero or low, then it is updated to the correct value. This may happen even if your system was hashing the full time. If you stopped hashing a long enough time before the block was found, then your reward will reduce to almost nothing. On the other hand if you hopped to another pool or had a hardware problem, but got back to Slush enough time before the end of the block, then you'll get essentially the full reward as if you were there 100% of the time... Thats meen the best way to loos not your reward is to mine with to workers. That if one is going down the second one safe your reward?
|
|
|
|
timmmers
|
 |
December 21, 2013, 10:53:07 AM |
|
is the slush mining proxy flakey? Got my blades going 10+gh/s now. had 2 pointed at a bfg proxy and 1 pointed at slush's mining proxy. The one pointed at his proxy reported for the last 8 hours 10.9gh/s while slush pool reported the blade was only doing 9.6gh/s. That is too much of a different to be luck etc... I then pointed that blade at a bfg proxy, I did not reboot the blade. I simply stopped the slush miner and made bfg take over at that IP/port. It immediately started to rise above 9.6gh/s on the pool and was at 10.6 on the next block as it delcared it was doing. All the same network, same pc, same everything, so it 100% was the slush mining proxy skimming 1gh/s off.
Same here, been that way for a week or more. Roughly 5 to 10% loss most of the time. Hashing at 140 give or take a couple and 120 to 130 shown on Slush. IF it carries on like this I'm off to find a pool that works.
|
|
|
|
kabopar
|
 |
December 21, 2013, 11:19:01 AM |
|
Hi, i have a short question:
# Block found at Duration Total shares Your shares Your BTC reward Block # Block value Validity 21229 2013-12-21 00:36:48 9:39:26 4091124633 17590 0.00000000 276127 25.12559563 34 Bestätigungen ausstehend
My miner can't finished the block couse of an hardware problem but is it true that i get no reward or will it be calculated later?
thanks
deagel
It depends when did your hardware stop working, Slush uses an exponentially decaying function, the formula is somewhere in the FAQ or on this thread. In some cases the reward is reported as zero or low, then it is updated to the correct value. This may happen even if your system was hashing the full time. If you stopped hashing a long enough time before the block was found, then your reward will reduce to almost nothing. On the other hand if you hopped to another pool or had a hardware problem, but got back to Slush enough time before the end of the block, then you'll get essentially the full reward as if you were there 100% of the time... Thats meen the best way to loos not your reward is to mine with to workers. That if one is going down the second one safe your reward?  the best way is to mine with all possible miners/workers that you have, and have a good power backup, good internet connection, then use a 'backup pool' so if your main pool goes down, you don't waste your mining resources and automatically switch to an alternative pool....  It probably doesn't matter if you group your miners into a single 'worker' or not, unless the separation into separate workers involves some redundancy that improves your overall reliability (such as if 2 workers have each a separate PC, if one PC fails the other one will keep going, but you'll have higher electricity costs...)
|
|
|
|
Mudbankkeith
|
 |
December 21, 2013, 11:36:27 AM |
|
Hi, i have a short question:
# Block found at Duration Total shares Your shares Your BTC reward Block # Block value Validity 21229 2013-12-21 00:36:48 9:39:26 4091124633 17590 0.00000000 276127 25.12559563 34 Bestätigungen ausstehend
My miner can't finished the block couse of an hardware problem but is it true that i get no reward or will it be calculated later?
thanks
deagel
It depends when did your hardware stop working, Slush uses an exponentially decaying function, the formula is somewhere in the FAQ or on this thread. In some cases the reward is reported as zero or low, then it is updated to the correct value. This may happen even if your system was hashing the full time. If you stopped hashing a long enough time before the block was found, then your reward will reduce to almost nothing. On the other hand if you hopped to another pool or had a hardware problem, but got back to Slush enough time before the end of the block, then you'll get essentially the full reward as if you were there 100% of the time... Thats meen the best way to loos not your reward is to mine with to workers. That if one is going down the second one safe your reward?  the best way is to mine with all possible miners/workers that you have, and have a good power backup, good internet connection, then use a 'backup pool' so if your main pool goes down, you don't waste your mining resources and automatically switch to an alternative pool....  It probably doesn't matter if you group your miners into a single 'worker' or not, unless the separation into separate workers involves some redundancy that improves your overall reliability (such as if 2 workers have each a separate PC, if one PC fails the other one will keep going, but you'll have higher electricity costs...) Multiple Pi's is the route to good economic redundancy and easy failover, also for mining across multiple pools. ................(or possibly beagle bones)
|
BTc donations welcome:- 13c2KuzWCaWFTXF171Zn1HrKhMYARPKv97
|
|
|
deagel
Member

Offline
Activity: 67
Merit: 10
|
 |
December 21, 2013, 12:38:29 PM |
|
Hi, i have a short question:
# Block found at Duration Total shares Your shares Your BTC reward Block # Block value Validity 21229 2013-12-21 00:36:48 9:39:26 4091124633 17590 0.00000000 276127 25.12559563 34 Bestätigungen ausstehend
My miner can't finished the block couse of an hardware problem but is it true that i get no reward or will it be calculated later?
thanks
deagel
It depends when did your hardware stop working, Slush uses an exponentially decaying function, the formula is somewhere in the FAQ or on this thread. In some cases the reward is reported as zero or low, then it is updated to the correct value. This may happen even if your system was hashing the full time. If you stopped hashing a long enough time before the block was found, then your reward will reduce to almost nothing. On the other hand if you hopped to another pool or had a hardware problem, but got back to Slush enough time before the end of the block, then you'll get essentially the full reward as if you were there 100% of the time... Thats meen the best way to loos not your reward is to mine with to workers. That if one is going down the second one safe your reward?  the best way is to mine with all possible miners/workers that you have, and have a good power backup, good internet connection, then use a 'backup pool' so if your main pool goes down, you don't waste your mining resources and automatically switch to an alternative pool....  It probably doesn't matter if you group your miners into a single 'worker' or not, unless the separation into separate workers involves some redundancy that improves your overall reliability (such as if 2 workers have each a separate PC, if one PC fails the other one will keep going, but you'll have higher electricity costs...) Multiple Pi's is the route to good economic redundancy and easy failover, also for mining across multiple pools. ................(or possibly beagle bones) thanks for the information. i have two pi's. the plan was to have one active and one for testing. know both are active and i split my asic's on both pi.
|
|
|
|
Mudbankkeith
|
 |
December 21, 2013, 12:52:06 PM |
|
thanks for the information. i have two pi's. the plan was to have one active and one for testing. know both are active and i split my asic's on both pi.
I now have 3Pi's and a spare SD card (cards do fail, especially when they are second hand, 2Gb micro SD off fleabay)
|
BTc donations welcome:- 13c2KuzWCaWFTXF171Zn1HrKhMYARPKv97
|
|
|
gourmet
|
 |
December 21, 2013, 02:38:47 PM |
|
Hi, i have a short question:
# Block found at Duration Total shares Your shares Your BTC reward Block # Block value Validity 21229 2013-12-21 00:36:48 9:39:26 4091124633 17590 0.00000000 276127 25.12559563 34 Bestätigungen ausstehend
My miner can't finished the block couse of an hardware problem but is it true that i get no reward or will it be calculated later?
thanks
deagel
It depends when did your hardware stop working, Slush uses an exponentially decaying function, the formula is somewhere in the FAQ or on this thread. In some cases the reward is reported as zero or low, then it is updated to the correct value. This may happen even if your system was hashing the full time. If you stopped hashing a long enough time before the block was found, then your reward will reduce to almost nothing. On the other hand if you hopped to another pool or had a hardware problem, but got back to Slush enough time before the end of the block, then you'll get essentially the full reward as if you were there 100% of the time... Thats meen the best way to loos not your reward is to mine with to workers. That if one is going down the second one safe your reward? :-) Do you hope your second worker saving your first worker's reward, just by "masking" its absence by its own presence? This is not the case, each worker's hashrate/reward doesn't influence the other worker's reward at all. Shares from each worker are ageing/losing value independently of each other.
|
|
|
|
J_Dubbs
|
 |
December 21, 2013, 07:38:17 PM |
|
Wondering if this is normal...
Anyone else have slightly lower reported hash rate on some workers? Or maybe just ones running through stratum proxy?
For example, one of my blades is isolated as it's own worker, through the blade UI it says 99.7% efficiency and 10.7gh/s, but on my pool account view (ie, Slush Website) the worker is reporting 9.7gh/s.
Maybe worth mentioning, I have 8 other blades all on one worker account, sharing the same proxy, which also might be seeing the same reporting variance. I am going to split them all into separate workers later on to get a batter idea how each blade is performing.
Also, the one right now that is isolated will sometimes say "last share tome: 1 minute" on Slush account view, which makes me think it gets stuck waiting in line behind the worker with 8 blades on the same proxy.
|
|
|
|
BuhTuglia
|
 |
December 21, 2013, 07:42:02 PM |
|
This pool has gone to crap lately. Our luck is abysmal. The gods are angry. Someone must be sacrificed. I'd do it, but I have a dentist appointment Tuesday. Any volunteers?
|
Just another dust miner... Enquiring Gnomes want to Mine! Send nothing to 16SVa2iQA6HuNPDGYShpmeEvUBRi2gW7f1
|
|
|
Codemeister
Full Member
 
Offline
Activity: 131
Merit: 100
Hobby Miner
|
 |
December 21, 2013, 08:24:27 PM |
|
Yeah, last rounds are horrible. Pool luck went down to 52%. I'm in the hospital next week, so I'll sacrifice myself. 
|
|
|
|
mdopro1
|
 |
December 21, 2013, 08:50:45 PM |
|
*W00t* I just finished making a custom aluminum enclosure for my blades that now almost looks like a KNCMiner  I'll do a guide if other people want to know how I did it. Pic attached. https://www.dropbox.com/s/00aipz3j8l9kyap/gen1complete.jpg
|
New Bitcoin fund doubling platform has launched! Receive Automated Payment Every 2 Hours Appealing alternative with Sophisticated algorithms. https://Btc-Funds.com
|
|
|
Trongersoll
|
 |
December 21, 2013, 11:29:16 PM |
|
Wondering if this is normal...
Anyone else have slightly lower reported hash rate on some workers? Or maybe just ones running through stratum proxy?
For example, one of my blades is isolated as it's own worker, through the blade UI it says 99.7% efficiency and 10.7gh/s, but on my pool account view (ie, Slush Website) the worker is reporting 9.7gh/s.
Maybe worth mentioning, I have 8 other blades all on one worker account, sharing the same proxy, which also might be seeing the same reporting variance. I am going to split them all into separate workers later on to get a batter idea how each blade is performing.
Also, the one right now that is isolated will sometimes say "last share tome: 1 minute" on Slush account view, which makes me think it gets stuck waiting in line behind the worker with 8 blades on the same proxy.
What you are seeing is pretty normal. It is because the pool bases hashrate on work returned and can be affected by variance. also, if you start in the middle of a round you'll see off kilter reporting.
|
|
|
|
J_Dubbs
|
 |
December 22, 2013, 12:42:07 AM Last edit: December 22, 2013, 02:11:06 AM by J_Dubbs |
|
Wondering if this is normal...
Anyone else have slightly lower reported hash rate on some workers? Or maybe just ones running through stratum proxy?
For example, one of my blades is isolated as it's own worker, through the blade UI it says 99.7% efficiency and 10.7gh/s, but on my pool account view (ie, Slush Website) the worker is reporting 9.7gh/s.
Maybe worth mentioning, I have 8 other blades all on one worker account, sharing the same proxy, which also might be seeing the same reporting variance. I am going to split them all into separate workers later on to get a batter idea how each blade is performing.
Also, the one right now that is isolated will sometimes say "last share tome: 1 minute" on Slush account view, which makes me think it gets stuck waiting in line behind the worker with 8 blades on the same proxy.
What you are seeing is pretty normal. It is because the pool bases hashrate on work returned and can be affected by variance. also, if you start in the middle of a round you'll see off kilter reporting. I've had all my stuff running for a few days, feel like this is just today it's a bit less. Should I reboot everything? This isn't a case of joining mid-round, but I should read up on scoring variance so I understand it. Thanks. Edit: just realized all the miners reporting low on the pool website have one thing in common; they're the only ones running through proxy. My BFL Jally reports correctly and runs through BfGminer directly to pool, but it is also not competing for bandwidth like the blades are because it's USB.
|
|
|
|
dbell
Newbie
Offline
Activity: 59
Merit: 0
|
 |
December 22, 2013, 03:38:05 AM |
|
I have a some older technology Getwork miners working through a Stratum Proxy hashing on Slush. Running around 50 to 70 GH combined
I had one recent round, 21228, where I had no reward for any shares. What is up? The value formula indicates the reward should have been 0.0013 BTC. "The reward earned by a given user is given by the following formula: (25 BTC + block fees - 2% fee) * (shares found by user's workers) / (total shares in current round)"
Not much loss but it seems like something is wrong or I don't understand the BTC reward algorithm, or I don't undestand reward reporting.
Round Duration Total Shares My Shares BTC Reward Block # Block Value Validation 21230 1:43:31 728080133 102720 0.00390706 276139 25.04945416 98 confirmations left 21229 9:39:26 4091124633 480476 0.00383220 276127 25.12559563 86 confirmations left 21228 4:35:30 1928606238 102602 0.00000000 276067 25.17414052 26 confirmations left 21227 0:46:16 323420163 47502 0.00321315 276036 25.06559435 confirmed 21226 0:14:56 104058374 13282 0.00321300 276031 25.01980000 confirmed 21225 1:07:44 472925199 64496 0.00285957 276029 25.20153852 confirmed 21224 0:04:17 29652709 4292 0.00351801 276018 25.03507003 confirmed 21223 1:52:10 783569002 58652 0.00273363 276016 25.05123438 confirmed
Round 21224 sure was a winner!
It happened again. I can see that I mined all the way through round 21233. Never switched to the backup pool. My shares for round 21233 are proportionally correct for the duration of the block. No apparent dropouts from the Stratum Proxy. Every thing looks correct except BTC reward for Round 21233 is ZERO!. What's up with that? Again, very little lost but it should have given me at least 0.0025 or so BTC for that round. Something wrong with this one. The exponential decay function could not have zero'ed my shares which were 1/10,000 of the total. 1/10,000 of 25 BTC is 0.0025, not zero. Round Duration Total Shares My Shares BTC Reward Block # Block Value Validation 21236 1:04:02 445846104 62580 0.00375781 276297 25.08008069 94 confirmations left 21235 0:31:04 215263719 33420 0.00407103 276290 25.07021854 87 confirmations left 21234 11:36:07 4869485213 455502 0.00342830 276286 25.20665744 83 confirmations left 21233 4:49:31 2040992243 193643 0.00000000 276206 25.04204200 3 confirmations left 21232 1:10:32 499330676 72415 0.00332870 276185 25.07522347 confirmed 21231 4:16:34 1810725132 255048 0.00335437 276177 25.03722000 confirmed
|
|
|
|
J_Dubbs
|
 |
December 22, 2013, 05:13:31 AM |
|
I have a some older technology Getwork miners working through a Stratum Proxy hashing on Slush. Running around 50 to 70 GH combined
I had one recent round, 21228, where I had no reward for any shares. What is up? The value formula indicates the reward should have been 0.0013 BTC. "The reward earned by a given user is given by the following formula: (25 BTC + block fees - 2% fee) * (shares found by user's workers) / (total shares in current round)"
Not much loss but it seems like something is wrong or I don't understand the BTC reward algorithm, or I don't undestand reward reporting.
Round Duration Total Shares My Shares BTC Reward Block # Block Value Validation 21230 1:43:31 728080133 102720 0.00390706 276139 25.04945416 98 confirmations left 21229 9:39:26 4091124633 480476 0.00383220 276127 25.12559563 86 confirmations left 21228 4:35:30 1928606238 102602 0.00000000 276067 25.17414052 26 confirmations left 21227 0:46:16 323420163 47502 0.00321315 276036 25.06559435 confirmed 21226 0:14:56 104058374 13282 0.00321300 276031 25.01980000 confirmed 21225 1:07:44 472925199 64496 0.00285957 276029 25.20153852 confirmed 21224 0:04:17 29652709 4292 0.00351801 276018 25.03507003 confirmed 21223 1:52:10 783569002 58652 0.00273363 276016 25.05123438 confirmed
Round 21224 sure was a winner!
It happened again. I can see that I mined all the way through round 21233. Never switched to the backup pool. My shares for round 21233 are proportionally correct for the duration of the block. No apparent dropouts from the Stratum Proxy. Every thing looks correct except BTC reward for Round 21233 is ZERO!. What's up with that? Again, very little lost but it should have given me at least 0.0025 or so BTC for that round. Something wrong with this one. The exponential decay function could not have zero'ed my shares which were 1/10,000 of the total. 1/10,000 of 25 BTC is 0.0025, not zero. Round Duration Total Shares My Shares BTC Reward Block # Block Value Validation 21236 1:04:02 445846104 62580 0.00375781 276297 25.08008069 94 confirmations left 21235 0:31:04 215263719 33420 0.00407103 276290 25.07021854 87 confirmations left 21234 11:36:07 4869485213 455502 0.00342830 276286 25.20665744 83 confirmations left 21233 4:49:31 2040992243 193643 0.00000000 276206 25.04204200 3 confirmations left 21232 1:10:32 499330676 72415 0.00332870 276185 25.07522347 confirmed 21231 4:16:34 1810725132 255048 0.00335437 276177 25.03722000 confirmed What kind of hardware? Blades? Wondering if there's a problem with the Stratum proxy... I'm not getting 0 rewards but I am seeing my miners get skimmed on their reported hash. When you look on your account page are the hashes reported accurate to what your miners show locally??
|
|
|
|
dbell
Newbie
Offline
Activity: 59
Merit: 0
|
 |
December 22, 2013, 06:40:19 AM |
|
I have a some older technology Getwork miners working through a Stratum Proxy hashing on Slush. Running around 50 to 70 GH combined
I had one recent round, 21228, where I had no reward for any shares. What is up? The value formula indicates the reward should have been 0.0013 BTC. "The reward earned by a given user is given by the following formula: (25 BTC + block fees - 2% fee) * (shares found by user's workers) / (total shares in current round)"
Not much loss but it seems like something is wrong or I don't understand the BTC reward algorithm, or I don't undestand reward reporting.
Round Duration Total Shares My Shares BTC Reward Block # Block Value Validation 21230 1:43:31 728080133 102720 0.00390706 276139 25.04945416 98 confirmations left 21229 9:39:26 4091124633 480476 0.00383220 276127 25.12559563 86 confirmations left 21228 4:35:30 1928606238 102602 0.00000000 276067 25.17414052 26 confirmations left 21227 0:46:16 323420163 47502 0.00321315 276036 25.06559435 confirmed 21226 0:14:56 104058374 13282 0.00321300 276031 25.01980000 confirmed 21225 1:07:44 472925199 64496 0.00285957 276029 25.20153852 confirmed 21224 0:04:17 29652709 4292 0.00351801 276018 25.03507003 confirmed 21223 1:52:10 783569002 58652 0.00273363 276016 25.05123438 confirmed
Round 21224 sure was a winner!
It happened again. I can see that I mined all the way through round 21233. Never switched to the backup pool. My shares for round 21233 are proportionally correct for the duration of the block. No apparent dropouts from the Stratum Proxy. Every thing looks correct except BTC reward for Round 21233 is ZERO!. What's up with that? Again, very little lost but it should have given me at least 0.0025 or so BTC for that round. Something wrong with this one. The exponential decay function could not have zero'ed my shares which were 1/10,000 of the total. 1/10,000 of 25 BTC is 0.0025, not zero. Round Duration Total Shares My Shares BTC Reward Block # Block Value Validation 21236 1:04:02 445846104 62580 0.00375781 276297 25.08008069 94 confirmations left 21235 0:31:04 215263719 33420 0.00407103 276290 25.07021854 87 confirmations left 21234 11:36:07 4869485213 455502 0.00342830 276286 25.20665744 83 confirmations left 21233 4:49:31 2040992243 193643 0.00000000 276206 25.04204200 3 confirmations left 21232 1:10:32 499330676 72415 0.00332870 276185 25.07522347 confirmed 21231 4:16:34 1810725132 255048 0.00335437 276177 25.03722000 confirmed What kind of hardware? Blades? Wondering if there's a problem with the Stratum proxy... I'm not getting 0 rewards but I am seeing my miners get skimmed on their reported hash. When you look on your account page are the hashes reported accurate to what your miners show locally?? Running 2 AsicMinerCubes: For example, available in groupbuy here: https://bitcointalk.org/index.php?topic=375247.0. Each cube running as a separate worker. Running Slush Stratum Proxy on local PC which looks to be running fine. Hash rate reported on Slush pool stats for the two cubes agrees with hash rate reported locally on the cubes and the hash rates indicate the units are running at top speed, no lagging. I am getting top rated performance from each of the cubes. If there was a problem with the Stratum Proxy on round 21233 then it corrected pretty quickly since I got the correct ratio of My Shares vs. Total Shares, i.e. similar ratio compared to the other two long duration rounds that did reward BTC. Round 21231: Roughly 1:10,000 My Shares to Total Shares, Paid out Round 21233: Roughly 1:10,000 My Shares to Total Shares, No Reward Round 21234: Roughly 1:10,000 My Shares to Total Shares, Paid out
|
|
|
|
gourmet
|
 |
December 22, 2013, 08:09:07 AM Last edit: December 22, 2013, 08:22:36 AM by gourmet |
|
It happened again. I can see that I mined all the way through round 21233. Never switched to the backup pool. My shares for round 21233 are proportionally correct for the duration of the block. No apparent dropouts from the Stratum Proxy. Every thing looks correct except BTC reward for Round 21233 is ZERO!. What's up with that? Again, very little lost but it should have given me at least 0.0025 or so BTC for that round. Something wrong with this one. The exponential decay function could not have zero'ed my shares which were 1/10,000 of the total. 1/10,000 of 25 BTC is 0.0025, not zero.
Round Duration Total Shares My Shares BTC Reward Block # Block Value Validation 21236 1:04:02 445846104 62580 0.00375781 276297 25.08008069 94 confirmations left 21235 0:31:04 215263719 33420 0.00407103 276290 25.07021854 87 confirmations left 21234 11:36:07 4869485213 455502 0.00342830 276286 25.20665744 83 confirmations left 21233 4:49:31 2040992243 193643 0.00000000 276206 25.04204200 3 confirmations left 21232 1:10:32 499330676 72415 0.00332870 276185 25.07522347 confirmed 21231 4:16:34 1810725132 255048 0.00335437 276177 25.03722000 confirmed
Running 2 AsicMinerCubes: For example, available in groupbuy here: https://bitcointalk.org/index.php?topic=375247.0. Each cube running as a separate worker. Running Slush Stratum Proxy on local PC which looks to be running fine. Hash rate reported on Slush pool stats for the two cubes agrees with hash rate reported locally on the cubes and the hash rates indicate the units are running at top speed, no lagging. I am getting top rated performance from each of the cubes. If there was a problem with the Stratum Proxy on round 21233 then it corrected pretty quickly since I got the correct ratio of My Shares vs. Total Shares, i.e. similar ratio compared to the other two long duration rounds that did reward BTC. Round 21231: Roughly 1:10,000 My Shares to Total Shares, Paid out Round 21233: Roughly 1:10,000 My Shares to Total Shares, No Reward Round 21234: Roughly 1:10,000 My Shares to Total Shares, Paid out This is simply not true. More exact ratios your/total look like this: 21231 0.000140854 21232 0.000145024 21233 0.000094876 21234 0.000093542 21235 0.000155251 21236 0.000140362 You can see a dropout at the end of 33 and begining of 34. That is the reason. [edit] Mining must have been out for about 1.5 hours at the end of 21233 and ~4 hours at the beginning of the following round.
|
|
|
|
dbell
Newbie
Offline
Activity: 59
Merit: 0
|
 |
December 22, 2013, 08:56:45 AM |
|
It happened again. I can see that I mined all the way through round 21233. Never switched to the backup pool. My shares for round 21233 are proportionally correct for the duration of the block. No apparent dropouts from the Stratum Proxy. Every thing looks correct except BTC reward for Round 21233 is ZERO!. What's up with that? Again, very little lost but it should have given me at least 0.0025 or so BTC for that round. Something wrong with this one. The exponential decay function could not have zero'ed my shares which were 1/10,000 of the total. 1/10,000 of 25 BTC is 0.0025, not zero.
Round Duration Total Shares My Shares BTC Reward Block # Block Value Validation 21236 1:04:02 445846104 62580 0.00375781 276297 25.08008069 94 confirmations left 21235 0:31:04 215263719 33420 0.00407103 276290 25.07021854 87 confirmations left 21234 11:36:07 4869485213 455502 0.00342830 276286 25.20665744 83 confirmations left 21233 4:49:31 2040992243 193643 0.00000000 276206 25.04204200 3 confirmations left 21232 1:10:32 499330676 72415 0.00332870 276185 25.07522347 confirmed 21231 4:16:34 1810725132 255048 0.00335437 276177 25.03722000 confirmed
Running 2 AsicMinerCubes: For example, available in groupbuy here: https://bitcointalk.org/index.php?topic=375247.0. Each cube running as a separate worker. Running Slush Stratum Proxy on local PC which looks to be running fine. Hash rate reported on Slush pool stats for the two cubes agrees with hash rate reported locally on the cubes and the hash rates indicate the units are running at top speed, no lagging. I am getting top rated performance from each of the cubes. If there was a problem with the Stratum Proxy on round 21233 then it corrected pretty quickly since I got the correct ratio of My Shares vs. Total Shares, i.e. similar ratio compared to the other two long duration rounds that did reward BTC. Round 21231: Roughly 1:10,000 My Shares to Total Shares, Paid out Round 21233: Roughly 1:10,000 My Shares to Total Shares, No Reward Round 21234: Roughly 1:10,000 My Shares to Total Shares, Paid out This is simply not true. More exact ratios your/total look like this: 21231 0.000140854 21232 0.000145024 21233 0.000094876 21234 0.000093542 21235 0.000155251 21236 0.000140362 You can see a dropout at the end of 33 and begining of 34. That is the reason. [edit] Mining must have been out for about 1.5 hours at the end of 21233 and ~4 hours at the beginning of the following round. Case solved. I believe you are correct sir! Must be something still wrong with my Stratum Proxy. The exponential decay function was a killer making the first 2/3 of that round worthless to me because I missed the last 1/3. On the next round, missing the first 1/3 did not seem to cost me anything in payout. Makes me think I could have missed the first 2/3 of that round and still received roughly the same payout. The exponential decay function is a hard master, punishing those who miss the end of a round and rewarding of those who work the end of a round.
|
|
|
|
KNK
|
 |
December 22, 2013, 06:55:38 PM Last edit: December 22, 2013, 07:05:44 PM by KNK |
|
My shares for round 21233 are proportionally correct for the duration of the block. ... 21233 4:49:31 2040992243 193643 0.00000000 276206 25.04204200 3 confirmations left ... 21231 4:16:34 1810725132 255048 0.00335437 276177 25.03722000 confirmed
Realy? EDIT: Sorry sow it was stated in a later post. -------------------------- The exponential decay function was a killer making the first 2/3 of that round worthless to me because I missed the last 1/3. On the next round, missing the first 1/3 did not seem to cost me anything in payout. Makes me think I could have missed the first 2/3 of that round and still received roughly the same payout.
The exponential decay function is a hard master, punishing those who miss the end of a round and rewarding of those who work the end of a round.
Yes, that's why it was implemented - (IF) you are a pool hopper you loose almost immediately. It's not 1/3 or 2/3 of the round - it's a matter of ~20-30 min, so for a 11h round you may miss 10:30 of it and get the full reward (joining at the end) or miss the last 6% of it and loose all the reward you had
|
|
|
|
|