you say it grabs the pools, why cant it grab the username and passes as well?
do i copy this into the bithopper dir? do I run bithopper and then this? and if so why does this need my user names again?
it also takes username and passes from the bithopper link. you just start it with a link to bitHopper json file (eg http://localhost:8337/data) and it will connect to the pool which is current in bithopper. all needed data is provided through the bithopper json interface - so bithopper don't need to be modified and you can start it from wherever you want (even on another machine). don't get confused that i didn't change the help message. just look for the working command line in my initial post. edit: made it a little more clear |
|
|
|
with my poclbm mod i am running at 0.28% and 0.33% stales (only twominers running).
and still using the nicer stats grabbing and pool decisions from bitthopper so you arent using cherry picker.. just modded poclbm and bithopper? yes, my poclbm-mod connects to bithopper and loads a pool list from there. it checks the page every three seconds and switches (with no stale or rejects) to the new bithopper-current you'll lose the worker management and submitted shares display in bithopper (and it sometimes shows an exception on a flaky connection - which could safely be ignored [just had no time to fix it right now]) btw. i am working on this atm: http://miner.k1024.deits pre pre pre alpha. only thing that works: a nice stats page where two bithopper instances pushes their round share information. they are both running on different networks - just to make sure the pools dont start playing "whats your ip" with us (suggestions are welcome) |
|
|
|
Data point on biclockers:
With Cherry: .513% stales.
2.3Gh/s on one worker from 10 GPUs
Same account and worker since before I started hopping.
FWIW.
with my poclbm mod i am running at 0.28% and 0.33% stales (only twominers running). and still using the nicer stats grabbing and pool decisions from bitthopper  |
|
|
|
if you guys want to use multiple miner pc's you could try my mod: https://bitcointalk.org/index.php?topic=34514.0it make poclbm connect to a running bithopper and switches without stales. as its a normal poclbm-pool connection there are no proxy-related problems. you can even restart bithopper without loosing shares. |
|
|
|
this is used to control your miner through an JSON-WebPage (eg. the datasite of the famous bitHopper). grab it here: https://github.com/flower1024/poclbm (make sure to get the master branch) Instead of a server you provide a link to a json file like this: (capitalized means you should change that) {
"current": "POOLNAME",
"servers": {
"POOLNAME": {
"user": "#MINER USER#",
"pass": "#MINER PASS#",
"role": "#BACKUP | DISABLE | ???#",
"mine_address": "#POOL MINE ADDRESS#:#POOL MINE PORT#",
}
}
role could be: disable don't user this server (for whatever reason) backup just like the normal poclbm backups. if the current pool fails it'll cycle through the backups  no meaning, could be "mine" Example {
"current": "rfc",
"servers": {
"mtred": {
"mine_address": "mtred.com:8337",
"pass": "minerpass",
"role": "mine",
"user": "miner.user",
},
"rfc": {
"mine_address": "pool.rfcpool.com:8332",
"pass": "minerpass",
"role": "backup",
"user": "miner_user",
}
},
}
cmd-example (for bitHopper): python -O poclbm.py http://localhost:8337/data -d 1 -v -w64 -f10 --phatk2
05/08/2011 04:57:56, reading serverlist from bitHopper http://localhost:8000/data
05/08/2011 04:57:56, adding backup USER @ pool.rfcpool.com:8332
05/08/2011 04:57:56, adding backup USER @ su.mining.eligius.st:8337
05/08/2011 04:57:56, adding server USER @ polmine.pl:8347
05/08/2011 04:57:56, adding server USER @ api2.bitcoin.cz:8332
05/08/2011 04:57:56, adding server USER @ mtred.com:8337
05/08/2011 04:57:56, adding server USER @ pool.rfcpool.com:8332
05/08/2011 04:57:56, adding server USER @ eu1.triplemining.com:8344
05/08/2011 04:57:56, adding server USER @ ozco.in:8332
05/08/2011 04:57:56, adding server USER @ pool.bitclockers.com:8332
05/08/2011 04:57:56, Setting server (USER @ rfcpps)
rfcpps 05/08/2011 04:57:56, Kernel: phatk2
rfcpps 05/08/2011 04:58:02, LP connected to rfcpps
rfcpps [389.713 MH/s (~412 MH/s)] [Rej: 0/77 (0.00%)]
atm the server list is not updated. just the "current" field is interpreted every three seconds. it switches without rejects. if you have any ideas how to improve this please let me know |
|
|
|
for me this poclbm patch solved the bitclockers problem completly. it has been a long time since i have seen my real hashrate on their site atm this patch produces some rejects when switching pools (around 4). until saturday i'll add the following: - try out poclbm mentioned by clipse - close old connection, clear work queue and reconnect lp on switch - (maybe) interface with bithopper for submitting share/rejects and user stats any other ideas? |
|
|
|
I hate to ask more of your time but could you add this feature to the phatk2 poclbm fork located here, https://github.com/progranism/poclbmUnless you allready added phatk2 and phatk2_1 support to this fork? atm its just a quick hack. lets see if it brings any good. if so i am willing to put more time on it lets wait until saturday, until then i know if i would like to use further or not. i used the fastlongpoll branch from the p2pool guy - as this works best for me. (btw: i did not change that much - only Transport.py. i am pretty sure its not that hard to integrate it in another fork) FIXED: btw i have a bug that it still trying to get back to its primary... i'll fix that |
|
|
|
i just made a poclbm fork that gets its server list from an bitHopper address. it checks every three seconds for the current pool and switches if neccesary if you want to try it out: https://github.com/flower1024/poclbmyout bitHopper url (use DATA instead of STATS - as this is where the json is, atm you must supply a username and a password): http://chaos:x@localhost:8337/dataa working command line looks like this: python -O poclbm.py http://chaos:x@localhost:8337/data --no-server-failbacks -d 1 -v -w64 -f10 04/08/2011 23:49:06, reading serverlist from bitHopper http://localhost:8337/data04/08/2011 23:49:06, adding server polmine.pl:8347 user XXX pass XXX 04/08/2011 23:49:06, adding server api2.bitcoin.cz:8332 04/08/2011 23:49:06, adding server mtred.com:8337 04/08/2011 23:49:06, adding server pool.rfcpool.com:8332 04/08/2011 23:49:06, adding server pool.rfcpool.com:8332 04/08/2011 23:49:06, adding server eu1.triplemining.com:8344 04/08/2011 23:49:06, adding server su.mining.eligius.st:8337 04/08/2011 23:49:06, adding server ozco.in:8332 04/08/2011 23:49:06, adding server pool.bitclockers.com:8332 04/08/2011 23:49:06, Setting server (peter1 @ bitclockers) bitclockers 04/08/2011 23:49:17, LP connected to bitclockers if this fork works and brings any use i might add: - backup server support (select one of bitHoppers backup pools) - submit share and reject information to bitHopper to keep their stats working |
|
|
|
Your slice method has been removed for some reason, only the altslice is left and that doesnt sort.
i am referring to the new default method in c00w which is called SlicedScheduler |
|
|
|
Cow, could you add sorting by name (ryo had that in his fork) , it just makes it more natural to read through the webui  Even better, sort by name based on mine: A-Z , backup: A-Z , mine_slush: A-Z , nmc: A-Z, disable: A-Z, info: A-Z. if you take the slice method: it has still my sorting method which is doing exactly as you described (sort by role and then by name) but i only tested it in firefox... |
|
|
|
|
have you tried it without bithopper as an immediate (and different worker names)?
i still get some connection errors, but not that much as before (atm 1 conn errorevery minute - which bh ignores) - maybe you get more (as you have more getworks in general) - and therefor bh disabled bclockers faster?.
|
|
|
|
|
bitclockers is working fine..
just make a new account, thats enough
|
|
|
|
Um, I am running 400mhash through bitclockers from a single machine. I did not make a new account or get a new ip. The latest version shouldn't have any obvious errors. When you are running a lot of Mhash's through them what happens? Do they just lag out a lot quicker? b/c we could have the delagger run more often. Or is it just an artificially high reject rate? and is bitclockers the only pool where it appears?
bitclocker is the only one. and it's mainly connection errors (delagger works fine; maybe you could change the it to percentage - means: last 10 getworks, more than 2% conn error -> lag) it is lagging really fast. it switches to bitclockers, stays for 3 secs (approx) and lag again. with multiple bithoppers i saw way less connection errors (it stays for about 10-20secs), and the bitclocker-guy where talking about some traffic control - so i thought i could just be the amount of getworks now i think i should make a new user and redirect my bitclockers traffic through a fresh ip |
|
|
|
I have bitclockers working fine for myself.
how much mhash are you pushing? with everything above 300mh i get way more connection errors. with different worker they all are doing fine (still some connection errors, but not that much) |
|
|
|
Hardly worth all that for one pool  yep, its just a matter of principle |
|
|
|
|
i now have a working configuration for bitclockers (but it requires two different ip's)
first-ip: start a bithopper instance
second-ip: start a bithopper instance per worker on a different port (eg you have three workers just put them at ports 8000,8001,8002)
-> change pools.cfg to get stats from http://<firstip>/data
format is always json, key is servers.#poolname#.shares
(poolname does not refer to its name, it the key inside [key] in pools.cfg)
-> change users.cfg to get a unique workername for bitclockers at each port
(as this file is always read in through bithopper start, you can write a script which starts the instances all from the same directory, just switches the users.cfg)
-> you could change the stat update interval in bitHopper.py (ONLY on your worker-hopper, not on stats hopper)
now connect your worker - each to a different bithopper port
now you can mine at bitclockers again.
^^ with this your stats will be a little messed up;
|
|
|
|
|
obvious: i vote for a blue.(as it was me using it on the first stats page which just got copied (its still pd))
the theme idea shouldn't be very complex. i could rewrite the stats page that all colors are from an css file.
with jquery the css could be replaced easily (without reloading)
|
|
|
|
So for some reason it likes to get stuck on BTCPool24.
yep, something is not right, 40593 seconds from beginning of the round (11 hours) at 30Gh on average (have seen 50Gh+), has only 288422 shares... Try my AltSliceScheduler: https://github.com/echiu64/bitHopperUse options like --scheduler AltSliceScheduler --altslicesize=1200 Default is 600 "slice" or "pie" size, in that the 600 will be divided amongst the pools, weighted by their share count. For really fast switch set it to 60. Takes about a minute or so to wait for all the stats to initialize and have the slice redistribution get set. Not sure if there is a better way to trigger this earlier. Still using the previous stats page for the alt slice scheduler, so should be functional... You can see the time slice count on the stats page as well and will decrement over time. The next largest slice will be selected. Once all are exhausted, slices are recalculated... Credit goes to flowers for the original implementation really nice! thank you very much for that. just a little suggestion: if "reslice" occurs don't take the pool with the biggest slice. instead check if the current pool got another slice and if so stay there -> reducing hopping a little and worked well for me (i changed it in a later version, so you might not have catched it up). i'll switch to your version now. do you want me to make the suggestion as a pull request? its really not much |
|
|
|
flower1024, could you box in the outer edges of the graph? it would look better then leaving a space above and under them like you do now. (just extend it to the Dark Blue lines separating the different pools)
ok |
|
|
|
The timeouts are caused by the pool on purpose though because we're identified by IP and user/workername as offending hoppers (see burnbacks post a few pages back). How will client side worker management get around this?
ok, client side worker are not really needed to solve this as bithopper could just split getwork requests through its workers; but i am very sure that missing them is the reason we got currupted (NOT stale) shares) but i think its easier to implement - as you "always" know worker 1 goes to pool worker 1 and so on. |
|
|
|
|
Show Posts
