Phoenix and most other miners only have 1 thread doing submissions. If it fails they drop the work. Bithopper doesn't.
kick ass, is that one of your features? I just keep becoming more and more of a fan of this proxy
Topic: bitHopper: Python Pool Hopper Proxy - page 124. (Read 355689 times)
kick ass, is that one of your features? I just keep becoming more and more of a fan of this proxy
Phoenix and most other miners only have 1 thread doing submissions. If it fails they drop the work. Bithopper doesn't.
check the pool websites your mining at, rfc is showing 2% stales for me this round using your script but that could be for other reasons.
Good idea... I think I can take this as confirmation (rfc):
Last 15 Mins 1359 0 0.000%
I can't believe this gets less stales than phoenix by itself.
gnadget: We only hold the last 5 minutes worth of objects. Memory usage with 500 getworks in 5 minutes < 1 mb.
But we hold the entire merkle root in string format (64 characters). Assuming a 2 byte encoding, we are looking at 128 bytes per merkle root. I would estimate I am averaging 3 getworks / s so 3*60*5 = 900. 900 * 128 = 115,200 BYTES... I see my error in caclulations: I was thinking in kilobytes, duh computers are hard.
that's 10% of 1 mb, would handle bigger loads then...
edit: rfc lags big time, let's hope they upgrade sometime in the future
also, has anyone got polmine to work? i just get API error and 591402.50% shares.
copy>paste whole pool.cfg.default entry to you cfg and edit only miner and pass, here work just fine
i got it to work, i think it might have something to do with that there's an english version and a polish version of the site, resulting in that it doesn't find the polish text "szystkich".
So i changed it to make it friendly for both the versions.
Code:
api_key::
([ 0-9]+)
But we hold the entire merkle root in string format (64 characters). Assuming a 2 byte encoding, we are looking at 128 bytes per merkle root. I would estimate I am averaging 3 getworks / s so 3*60*5 = 900. 900 * 128 = 115,200 BYTES... I see my error in caclulations: I was thinking in kilobytes, duh computers are hard.also, has anyone got polmine to work? i just get API error and 591402.50% shares.
copy>paste whole pool.cfg.default entry to you cfg and edit only miner and pass, here work just finegnadget: We only hold the last 5 minutes worth of objects. Memory usage with 500 getworks in 5 minutes < 1 mb.also, has anyone got polmine to work? i just get API error and 591402.50% shares.
Working good for me. Haven't had an API error today with it. At 1087793 shares.also, has anyone got polmine to work? i just get API error and 591402.50% shares.updated to latest7
also, what pools do you have switched on to mine at?
i keep getting TCP error all the time and my hopper keeps switching pool every 40 sec :/
Yeah mine has been getting periods of this for a few hours now. Rfc gets lagged easy.
Also using this new code 1019 / 0. Working good.
updated to latest
also, what pools do you have switched on to mine at?
i keep getting TCP error all the time and my hopper keeps switching pool every 40 sec :/
I think that is just rfc being rfc. There is a lot of lag on their server. The important thing is you don't get stales when you hop to and away from itupdated to latest
http://i.imgur.com/BMUTq.png7
also, what pools do you have switched on to mine at?
i keep getting TCP error all the time and my hopper keeps switching pool every 40 sec :/check the pool websites your mining at, rfc is showing 2% stales for me this round using your script but that could be for other reasons.Holy carp on a stick. I'm up to 11,000 shares / 0 stales. I'm actually a little worried about the lack of stales. Plus, I have to stop it and move it over to a screen session, and I really don't want to interrupt this run
What is really amazing, and I don't understand how this is possible, I have the exact same memory usage with update and I did before. The new object should be pretty largeUm obvious errors or a reject rate above 10%. Or bizarre behavior with regards to pool selection.
13 minutes running and 0 stales, normal behavior
edit: I'm changing servers like crazy here just to see it fail, no luck by now
edit2: looks like the "bad" merge was good after all, I miss the stales ppl, send me some, hehe just kiddingOr bizarre behavior with regards to pool selection.
Did you include the mine_friendly role?
9000 shares, 0 stales for me, and that is with getting a lot of lagging out of rfc and switching servers. I'm impressed, but I haven't tried your version yeteverything awesome right now.. 0 rejects.. only one hop so far but it went without rejects.
looks more than good so far.Um obvious errors or a reject rate above 10%. Or bizarre behavior with regards to pool selection.I should write a style guide for bitHopper and then list the 60% of the code I want to rewrite to follow the style guide.
work.py is an especially big mess.
I don't have access to my test machine but has anyone been testing with trunk? If its working I can turn it on in the repo remotely.
is working all right but dunno what to search for (the trunk you posted before)
edit: whoa f...in nice, changing servers randomly and it doesn't loose the temper
edit 2: just changed 3 servers (3-4 seconds on every one) and back to backup, it didn't loose 1 lame share, you gotta see this manJump to:
