bitHopper: Python Pool Hopper Proxy

[joulesbeef]

the "selective" lag problems with bitclockers could appear from more factors than just low QOS account or IP ban, could be geographic location too

pool.bitclockers.com 8332 Denver
pool2.bitclockers.com 8332 Chicago
pool3.bitclockers.com 8332 Czech Republic


I shouldnt have any problems with the first two, especially the second.. but i do

[Clipse]

the "selective" lag problems with bitclockers could appear from more factors than just low QOS account or IP ban, could be geographic location too

pool.bitclockers.com 8332 Denver
pool2.bitclockers.com 8332 Chicago
pool3.bitclockers.com 8332 Czech Republic


I shouldnt have any problems with the first two, especially the second.. but i do

Ive been testing flowers poclbm mod out since last night and waiting for new bitclockers block to start, will let you know if this solve the issue for me (as it apparently did for flowers)

[paraipan]

the "selective" lag problems with bitclockers could appear from more factors than just low QOS account or IP ban, could be geographic location too

pool.bitclockers.com 8332 Denver
pool2.bitclockers.com 8332 Chicago
pool3.bitclockers.com 8332 Czech Republic


I shouldnt have any problems with the first two, especially the second.. but i do

man you force me do this   ... from where you're mining ? give the coast at least or something... like plains of the purple buffalo

edit: and the third ?

[bitcoindaddy]

the "selective" lag problems with bitclockers could appear from more factors than just low QOS account or IP ban, could be geographic location too

pool.bitclockers.com 8332 Denver
pool2.bitclockers.com 8332 Chicago
pool3.bitclockers.com 8332 Czech Republic


I shouldnt have any problems with the first two, especially the second.. but i do

man you force me do this   ... from where you're mining ? give the coast at least or something... like plains of the purple buffalo

edit: and the third ?

Isn't the problem with the API and not the pool address?

[Starlightbreaker]

Hm.
bithopper refuses to hop from digbtc, even after i disabled digbtc.

[gnaget]

Hm.
bithopper refuses to hop from digbtc, even after i disabled digbtc.

He fixed that issue last night, did you get latest?

[Clipse]

When using pools that use mine_slush and altslicescheduler, shouldnt it remove the slice part on the pool if it starts to mine there and the pool allready went above the predefined 10.35% ?

What I notice is that it gives slush for instance a slice of 300sec(or whatever it sliced at) then it would eventually hop to slush even if its at >10.35% (my example it was at 40%) and then finish the 300sec slice. I think it should be able to notice the pool is assigned mine_slush (or atleast its defined something other than just mine) and clear the slice as soon as it hops there(or before it hops there)

[bitcoindaddy]

When using pools that use mine_slush and altslicescheduler, shouldnt it remove the slice part on the pool if it starts to mine there and the pool allready went above the predefined 10.35% ?

What I notice is that it gives slush for instance a slice of 300sec(or whatever it sliced at) then it would eventually hop to slush even if its at >10.35% (my example it was at 40%) and then finish the 300sec slice. I think it should be able to notice the pool is assigned mine_slush (or atleast its defined something other than just mine) and clear the slice as soon as it hops there(or before it hops there)

See my posted issue regarding this topic:

https://github.com/c00w/bitHopper/issues/128

[Clipse]

Man I know ive said it before(alot!) but I really miss the ryo_dynamicpenalty system, from what I can tell it worked much more efficient across pools using poolspeed/sharesize and duration as factors.

I think I will move back to that version for now until it is added to the main bithopper version of c00w.

[c00w]

@user5716
Update. A bunch of those errors should be fixed.

[gnaget]

Ok, now slicing is picking up bitcoins.lc which is over 50% when there are 2 pools under 30%.  Is there something I am not understanding about slicing?  For the time being, I'm moving back to the old default scheduler

[MaGNeT]

"We don't need grasshoppers... We need miners..."

MaGneT, when are you going to admit that we really do need grasshoppers?

 

I think he's referring to your signature MaGNeT   

I know 

[paraipan]

"We don't need grasshoppers... We need miners..."

MaGneT, when are you going to admit that we really do need grasshoppers?

 

I think he's referring to your signature MaGNeT   

I know 

and ?... ahh I get it, you don't change sides atm

[Starlightbreaker]

Hm.
bithopper refuses to hop from digbtc, even after i disabled digbtc.

He fixed that issue last night, did you get latest?

i just downloaded it early this morning though.

[Clipse]

Latest version of c00w hopper using altslicer, took a while before an error cropped up with latest version

Code:

[20:04:33] received lp from: digbtc
Traceback (most recent call last):
  File "./bitHopper.py", line 298, in <module>
    main()
  File "./bitHopper.py", line 294, in main
    reactor.run()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 1158, in run
    self.mainLoop()
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 1167, in mainLoop
    self.runUntilCurrent()
--- <exception caught here> ---
  File "/usr/lib/python2.7/dist-packages/twisted/internet/base.py", line 789, in runUntilCurrent
    call.func(*call.args, **call.kw)
exceptions.TypeError: pull_lp() takes exactly 3 arguments (2 given)

[c00w]

I apologize. That error should be fixed now. I made a change but wasn't thinking about it and since I don't have my test server errors that don't crop up immediately are not apparent.

EDIT: And the bug was causing getworks to lag out. So poclbm runs a lot smoother and bitclockers shouldn't be triggered as rapidly.

[EskimoBob]

feature request (https://github.com/c00w/bitHopper/issues/121)

5) reload config files without stopping the script

[paraipan]

feature request (https://github.com/c00w/bitHopper/issues/121)

5) reload config files without stopping the script

added

[hawks5999]

I apologize. That error should be fixed now. I made a change but wasn't thinking about it and since I don't have my test server errors that don't crop up immediately are not apparent.

EDIT: And the bug was causing getworks to lag out. So poclbm runs a lot smoother and bitclockers shouldn't be triggered as rapidly.

Can I recommend some sort of release management get introduced to the c00w master? There's a negative incentive to use bithopper when the master is getting committed with bug fixes several times a day and overnight:



This is 25 changes to the master in less than 24 hours.

Could you consider doing all new features and bugfixes in a test branch and only merge back into the master when the defect density dies down. I understand this is all agile and whatnot but this process is going to burn out c00w and turn off users. A stable release branch that just works and updates slowly and a test branch that can be hacked away would allow for proper regression testing and require a lot less time spent updating to the absolute newest version every 2-3 hours. Less time downloading/configuring. More time mining.

[c00w]

Well the idea is I would tag the stable releases similarly to how the linux kernel works. But well we've only had one spot where it was semistable and its been tagged as 0.1.

Also this isn't agile or anything. Its just me writing code and adding features. Sometimes I mess up. Sometimes other people mess up. Thats life.

Burnout?
Maybe. If it happens I'll probably turn the github page into an organisation and let someone else start managing it.

But if we wanted real release management it'd work something like this:
I merge changes over the weekend and monday. Tuesday and later I only merge bugfixes. Once its tested sufficiently I release a stable version.