mmm im on the beta pool, just to give you some of miner results:
fresh restart short while ago: Grand Total : [1143.11 MHash/sec] [526 Accepted] [2 Rejected] [.380% Rejected]
bit longer running session : Grand Total: [1153.73 MHash/sec] [7930 Accepted] [76 Rejected] [.958% Rejected]
Grand Total: [784.48 Mhash/sec] [3003 Accepted] [33 Rejected] [1.00% Rejected]
Grand Total: [1139.64 MHash/sec] [7744 Accepted] [78 Rejected] [1.007% Rejected]
Rest of the machines all follow same results , most of the results from mtred so far.
So all of these are fairly acceptable to me.
Topic: bitHopper: Python Pool Hopper Proxy - page 117. (Read 355816 times)
Parapinaikos, that's not exactly as I suggested it - at least in the pool.py and website.py version of your pull request "application_path" isn't even used. Also __file__ will always exist, it will just point to a wrong path when being frozen ("compiled").
Edit:
For clarification: the code I posted was the whole "try:" block. Why did you do the changes, were there errors?
my bad, there were no errors I copy pasted poorly Edit:
For clarification: the code I posted was the whole "try:" block. Why did you do the changes, were there errors?
) and create another pull request? Thanks a lot! As soon as this is in, I might be able to provide single exe-file distributions (+ pools.cfg.default + index.html + README) of every commit from then on! 
ok, pm sent
So far I've got 1.5% stales on mtred 
Damn, I am up around 4.5-5% stales. Might be because I am using phoenix with a bunch of the phatk tweaks though.
before i went to the beta pool, it stays <1%...so i guess it's just the beta pool issue.
Parapinaikos, that's not exactly as I suggested it - at least in the pool.py and website.py version of your pull request "application_path" isn't even used. Also __file__ will always exist, it will just point to a wrong path when being frozen ("compiled").
Edit:
For clarification: the code I posted was the whole "try:" block. Why did you do the changes, were there errors?
my bad, there were no errors I copy pasted poorly Edit:
For clarification: the code I posted was the whole "try:" block. Why did you do the changes, were there errors?
) and create another pull request? Thanks a lot! As soon as this is in, I might be able to provide single exe-file distributions (+ pools.cfg.default + index.html + README) of every commit from then on! So far I've got 1.5% stales on mtred
Damn, I am up around 4.5-5% stales. Might be because I am using phoenix with a bunch of the phatk tweaks though.
Edit: Actually no, the only pool that is over 2% is MtRed. Sitting at 4.8% stales right now. No idea why that would be happening. How do I have double the stales to a server in the US than one in Austrailia with ozco.in?
So far I've got 1.5% stales on mtred
hmm, hovering around 2.5% now.
i normally get somewhere around .3% stales.
i normally get somewhere around .3% stales.
Anybody tried mtred beta?
it gives me slightly more stale than the regular one.
it gives me slightly more stale than the regular one.
Works for me, still <1% stales
Anybody tried mtred beta?
it gives me slightly more stale than the regular one.
it gives me slightly more stale than the regular one.
Yeah, mine_friendly is the wrong name. I might do a search and replace to change it to mine_charity.
EDIT:
__file__ doesn't always exist. just a heads up.
EDIT:
__file__ doesn't always exist. just a heads up.
__file__:
From docs: "If the loader does not make filename information available, this variable is set to None."
When does this happen??
@Hawks
How many servers and how many gh/s do you have if you make 10,000 shares in a night? Or are you on a 20 day trek?
How many servers and how many gh/s do you have if you make 10,000 shares in a night? Or are you on a 20 day trek?
3 servers. 10 miners (11 when my RMA comes back). About 2.5 Gh/s. Gone for 2.5 days. It looks like I've had 20k shares to deepbit as a backup in the last 24 hours
Why does bithopper stop polling ozco.in stats after a while (approx ~1-2h)?
Any ideas?
Any ideas?
at the current difficulty and exchange rates namecoin mining should never trigger
It wont the way its implemented atm however if implemented the way I proposed it will enable quite a few times optimally and profitably.
The approach I suggested(that c00w will implement afaik) is to stay for exactly the same variable time to difficulty so that you would be able to either A.) hit it lucky and get paid more than BTC worth or b.) get paid longterm the same worth as BTC.
Its actually quite a practical approach for the times that there is no prop pools <43% of difficulty. This method should also give you the chance of higher returns if lucky or similar returns if unlucky as EMPPS pools.
at the current difficulty and exchange rates namecoin mining should never trigger
Similar to mine_friendly (or charity or whatever) I'd like to develop a patch to extend the backup pools to all hopping proof ones and hop to the one(s) that have the highes share count currently.
Parapinaikos, that's not exactly as I suggested it - at least in the pool.py and website.py version of your pull request "application_path" isn't even used. Also __file__ will always exist, it will just point to a wrong path when being frozen ("compiled").
Edit:
For clarification: the code I posted was the whole "try:" block. Why did you do the changes, were there errors?
Parapinaikos, that's not exactly as I suggested it - at least in the pool.py and website.py version of your pull request "application_path" isn't even used. Also __file__ will always exist, it will just point to a wrong path when being frozen ("compiled").
Edit:
For clarification: the code I posted was the whole "try:" block. Why did you do the changes, were there errors?
my bad, there were no errors I copy pasted poorly
Yeah, mine_friendly is the wrong name. I might do a search and replace to change it to mine_charity.
EDIT:
__file__ doesn't always exist. just a heads up.
EDIT:
__file__ doesn't always exist. just a heads up.
Similar to mine_friendly (or charity or whatever) I'd like to develop a patch to extend the backup pools to all hopping proof ones and hop to the one(s) that have the highes share count currently.
Parapinaikos, that's not exactly as I suggested it - at least in the pool.py and website.py version of your pull request "application_path" isn't even used. Also __file__ will always exist, it will just point to a wrong path when being frozen ("compiled").
Edit:
For clarification: the code I posted was the whole "try:" block. Why did you do the changes, were there errors?
Parapinaikos, that's not exactly as I suggested it - at least in the pool.py and website.py version of your pull request "application_path" isn't even used. Also __file__ will always exist, it will just point to a wrong path when being frozen ("compiled").
Edit:
For clarification: the code I posted was the whole "try:" block. Why did you do the changes, were there errors?
pull request... done
@sukrim: The code you released is public domain or you transfer copyright to c00w?
"mine_friendly" should make it as "mine_help" (my opinion)
@sukrim: The code you released is public domain or you transfer copyright to c00w?
"mine_friendly" should make it as "mine_help" (my opinion)
This was an invalid block from 5-6 days (?) ago, that stayed in the unconfirmed payout..
Edit: Invalid block was from 2011-07-21
Edit: Invalid block was from 2011-07-21
Oh, thats weird.
On a different note, does anyone have mine_slush working? Its supposed to jump away from slush at .1*difficulty shares apparently, but the last time I tried it, it would stay until around .4*difficulty shares. Seems other people have been experiencing the same thing. I haven't tried it on the newest version of c00w's hopper though.
Um, I can see scraping the btc exchange rate and the nmc exchange rate to deal with the fact that difficulty doesn't match the price exchange, we already use the nmcdifficulty/btcdifficulty ratio. The website doesn't reflect that however.
So yeah we should scrape that and only use namepools if the two prices make sense. I agree completely.
EDIT: However I don't use namepools and I added in the capability for those who wish to. If you are using namepools you should check the exchange rates and make an informed decision. If you modify bitHopper to do it for you I welcome the pull request.
EDIT2: basically as long as nmc_price/nmc_difficulty > bitcoin_price/bitcoin_difficulty you should be mining namecoins. However if there are no pools to hop with bitcoin then if nmc_price/nmc_difficulty > .77 * bitcoin_price/bitcoin_difficulty you should hop them.
And now that I've though about it I might just code it in...
So yeah we should scrape that and only use namepools if the two prices make sense. I agree completely.
EDIT: However I don't use namepools and I added in the capability for those who wish to. If you are using namepools you should check the exchange rates and make an informed decision. If you modify bitHopper to do it for you I welcome the pull request.
EDIT2: basically as long as nmc_price/nmc_difficulty > bitcoin_price/bitcoin_difficulty you should be mining namecoins. However if there are no pools to hop with bitcoin then if nmc_price/nmc_difficulty > .77 * bitcoin_price/bitcoin_difficulty you should hop them.
And now that I've though about it I might just code it in...
This will possibly create 2 extra effects, other than just pure profitibility right now for hoppers.
1.) burst of namecoin mining traffic - creating more interest possibly and also get to the next difficulty drop a bit faster albeit the drop would be less.
2.) possible value increase since more people might decide to hop it aswell thus creating higher hashing network mostly with bursts.
Jump to: