I started writing a google spreadsheet to have a few stats form the pools. The biggest problem currently is that the pools don't show which shares were mined with which difficulty --> you usually get a "total_shares" or something like that, most of the time also a total payout or similar but you can't calculate efficiency over several rounds (as you don't know how many shares were mined with which difficulty).
For this you would need a "canonical" metapool, that does not really give out work or accept it but just takes an arbitrary number of shares for each round and outputs the expected 0% PPS payout after the block was confirmed (to make sure also transaction fees are accounted for - important in the long run). This data should then be queriable aggregated via APIs like in most other pools. From this you could then determine if your pool cheats you or not (ideally for non-hoppers it should show about the same payouts on the metapool and the real pool, if it's a 0% fee pool).
Also some pools don't have a (useful) API at all, you'd need to login and scrape their website...
All in all, I fear that only client side stats from bithopper will be useful (but might not reflect the reality 100%, as in the end only what reaches your wallet counts!). The ones from pools might be interesting for basic statistics, but you can't even see how lucky/unlucky you were each round (something that I'm interested in). They could be used to verify the local stats though and/or to correct them.
Edit:
It seems to me that bitHopper hops to early! According to https://forum.bitcoin.org/index.php?topic=3165.0 line 169 should read min_shares = difficulty*.435, not min_shares = difficulty*.40! We still loose some "hot" share this way in the worst case.
Topic: bitHopper: Python Pool Hopper Proxy - page 198. (Read 355689 times)
Yes, the new Version runs great for about 6 Hours and 9 Workers connected.
No Errors, fast pool switching and nearly 0 stales.
No Errors, fast pool switching and nearly 0 stales.
Just a little feedback:
The latest version seems pretty stable. It didn't crash for me in the last 4 hours.
The latest version seems pretty stable. It didn't crash for me in the last 4 hours.
just downloaded the last version and have a small request: please do not hide the pool share count from time to time, please. It helps allot if everything keeps transparent and for debugging purposes too. Thanks
mt.red stats failed me couple a minutes ago
restarted and everything goes fine
Code:
Time: UTC+2
[12:09:06] mining.mainframe.nl :3622349
[12:09:06] Server change to eligius, telling client with LP
[12:09:06] mineco :66088
[12:09:06] bitcoin.lc :480294
[12:09:06] Server change to bclc, telling client with LP
[12:09:06] mtred :754610
[12:09:06] pool.bitp.nl :1569718
[12:09:06] btcguild :57456
[12:09:06] Server change to btcg, telling client with LP
[12:09:06] bitclockers :611500
[12:09:07] eclipsemc :2549766
[12:09:16] RPC request [] submitted to BTC Guild
[12:09:17] LP Call us.btcguild.com:8332/LP
[12:09:37] RPC request [] submitted to BTC Guild
[12:09:57] RPC request [] submitted to BTC Guild
[12:09:59] RPC request [u'000000014610341ceb92ab33cbe0e555229c8e5999d99021bbc1f0c90000015000000000ad6cbce0f8afebe71d19f71464eb622a01d17c41cd014c16256f5b84bd869a4c4e1d6e8b1a0abbcf6b779c16000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'] submitted to BTC Guild
[12:10:08] RPC request [u'000000014610341ceb92ab33cbe0e555229c8e5999d99021bbc1f0c90000015000000000ad6cbce0f8afebe71d19f71464eb622a01d17c41cd014c16256f5b84bd869a4c4e1d6e8b1a0abbcf3dedf17f000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'] submitted to BTC Guild
[12:10:18] RPC request [] submitted to BTC Guild
[12:10:38] RPC request [] submitted to BTC Guild
[12:10:59] RPC request [] submitted to BTC Guild
[12:11:02] mining.mainframe.nl :3622490
[12:11:03] mineco :75772
[12:11:03] bitcoin.lc :567786
[12:11:03] bitclockers :616410
[12:11:03] mtred :0
[12:11:03] pool.bitp.nl :1571346
[12:11:03] btcguild :116551
[12:11:04] eclipsemc :2551778
[12:11:10] RPC request [u'000000014610341ceb92ab33cbe0e555229c8e5999d99021bbc1f0c90000015000000000e68dc07f3973e7d42b69c79942a63eb7de1b5e4577b53412795421af314056204e1d6ec91a0abbcff6130688000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'] submitted to BTC Guild
[12:11:14] RPC request [u'000000014610341ceb92ab33cbe0e555229c8e5999d99021bbc1f0c90000015000000000e68dc07f3973e7d42b69c79942a63eb7de1b5e4577b53412795421af314056204e1d6ec91a0abbcf9e724bbb000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'] submitted to BTC Guild
[12:11:19] RPC request [] submitted to BTC Guild
[12:11:40] RPC request [] submitted to BTC Guild
[12:12:00] RPC request [] submitted to BTC Guild
[12:12:15] RPC request [u'000000014610341ceb92ab33cbe0e555229c8e5999d99021bbc1f0c900000150000000003ff9095133cdd7ce5a5db8c9836cd9cc1dd2e9abde9a4a1c32e66c9890a3aab24e1d6f061a0abbcf8251a8b4000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'] submitted to BTC Guild
[12:12:21] RPC request [] submitted to BTC Guild
[12:12:33] RPC request [u'000000014610341ceb92ab33cbe0e555229c8e5999d99021bbc1f0c90000015000000000a166b70401e554527ff71b723a75f693e3a8798c6a38f140968f5478b4b4159c4e1d6f1b1a0abbcf36bbc88e000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'] submitted to BTC Guild
[12:12:37] RPC request [u'000000014610341ceb92ab33cbe0e555229c8e5999d99021bbc1f0c90000015000000000a166b70401e554527ff71b723a75f693e3a8798c6a38f140968f5478b4b4159c4e1d6f1b1a0abbcf8faca9c0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'] submitted to BTC Guild
[12:12:39] RPC request [u'000000014610341ceb92ab33cbe0e555229c8e5999d99021bbc1f0c90000015000000000a166b70401e554527ff71b723a75f693e3a8798c6a38f140968f5478b4b4159c4e1d6f1b1a0abbcfc0a47fe2000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'] submitted to BTC Guild
[12:12:41] RPC request [] submitted to BTC Guild
[12:13:00] mining.mainframe.nl :3622490
[12:13:00] mineco :75772
[12:13:00] bitcoin.lc :567786
[12:13:00] bitclockers :621155
[12:13:00] mtred :0
[12:13:00] pool.bitp.nl :1572960
[12:13:00] btcguild :176268
[12:13:00] Server change to mtred, telling client with LP
[12:13:01] eclipsemc :2553709
[12:13:02] RPC request [] submitted to mtred
[12:13:02] LP Call mtred.com:8337/LP
[12:13:17] RPC request [u'000000014610341ceb92ab33cbe0e555229c8e5999d99021bbc1f0c900000150000000008e9838f1e4fd79ceecf50420e84a588ecb9213a20131f2820eb1afc84ee9be7c4e1d6f441a0abbcf0d19aeb8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'] submitted to mtred
[12:13:22] RPC request [] submitted to mtred
[12:13:43] RPC request [] submitted to mtred
[12:13:49] RPC request [u'000000014610341ceb92ab33cbe0e555229c8e5999d99021bbc1f0c90000015000000000a64dfa76d8141ce09c2fc668f42a267db3f249c8a46a21fa81d2c8f26250c70a4e1d6f6d1a0abbcf52c9eb4b000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'] submitted to mtred
[12:13:52] RPC request [u'000000014610341ceb92ab33cbe0e555229c8e5999d99021bbc1f0c90000015000000000a64dfa76d8141ce09c2fc668f42a267db3f249c8a46a21fa81d2c8f26250c70a4e1d6f6d1a0abbcf3a83066a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'] submitted to mtred
[12:14:03] RPC request [] submitted to mtred
[12:14:17] LP triggered from server mtred
[12:14:17] LP triggering clients manually
[12:14:17] mining.mainframe.nl :3622587
[12:14:18] mineco :75772
[12:14:18] bitcoin.lc :567786
[12:14:18] mtred :0
[12:14:18] pool.bitp.nl :1573711
[12:14:18] bitclockers :623600
[12:14:18] btcguild :235357
[12:14:19] LP triggered from server mtred
[12:14:19] LP triggering clients manually
[12:14:19] mining.mainframe.nl :3622587
[12:14:19] mineco :75772
[12:14:20] mtred :0
[12:14:20] pool.bitp.nl :1573711
[12:14:20] bitclockers :623600
[12:14:20] btcguild :235357
[12:14:22] bitcoin.lc :567786
[12:14:24] RPC request [] submitted to mtred
[12:14:24] LP Call mtred.com:8337/LP
[12:14:24] RPC request [] submitted to mtred
[12:14:25] RPC request [] submitted to mtred
[12:14:25] eclipsemc :2555007
[12:14:25] RPC request [] submitted to mtred
[12:14:25] RPC request [] submitted to mtred
[12:14:26] RPC request [] submitted to mtred
[12:14:28] eclipsemc :2555044
[12:14:45] RPC request [] submitted to mtred
[12:14:50] RPC request [u'0000000117fd24eaa050282730a84371a5eb57bdaeb390cfe5a0b11000000a340000000014572add3e2f6d6397f9de08cbd0f3e36738d1551c7a47f73181288f9ce459594e1d6ffa1a0abbcfa0041633000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'] submitted to mtred
[12:14:57] mining.mainframe.nl :3622587
[12:14:57] mineco :75772
[12:14:57] bitcoin.lc :567786
[12:14:57] mtred :0
[12:14:57] pool.bitp.nl :1574462
[12:14:57] bitclockers :625442
[12:14:58] btcguild :235357
[12:14:58] eclipsemc :2555547
[12:15:06] RPC request [] submitted to mtred
[12:15:27] RPC request [] submitted to mtred
[12:15:29] RPC request [u'0000000117fd24eaa050282730a84371a5eb57bdaeb390cfe5a0b11000000a34000000008d36a7ea7eab4dd2d6f93e7c3044846ec2d95def6ae21d2c11f07bdc79343c8f4e1d6ffb1a0abbcf3e79a311000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'] submitted to mtred
[12:15:39] RPC request [u'0000000117fd24eaa050282730a84371a5eb57bdaeb390cfe5a0b11000000a34000000008d36a7ea7eab4dd2d6f93e7c3044846ec2d95def6ae21d2c11f07bdc79343c8f4e1d6ffb1a0abbcf693abb94000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'] submitted to mtred
[12:15:44] RPC request [u'0000000117fd24eaa050282730a84371a5eb57bdaeb390cfe5a0b11000000a34000000008d36a7ea7eab4dd2d6f93e7c3044846ec2d95def6ae21d2c11f07bdc79343c8f4e1d6ffb1a0abbcf66ea9ece000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000'] submitted to mtred
restarted and everything goes fine
nice update thx.
But wish i had more options to pass like: --port --hideRPCrequests --showServerShares..
And it would be great for statistic if you could count each valid share for each server and save it in a stats.blub file or something like that.
From time to time i get:
In that time my workers feel bored and didn't work.
But wish i had more options to pass like: --port --hideRPCrequests --showServerShares..
And it would be great for statistic if you could count each valid share for each server and save it in a stats.blub file or something like that.
From time to time i get:
Code:
2011-07-13 09:20:14+0200 [-] Caught, jsonrpc_call insides
2011-07-13 09:20:14+0200 [-] User timeout caused connection failure.
2011-07-13 09:20:18+0200 [-] Caught, jsonrpc_call insides
2011-07-13 09:20:18+0200 [-] User timeout caused connection failure.
...
2011-07-13 09:23:07+0200 [-] User timeout caused connection failure.
2011-07-13 09:23:15+0200 [-] Caught, jsonrpc_call insides
2011-07-13 09:23:15+0200 [-] User timeout caused connection failure.
In that time my workers feel bored and didn't work.
Same here.
I'm on mtred now, and everythings fine.
But on bitclockers before, there where a lot of these errors. And about 20% stales.
Maybe some kind of DDOS-protection from Bitclockers?
phoenix wrote this in the console:
Code:
2011-07-13 09:22:38: Traceback (most recent call last):
2011-07-13 09:22:38: File "phoenix.py", line 125, in
2011-07-13 09:22:38: File "twisted\internet\base.pyo", line 1166, in run
2011-07-13 09:22:38: File "twisted\internet\base.pyo", line 1175, in mainLoop
2011-07-13 09:22:38: ------
2011-07-13 09:22:38: File "twisted\internet\base.pyo", line 779, in runUntilCurrent
2011-07-13 09:22:38: File "minerutil\RPCProtocol.pyo", line 130, in callback
2011-07-13 09:22:38: File "minerutil\RPCProtocol.pyo", line 352, in handleWork
2011-07-13 09:22:38: exceptions.TypeError: string indices must be integers
DiabloMiner was idle after the rp_call connection lost erros:
Code:
java.lang.NullPointerException
Only m0mchilds poclbm seems to run smooth.
//EDIT:
Oops you uploaded a new Version, i'll test it
//EDIT2:
Thanks, works great now.
nice update thx.
But wish i had more options to pass like: --port --hideRPCrequests --showServerShares..
And it would be great for statistic if you could count each valid share for each server and save it in a stats.blub file or something like that.
From time to time i get:
In that time my workers feel bored and didn't work.
But wish i had more options to pass like: --port --hideRPCrequests --showServerShares..
And it would be great for statistic if you could count each valid share for each server and save it in a stats.blub file or something like that.
From time to time i get:
Code:
2011-07-13 09:20:14+0200 [-] Caught, jsonrpc_call insides
2011-07-13 09:20:14+0200 [-] User timeout caused connection failure.
2011-07-13 09:20:18+0200 [-] Caught, jsonrpc_call insides
2011-07-13 09:20:18+0200 [-] User timeout caused connection failure.
...
2011-07-13 09:23:07+0200 [-] User timeout caused connection failure.
2011-07-13 09:23:15+0200 [-] Caught, jsonrpc_call insides
2011-07-13 09:23:15+0200 [-] User timeout caused connection failure.
In that time my workers feel bored and didn't work.
As far as fail over goes, try using the new poclbm. It haa built in failover to whatever your back up pool its at whatever -f you have for your main pool. Even if poclbm isn't as fast for you as whatever you're using, it might be worthwhile until bitHopper is working properly for you.
Don't really feel like changing all of my miners and re-building all my scripts around a new executable. Might be minor for those of you who have two or three nodes but I'm playing with 14
Edit: For the record, since I'm pretty sure I haven't stated before, I'm running puddinpop's opencl miner under winxp
As far as fail over goes, try using the new poclbm. It haa built in failover to whatever your back up pool its at whatever -f you have for your main pool. Even if poclbm isn't as fast for you as whatever you're using, it might be worthwhile until bitHopper is working properly for you.
Yet another wall of errors and half my hashrate is going to my backup pool (running at -f60 priority in case the proxy fails) 
Code:
Request.finish called on a request after its connection was lost; use Request.no
tifyFinish to keep track of this.
[00:09:22] RPC request [] submitted to bitclockers.com
caught, Final response/writing
Request.finish called on a request after its connection was lost; use Request.no
tifyFinish to keep track of this.
Caught, jsonrpc_call insides
TCP connection timed out: 10060: A connection attempt failed because the connect
ed party did not properly respond after a period of time, or established connect
ion failed because connected host has failed to respond..
First things first, Thanks for BitHopper!
Second: Thought about ArsBitcoin as second Backup Pool? Like Eligius thery are using SMPPS. I mined on Ars when Eligius had problems, and had 0 Downtimes.
Second: Thought about ArsBitcoin as second Backup Pool? Like Eligius thery are using SMPPS. I mined on Ars when Eligius had problems, and had 0 Downtimes.
2) Crashes on that line?
Removed it. Not needed. I'm unsure why it was sucking so much work though... I did up the timer for the stalls to half a second a piece. It looks like your miner is timing out too quickly. I got these sorts of stalls with poclbm. Phoenix stalls less although it will try and double submit shares.
EDIT: Actually I think it is a server side LP issue. Which I think I just fixed. I accidentally had error'd LP calls call the lp handler
Removed it. Not needed. I'm unsure why it was sucking so much work though... I did up the timer for the stalls to half a second a piece. It looks like your miner is timing out too quickly. I got these sorts of stalls with poclbm. Phoenix stalls less although it will try and double submit shares.
EDIT: Actually I think it is a server side LP issue. Which I think I just fixed. I accidentally had error'd LP calls call the lp handler
Updated, it appears to be running and I haven't seen another error yet. I'm keeping my eyes open and fingers crossed though
Thanks! (damn you work fast)
Code:
print "You just disabled the backup pool. I hope you know what you are doing"
*That* made me grin. The snarkier the better!
1)Minecoin?
They are already out of the rotation.
They are already out of the rotation.
Sorry, I misread Mineco as minecoin in the password file! My apologies.
1)Minecoin?
They are already out of the rotation.
2) Crashes on that line?
Removed it. Not needed. I'm unsure why it was sucking so much work though... I did up the timer for the stalls to half a second a piece. It looks like your miner is timing out too quickly. I got these sorts of stalls with poclbm. Phoenix stalls less although it will try and double submit shares.
EDIT: Actually I think it is a server side LP issue. Which I think I just fixed. I accidentally had error'd LP calls call the lp handler
3) Invalid username/password taking out a pool?
Yeah it already does this assuming the pool won't accept the work. Sometimes it does. its a little dicey. I'm going to try and add an option for going --skip Name1, Name2, etc... as well as a --list to help tell people which servers are installed.
EDIT: Enabled and in the repository. Note the format for disable should have no spaces.
Oh and I used --disable not --skip
They are already out of the rotation.
2) Crashes on that line?
Removed it. Not needed. I'm unsure why it was sucking so much work though... I did up the timer for the stalls to half a second a piece. It looks like your miner is timing out too quickly. I got these sorts of stalls with poclbm. Phoenix stalls less although it will try and double submit shares.
EDIT: Actually I think it is a server side LP issue. Which I think I just fixed. I accidentally had error'd LP calls call the lp handler
3) Invalid username/password taking out a pool?
Yeah it already does this assuming the pool won't accept the work. Sometimes it does. its a little dicey. I'm going to try and add an option for going --skip Name1, Name2, etc... as well as a --list to help tell people which servers are installed.
EDIT: Enabled and in the repository. Note the format for disable should have no spaces.
Oh and I used --disable not --skip
Just FYI, Mineco.in has implemented a Pay Per Last N Shares reward scheme. I'm guessing their change in payment scheme would require some adjustment of the pool hopper.
Getting the following a lot:
Doesn't seem to crash or anything, it recovers quickly, just thought I'd notify you
Edit: Scratch that, it is now happening so often that I'm getting more errors than actual traffic and an unreasonable amount of hashing power is falling to my backup pool, I've switched back to a previous build that still seems to work just fine, but whatever this is, it's BAD.
Code:
Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
File "D:\Python27\lib\site-packages\twisted\internet\defer.py", line 361, in c
allback
self._startRunCallbacks(result)
File "D:\Python27\lib\site-packages\twisted\internet\defer.py", line 455, in _
startRunCallbacks
self._runCallbacks()
File "D:\Python27\lib\site-packages\twisted\internet\defer.py", line 542, in _
runCallbacks
current.result = callback(current.result, *args, **kw)
File "D:\Python27\lib\site-packages\twisted\internet\defer.py", line 1076, in
gotResult
_inlineCallbacks(r, g, deferred)
------
File "D:\Python27\lib\site-packages\twisted\internet\defer.py", line 1020, in
_inlineCallbacks
result = g.send(result)
File "D:\bitHopper\work.py", line 140, in jsonrpc_getwork
request.finish()
File "D:\Python27\lib\site-packages\twisted\web\http.py", line 866, in finish
"Request.finish called on a request after its connection was lost; "
exceptions.RuntimeError: Request.finish called on a request after its connection
was lost; use Request.notifyFinish to keep track of this.
Doesn't seem to crash or anything, it recovers quickly, just thought I'd notify you
Edit: Scratch that, it is now happening so often that I'm getting more errors than actual traffic and an unreasonable amount of hashing power is falling to my backup pool, I've switched back to a previous build that still seems to work just fine, but whatever this is, it's BAD.
@ c00w: Does entering an invalid or empty username/password combo cause problems?
The reason I ask is that atm if a user doesn't like a pool or the pool starts withholding rewards, giving too many stales, or starts using an antihopping algo users have to go into going to pool.py in starts commenting out lines It might be easier for users to simply delete the username and password to turn a pool 'off'.
An advantage for you (c00w) is that you wouldn't have to worry about finding out which pools are good or not, adding them or deleting them. You could just add the top (say) 15 pools, don't worry about whether they use antihopping or not and let everyone take their pick. The only extra work for you would be figuring out the pool's api.
Then, if the stats show a pool is crapping out, the user can just delete the relevant username and password. Or maybe comment them out.
tl;dr
1. c00w adds top 15 pools and their api.
2. Users enter the username/passwords/api (if necessary) only of pools they actually want to use.
3. Username/passwords/api can be added or deleted later on.
I think this would reduce duplication of effort for both you and users.
What do you think?
The reason I ask is that atm if a user doesn't like a pool or the pool starts withholding rewards, giving too many stales, or starts using an antihopping algo users have to go into going to pool.py in starts commenting out lines It might be easier for users to simply delete the username and password to turn a pool 'off'.
An advantage for you (c00w) is that you wouldn't have to worry about finding out which pools are good or not, adding them or deleting them. You could just add the top (say) 15 pools, don't worry about whether they use antihopping or not and let everyone take their pick. The only extra work for you would be figuring out the pool's api.
Then, if the stats show a pool is crapping out, the user can just delete the relevant username and password. Or maybe comment them out.
tl;dr
1. c00w adds top 15 pools and their api.
2. Users enter the username/passwords/api (if necessary) only of pools they actually want to use.
3. Username/passwords/api can be added or deleted later on.
I think this would reduce duplication of effort for both you and users.
What do you think?
And I reordered the code again to try and stop tripping eligius's DDOS settings. To whoever sent me some bitcoins: Thank you very much.
I hope I'll do some stats soon but I'm spending too much time tracking down bugs. Its on the list. I swear.
I hope I'll do some stats soon but I'm spending too much time tracking down bugs. Its on the list. I swear.
keep up the good work man, bitcoins coming your way (when I get them)
(when I get them) Jump to: