I notice it actually on btcguild aswell with LP still, strange that no one else using bithopper is reporting this, unless they to lazy
Topic: bitHopper: Python Pool Hopper Proxy - page 193. (Read 355816 times)
Just a follow up, seems the stales is still the same, it evened out at 10% stales (was ~15% before your last fix) and doesnt seem to be a ozco.in issue.
I notice it actually on btcguild aswell with LP still, strange that no one else using bithopper is reporting this, unless they to lazy
I notice it actually on btcguild aswell with LP still, strange that no one else using bithopper is reporting this, unless they to lazy
Edit2:
MtRed just found a block - and just take a look at that sudden 100 GH/s hash rate increase! https://mtred.com/site/page/view/about.html
MtRed just found a block - and just take a look at that sudden 100 GH/s hash rate increase! https://mtred.com/site/page/view/about.html
Fastest Bitcoin I made in a while
considering poolsize/my hashing rate and the low shares on that block. 
Well, at least it doesn't seem they have automations in place for banning hoppers... it might be that you triggered something since most likely a few people mined with the default accounts - thus making you look like a botnet.
Bitclockers seem very fishy (abnormally "bad luck" with some wild claims their bitcoind is being hacked or something), and they claim to have a different payout system now.
Next on the possible features list: logging in on websites + "manually" paying out asap to make sure you don't loose money when/if being banned.
Edit:
Another possible pool would be x8s.de. Stats are openly available + live --> but only after a login.
Edit2:
MtRed just found a block - and just take a look at that sudden 100 GH/s hash rate increase! https://mtred.com/site/page/view/about.html
Bitclockers seem very fishy (abnormally "bad luck" with some wild claims their bitcoind is being hacked or something), and they claim to have a different payout system now.
Next on the possible features list: logging in on websites + "manually" paying out asap to make sure you don't loose money when/if being banned.
Edit:
Another possible pool would be x8s.de. Stats are openly available + live --> but only after a login.
Edit2:
MtRed just found a block - and just take a look at that sudden 100 GH/s hash rate increase! https://mtred.com/site/page/view/about.html
I disabled bitcoins.lc a while ago because they are banning pool hoppers.
Why did you disable bitclockers though?
4) High stales with oczo.in?
I think oczo.in is getting a little overloaded. Might be our fault
I think oczo.in is getting a little overloaded. Might be our fault
Yep, seems its ozco.in causing those 8-10% stales, new block on btcguild giving me normal ~0.5% stales.
I will keep monitoring and see over couple of blocks how stales progress across pools.
1) Only mining eligius?
I disabled bitcoins.lc a while ago because they are banning pool hoppers.
Since none of the pools have sharecounts < difficulty * .40 it won't hop to any of them and uses the two backup pools: eligius and arstechnica.
I disabled bitcoins.lc a while ago because they are banning pool hoppers.
Since none of the pools have sharecounts < difficulty * .40 it won't hop to any of them and uses the two backup pools: eligius and arstechnica.
What could be more interesting would be to prefetch getworks - so you always already have one available once your miner requests a new one instead of having internet delays at each new request.
I think this is the job of a proper mining client.
)About that BTCGuild error:
2011-07-14 21:57:37+0200 [HTTPChannel,0,127.0.0.1] RPC request [] submitted to BTC Guild
2011-07-14 21:57:38+0200 [HTTP11ClientProtocol,client] Error in json decoding, Server probably down
2011-07-14 21:57:38+0200 [HTTP11ClientProtocol,client]
2011-07-14 21:57:38+0200 [HTTP11ClientProtocol,client] Server change to ozcoin, telling client with LP
not very descriptive unfortunately...
What could be more interesting would be to prefetch getworks - so you always already have one available once your miner requests a new one instead of having internet delays at each new request.
I think this is the job of a proper mining client.
If a server accepted valid shares of other servers that would be a bug in the server code, not an intended feature. Something to try out, but not something worth doing in the long run.
What could be more interesting would be to prefetch getworks - so you always already have one available once your miner requests a new one instead of having internet delays at each new request.
I got some json decoding errors at btcguild btw., but they mine so fast that it's hard to really debug it...
What could be more interesting would be to prefetch getworks - so you always already have one available once your miner requests a new one instead of having internet delays at each new request.
I got some json decoding errors at btcguild btw., but they mine so fast that it's hard to really debug it...
i just read point 2)
are you saing it would be possible to submit the same share to multiple pools?
i am pretty sure you must deliever a share where the getwork came from.
i'll try the idea to switch pools fast tonight. lets see... my python skills still lack
are you saing it would be possible to submit the same share to multiple pools?
i am pretty sure you must deliever a share where the getwork came from.
i'll try the idea to switch pools fast tonight. lets see... my python skills still lack
1) bithopper switching pools quickly?
Its is feasible. The lag is the network connection not the server. Stale shares should also be going down a lot hopefully since I ironed out a lot of LP bugs.
2) Random idea
I'm actually tempted to write the code to submit each share to every server... Seems like it'd make it possible to get more credit. But it would also probably increase stales a lot since some servers won't accept random shares but only the shares they gave you the getwork for.
4) High stales with oczo.in?
I think oczo.in is getting a little overloaded. Might be our fault
Its is feasible. The lag is the network connection not the server. Stale shares should also be going down a lot hopefully since I ironed out a lot of LP bugs.
2) Random idea
I'm actually tempted to write the code to submit each share to every server... Seems like it'd make it possible to get more credit. But it would also probably increase stales a lot since some servers won't accept random shares but only the shares they gave you the getwork for.
4) High stales with oczo.in?
I think oczo.in is getting a little overloaded. Might be our fault
is it possible for bitHopper to switch between pools very fast without producing stales?
if so, i think it could be better to decide pool target per submitted share:
one (simple) example for each client getwork request:
DIFF = 10000 (example)
btcguild = 1/100 = 0.01 (means btcguild has 100 shares right now)
bitpit = 1/3000 = 0.0003
bitclockers = 1/500 = 0.002
bitcoinslc = 1/10000 = 0.00001
BREAKEVEN = DIFF * 0.4 = 4000 (only switch between pools lower than break even)
RAND(0, (btcguild + bitpit + bitclockers))
0-0.01 -> btcguild
0.01-0.0103 -> bitpit
0.0103-0.0303 -> bitclockers
i want to implement this (and submit a pull request if it works of course). but i don't know if is feasible to switch that fast. i dont want to have much more stales
if so, i think it could be better to decide pool target per submitted share:
one (simple) example for each client getwork request:
DIFF = 10000 (example)
btcguild = 1/100 = 0.01 (means btcguild has 100 shares right now)
bitpit = 1/3000 = 0.0003
bitclockers = 1/500 = 0.002
bitcoinslc = 1/10000 = 0.00001
BREAKEVEN = DIFF * 0.4 = 4000 (only switch between pools lower than break even)
RAND(0, (btcguild + bitpit + bitclockers))
0-0.01 -> btcguild
0.01-0.0103 -> bitpit
0.0103-0.0303 -> bitclockers
i want to implement this (and submit a pull request if it works of course). but i don't know if is feasible to switch that fast. i dont want to have much more stales
1) account banning?
Pool Hopping. Go figure. I had some funds. I have no idea how much. I was trying to log in and check.
2) Errors in LP?
I think I fixed some. I might be using the wrong agent. Let me check. And a debug log or any log helps because then I can clearly see the error. And then I can try and check my logs for it. I have a flaky DNS resolver though so my reject rates are higher than they should be so sometimes I see errors and think it is because of that.
EDIT: And I used the wrong agent... So the latest revision has that fixed as well. Probably why LP wasn't working.
3) zero division errors?
Bad code on my part. Its fixed in the latest revision.
Pool Hopping. Go figure. I had some funds. I have no idea how much. I was trying to log in and check.
2) Errors in LP?
I think I fixed some. I might be using the wrong agent. Let me check. And a debug log or any log helps because then I can clearly see the error. And then I can try and check my logs for it. I have a flaky DNS resolver though so my reject rates are higher than they should be so sometimes I see errors and think it is because of that.
EDIT: And I used the wrong agent... So the latest revision has that fixed as well. Probably why LP wasn't working.
3) zero division errors?
Bad code on my part. Its fixed in the latest revision.
I think you nailed the problem here
0% stales and counting.EDIT: may have spoken to early or it could just be ozco.in that is staled to shit. While mining on btcguild the stales remained at 0% then it switched over to ozco.in and stales went to 10%
Using phoenix and -u localhost:8337 I just get:
Unknown protocol:
Unknown protocol:
Try throwing any credentials at it and see if it works
Doh, just forgot the http://.
1) account banning?
Pool Hopping. Go figure. I had some funds. I have no idea how much. I was trying to log in and check.
2) Errors in LP?
I think I fixed some. I might be using the wrong agent. Let me check. And a debug log or any log helps because then I can clearly see the error. And then I can try and check my logs for it. I have a flaky DNS resolver though so my reject rates are higher than they should be so sometimes I see errors and think it is because of that.
EDIT: And I used the wrong agent... So the latest revision has that fixed as well. Probably why LP wasn't working.
3) zero division errors?
Bad code on my part. Its fixed in the latest revision.
Pool Hopping. Go figure. I had some funds. I have no idea how much. I was trying to log in and check.
2) Errors in LP?
I think I fixed some. I might be using the wrong agent. Let me check. And a debug log or any log helps because then I can clearly see the error. And then I can try and check my logs for it. I have a flaky DNS resolver though so my reject rates are higher than they should be so sometimes I see errors and think it is because of that.
EDIT: And I used the wrong agent... So the latest revision has that fixed as well. Probably why LP wasn't working.
3) zero division errors?
Bad code on my part. Its fixed in the latest revision.
3) ozco.in?
I'll add it. I just wasted two hours of my life trying to reset my bitcoins.lc account before they told me they banned it.
I'll add it. I just wasted two hours of my life trying to reset my bitcoins.lc account before they told me they banned it.
What did they ban your account for? With funds?
Does anyone know why im getting these API errors for bitclockers/bitpit ?
Code:
Error in user api for bitp
"[Failure instance: Traceback:: float division by zero\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:1076:gotResult\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:1063:_inlineCallbacks\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:361:callback\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:455:_startRunCallbacks\n--- ---\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:542:_runCallbacks\n/home/miner1/bitHopper/stats.py:65:selectsharesResponse\n/home/miner1/bitHopper/stats.py:55:parse_bitp\n]"
Code:
"[Failure instance: Traceback:: float division by zero\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:1076:gotResult\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:1063:_inlineCallbacks\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:361:callback\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:455:_startRunCallbacks\n--- ---\n/usr/lib/python2.7/dist-packages/twisted/internet/defer.py:542:_runCallbacks\n/home/miner1/bitHopper/stats.py:65:selectsharesResponse\n/home/miner1/bitHopper/stats.py:39:parse_bitclockers\n]"
I'm getting the same thing....
Because you have no submitted shares for them.
Ok no --debug yet but can confirm atleast its LP related.
I am using phoenix 1.5 with phatk(same version i use directly giving <1% stales) but just for interest sake i used poclbm and poclbm with phatk, same issue with stales around LP.
Since I can clearly see its around LP it should be easy to replicate these stales for anyone , thus i dont think its specific to me that you would require a debug log just yet
I am using phoenix 1.5 with phatk(same version i use directly giving <1% stales) but just for interest sake i used poclbm and poclbm with phatk, same issue with stales around LP.
Since I can clearly see its around LP it should be easy to replicate these stales for anyone , thus i dont think its specific to me that you would require a debug log just yet
OP can you change something on thread title or first post to node when you make a major code update 
You mean everyone doesn't run git log!
Sure. I'll throw it in the first post When a big change is made. There shouldn't be too many more besides database integration.
mmm still incredibly high stales.
Im using latest version and after LP and running on btcguild atm its between 12-17% stales , I think alot of the stales came from the LP new block but still if I run on btcguild directly with same defined server I get <1% gauranteed stales.
Is this related to bithopper or something you are working on to resolve?
Im using latest version and after LP and running on btcguild atm its between 12-17% stales , I think alot of the stales came from the LP new block but still if I run on btcguild directly with same defined server I get <1% gauranteed stales.
Is this related to bithopper or something you are working on to resolve?
I'm not sure. LP was screwed up until a recent commit due to the code reorganization. It should be fixed now.
Can you update to the latest version and if the issue is still apparent:
1) open an issue on github (or just repost here)
2) run bitHopper.py --debug and give me a link to the logs
3) Tell me what miner you are using so I can duplicate it on my test machine.
Jump to: