vpasic
|
|
October 23, 2013, 09:13:15 AM Last edit: October 23, 2013, 12:18:55 PM by vpasic |
|
need some help... I'm using 2 x 60GH singles with BFGminer, all working fine but couple of hrs ago I start getting a lot of "accepted" in BFGminer (7-10//sec) and my rewards become much smaller (0.008-0.009). usually it was like 1 or 2 "accepted" every 2-3 seconds and 0.012-0.014 rewards. what the hell?? anyway I can set pool diff manually?
|
Tips: 1Ejj8eANy2PLZVwrWUczkbQ8kQY2JhKqp6
|
|
|
gourmet
|
|
October 23, 2013, 11:25:39 AM Last edit: October 23, 2013, 11:48:54 AM by gourmet |
|
need some help... I'm using 2 x 60GH singles with BFGminer, all working fine but couple of hrs ago I start getting a lot of "accepted" in BFGminer (7-10//sec) and my rewards become much smaller (0.08-0.09). usually it was like 1 or 2 "accepted" every 2-3 seconds and 0.012-0.014 rewards. what the hell?? anyway I can set pool diff manually?
0.08-0.09 is not smaller than your usually 0.012-0.014.
|
|
|
|
juhakall
|
|
October 23, 2013, 11:39:15 AM |
|
need some help... I'm using 2 x 60GH singles with BFGminer, all working fine but couple of hrs ago I start getting a lot of "accepted" in BFGminer (7-10//sec) and my rewards become much smaller (0.08-0.09). usually it was like 1 or 2 "accepted" every 2-3 seconds and 0.012-0.014 rewards. what the hell?? anyway I can set pool diff manually?
0.08-0.09 is not smaller than 0.012-0.014. That must be because slush removed the manual difficulty setting that was previously working just fine. It's now replaced with vardiff. When your connection resets the miner starts flooding low difficulty shares. All pools should really support a minimum difficulty setting, not doing so is just asking for problems like this.
|
|
|
|
gourmet
|
|
October 23, 2013, 11:41:20 AM |
|
Could someone with a bit of knowledge of this pool explain to me a little about the API? Im trying to monitor the generated BTC once an hour, and unlike most pools i'd use theres no total paid out value in there, and im struggling to understand which specific stats i want to be using to get an accurate measurement of income.
Currently im using 'confirmed rewards', and im running a check on the last db entry to see if that figure has decreased then it must have meant a payment has been sent, in which case i increase the db's total payout to += 'send_threshold'.
I thought that would be correct, however about 2hr ago my db stats went from:
16:00 UTC Confirmed: 0.31413209 Total Payout: 0.00000000 Hourly update: 0.00000000 (no block solved)
17:00 UTC Confirmed: 0.04204677 Total Payout: 0.25000000 Hourly update: -0.02208532
18:00 UTC Confirmed: 0.13160902 Total Payout: 0.25000000 Hourly update: 0.08956225
Now, this has happened because rather than simply paying out based on the threshold, its paid more (0.31), however there doesnt appear to be anything in the API which tells me there has been any payment, and it means my attempt to code something in to respond to the fact that there isnt a total paid out statistic, is completely useless because if it sends 0.31btc i only know this by manually looking, and i have to go fumbling through the database to fix this. Has anyone found a solution which allows for the funds to be properly monitored, i genuinely thought with the 'send_threshold' it'd work, but its not much use really, its just another snippet of information rather than being a valuable means of circumventing the lack of 'total_payout' on the account & API.
Threshold means nothing different but threshold. You couldn't suppose the payout amount will be equal to that number. When the threshold level is crossed, all confirmed reward is paid out. You have probably lowered the threshold value manually at the beginning of your experiment, when there was 0.31 btc confirmed reward already, so that amount has been all paid out. No wonder. Everything is OK.
|
|
|
|
Mudbankkeith
|
|
October 23, 2013, 11:57:42 AM |
|
need some help... I'm using 2 x 60GH singles with BFGminer, all working fine but couple of hrs ago I start getting a lot of "accepted" in BFGminer (7-10//sec) and my rewards become much smaller (0.08-0.09). usually it was like 1 or 2 "accepted" every 2-3 seconds and 0.012-0.014 rewards. what the hell?? anyway I can set pool diff manually?
0.08-0.09 is not smaller than 0.012-0.014. That must be because slush removed the manual difficulty setting that was previously working just fine. It's now replaced with vardiff. When your connection resets the miner starts flooding low difficulty shares. All pools should really support a minimum difficulty setting, not doing so is just asking for problems like this. A challenge for Slush:- To complement the "Vardiff" we need a user "Mindiff"
|
BTc donations welcome:- 13c2KuzWCaWFTXF171Zn1HrKhMYARPKv97
|
|
|
vpasic
|
|
October 23, 2013, 12:20:18 PM |
|
need some help... I'm using 2 x 60GH singles with BFGminer, all working fine but couple of hrs ago I start getting a lot of "accepted" in BFGminer (7-10//sec) and my rewards become much smaller (0.08-0.09). usually it was like 1 or 2 "accepted" every 2-3 seconds and 0.012-0.014 rewards. what the hell?? anyway I can set pool diff manually?
0.08-0.09 is not smaller than your usually 0.012-0.014. My bad I meant 0.008-0.009
|
Tips: 1Ejj8eANy2PLZVwrWUczkbQ8kQY2JhKqp6
|
|
|
gourmet
|
|
October 23, 2013, 01:04:26 PM |
|
need some help... I'm using 2 x 60GH singles with BFGminer, all working fine but couple of hrs ago I start getting a lot of "accepted" in BFGminer (7-10//sec) and my rewards become much smaller (0.08-0.09). usually it was like 1 or 2 "accepted" every 2-3 seconds and 0.012-0.014 rewards. what the hell?? anyway I can set pool diff manually?
0.08-0.09 is not smaller than 0.012-0.014. That must be because slush removed the manual difficulty setting that was previously working just fine. It's now replaced with vardiff. When your connection resets the miner starts flooding low difficulty shares. All pools should really support a minimum difficulty setting, not doing so is just asking for problems like this. A challenge for Slush:- To complement the "Vardiff" we need a user "Mindiff" User adjustable lowest difficulty would be fine. Currently, there's a setting of the VarDiff that sets the difficulty to 3 at the beginning. Then, the difficulty is set to a different value after some time interval, according to the number of shares obtained by the server during that time. I.e. e.g. when no diff 3 shares arrive, the difficulty is set to 1. :-)
|
|
|
|
Threader
|
|
October 23, 2013, 02:04:27 PM |
|
3 invalid blocks in less than 24 hours 20538 2013-10-23 03:28:34 0:23:53 83222522 58748 0.01833783 265441 25.23686743 invalid 20534 2013-10-23 00:35:43 0:05:32 18859435 14630 0.01932590 265419 25.21232224 invalid 20521 2013-10-22 15:39:53 2:03:54 428492037 304742 0.01837904 265340 25.10731468 invali Not liking it. Switched half my miners to another pool to balance. If this continues I may have to leave completely until this is resolved.
|
|
|
|
threedrules
Member
Offline
Activity: 102
Merit: 10
|
|
October 23, 2013, 02:20:14 PM |
|
uhm invalid blocks happen because they are orphaned or someone else was first, not much can be done to resolve this
|
|
|
|
eleuthria
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
October 23, 2013, 02:42:57 PM |
|
uhm invalid blocks happen because they are orphaned or someone else was first, not much can be done to resolve this Better connected/faster servers reduce it a lot. 3 orphans in 24 hours is seems extremely high given the size of the pool. Orphan rates should be <1%. Obviously a given sample may have much more than 1% just due to lack of # of rounds being evaluated. Maybe organofcorti can shed some light on the probabilities. EDIT: 2 of the 3 orphans were never even seen by Blockchain.info...that points to serious server issues. These blocks were either never broadcast, or were broadcast well after the prior block (meaning no connected peers accepted it and rebroadcasted). The timestamp on 265441 was more than 1 minute after the competing block was seen by Blockchain.info. The timestamp on 265419 was almost 4 minutes after. This may not be the real delay due to ntime rolling/slush's poold configuration/where the table get it's timestamp from. But those are both blocks that were not even seen by the rest of the network apparently.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
VeeMiner
|
|
October 23, 2013, 02:50:39 PM |
|
uhm invalid blocks happen because they are orphaned or someone else was first, not much can be done to resolve this Better connected/faster servers reduce it a lot. 3 orphans in 24 hours is seems extremely high given the size of the pool. Orphan rates should be <1%. Obviously a given sample may have much more than 1% just due to lack of # of rounds being evaluated. Maybe organofcorti can shed some light on the probabilities. EDIT: 2 of the 3 orphans were never even seen by Blockchain.info...that points to serious server issues. These blocks were either never broadcast, or were broadcast well after the prior block (meaning no connected peers accepted it and rebroadcasted). The timestamp on 265441 was more than 1 minute after the competing block was seen by Blockchain.info. The timestamp on 265419 was almost 4 minutes after. This may not be the real delay due to ntime rolling/slush's poold configuration/where the table get it's timestamp from. But those are both blocks that were not even seen by the rest of the network apparently. Darn
|
|
|
|
zvs
Legendary
Offline
Activity: 1680
Merit: 1000
https://web.archive.org/web/*/nogleg.com
|
|
October 23, 2013, 09:27:21 PM |
|
uhm invalid blocks happen because they are orphaned or someone else was first, not much can be done to resolve this Better connected/faster servers reduce it a lot. 3 orphans in 24 hours is seems extremely high given the size of the pool. Orphan rates should be <1%. Obviously a given sample may have much more than 1% just due to lack of # of rounds being evaluated. Maybe organofcorti can shed some light on the probabilities. EDIT: 2 of the 3 orphans were never even seen by Blockchain.info...that points to serious server issues. These blocks were either never broadcast, or were broadcast well after the prior block (meaning no connected peers accepted it and rebroadcasted). The timestamp on 265441 was more than 1 minute after the competing block was seen by Blockchain.info. The timestamp on 265419 was almost 4 minutes after. This may not be the real delay due to ntime rolling/slush's poold configuration/where the table get it's timestamp from. But those are both blocks that were not even seen by the rest of the network apparently. Yeah, none of them show up on my log. No clue what happened with those... from what I've seen over the last 18 months or so, Slush very rarely gets orphans. I did notice this: 2013-10-23 19:22:43 received block 00000000000000051a828b0196663b7b82f33d9ec386e9da0a7d12c36f7c051b 2013-10-23 19:22:43 SetBestChain: new best=00000000000000051a828b0196663b7b82f33d9ec386e9da0a7d12c36f7c051b height=265588 log2_work=73.094444 tx=25887076 date=2013-10-23 19:22:38 progress=0.999999 2013-10-23 19:22:55 received block 00000000000000051a828b0196663b7b82f33d9ec386e9da0a7d12c36f7c051b 2013-10-23 19:22:55 ERROR: ProcessBlock() : already have block 265588 00000000000000051a828b0196663b7b82f33d9ec386e9da0a7d12c36f7c051b 2013-10-23 19:24:29 received block 00000000000000051a828b0196663b7b82f33d9ec386e9da0a7d12c36f7c051b 2013-10-23 19:24:29 ERROR: ProcessBlock() : already have block 265588 00000000000000051a828b0196663b7b82f33d9ec386e9da0a7d12c36f7c051b this earlier block is more like it usually is: 2013-10-22 15:59:49 received block 000000000000000a53c17f3837f4a9b058eff44a8e0691074253214db196496b 2013-10-22 15:59:49 SetBestChain: new best=000000000000000a53c17f3837f4a9b058eff44a8e0691074253214db196496b height=265348 log2_work=73.054409 tx=25822202 date=2013-10-22 15:59:43 progress=1.000000 2013-10-22 15:59:50 received block 000000000000000a53c17f3837f4a9b058eff44a8e0691074253214db196496b 2013-10-22 15:59:50 ERROR: ProcessBlock() : already have block 265348 000000000000000a53c17f3837f4a9b058eff44a8e0691074253214db196496b
|
|
|
|
Trongersoll
|
|
October 23, 2013, 09:51:17 PM |
|
Anybody has problem enabling payout address protection by two-factor authentication? I've tried more than once but still I get invalid token?
sorry if already answered but I've just skimmed through the last 5 pages and I didn't find anything.
I couldn't get it to work, I don't have a smart phone.
|
|
|
|
kkurtmann
|
|
October 23, 2013, 11:07:08 PM |
|
I would rather use a YubiKey than Google Authenticator, not that I don't trust Google but...
|
|
|
|
CMMPro
|
|
October 23, 2013, 11:55:52 PM |
|
What happened to 20553? I got nothing...my miner was running full tilt 280gh but it says I have no submitted shares for an hour?
Edit: Fixed itself....I should know better.
|
|
|
|
sickpig
Legendary
Offline
Activity: 1260
Merit: 1008
|
|
October 24, 2013, 06:54:22 AM |
|
I would rather use a YubiKey than Google Authenticator, not that I don't trust Google but...
don't use google auth, there are plenty of other solutions that implement two-factort auth
|
Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
|
|
|
sickpig
Legendary
Offline
Activity: 1260
Merit: 1008
|
|
October 24, 2013, 06:54:43 AM |
|
Anybody has problem enabling payout address protection by two-factor authentication? I've tried more than once but still I get invalid token?
sorry if already answered but I've just skimmed through the last 5 pages and I didn't find anything.
I couldn't get it to work, I don't have a smart phone. ROTFL
|
Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
|
|
|
sickpig
Legendary
Offline
Activity: 1260
Merit: 1008
|
|
October 24, 2013, 08:42:57 PM |
|
|
Bitcoin is a participatory system which ought to respect the right of self determinism of all of its users - Gregory Maxwell.
|
|
|
CMMPro
|
|
October 24, 2013, 08:49:32 PM |
|
I saw that too just now....what's with the invalid blocks lately?
|
|
|
|
eleuthria
Legendary
Offline
Activity: 1750
Merit: 1007
|
|
October 24, 2013, 09:07:15 PM |
|
I saw that too just now....what's with the invalid blocks lately?
That invalid was a classic block race orphan, something that's very hard to get rid of. BTC Guild probably found the block first (blockchain.info saw it 2 seconds before it saw slush's block). Due to the geographic distance (Chicago -> EU), this is a type of orphan you can't do much about.
|
RIP BTC Guild, April 2011 - June 2015
|
|
|
|