bitHopper: Python Pool Hopper Proxy - page 77.

ewibit

legendary

Activity: 2955

Merit: 1049

Quote from: Clipse on August 05, 2011, 02:38:49 PM

btcpool24 is acting up again, json stats reset as if block were found yet the main stats still count on from previous shares.

it has been now a few times that we see 3,23% Cheesy

look at his stats page how it jumps up and down Grin

edit:
digbtc.net is always going to api_disable...

Clipse

hero member

Activity: 504

Merit: 502

Quote from: MaGNeT on August 05, 2011, 02:39:24 PM

Did BTCPool24 just find their second block? Or are they faking stats?

This is the 2nd stats reset after the first block were found(paid out), Im getting tired of these screwups but ive committed a ton of shares and first expect some payout before I fukoff.

MaGNeT

legendary

Activity: 1526

Merit: 1002

Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na

Did BTCPool24 just find their second block? Or are they faking stats?

edit: looks like faking... They are "disable" now...
edit: stats are "normal" again... Maybe "enable" them later...

Clipse

hero member

Activity: 504

Merit: 502

btcpool24 is acting up again, json stats reset as if block were found yet the main stats still count on from previous shares.

I dont know what to believe on this site anymore, just to get get some sort of payout before i leave since its starting to feel extremely dodgy to me.

paraipan

legendary

Activity: 924

Merit: 1004

Firstbits: 1pirata

Quote from: hawks5999 on August 05, 2011, 02:23:28 PM

https://bitcointalksearch.org/topic/m.431969

Props to c00w given in this message by the finder of the first block on digbtc...

I wish he got a lucky find on another pool right now for being that onest

c00w

full member

Activity: 196

Merit: 100

Well penalty is already combined into the slice scheduler. However because it is based off of time not sharecount it won't effect much. Honestly it looks like AltSliceScheduler will become the default once all its issues are fixed and the current default will become SimpleSliceScheduler.

hawks5999

full member

Activity: 168

Merit: 100

https://bitcointalksearch.org/topic/m.431969

Props to c00w given in this message by the finder of the first block on digbtc...

Clipse

hero member

Activity: 504

Merit: 502

Im not so concerned bout the odd issues with certain fixes, atleast it speeds up development eitherway.

That said, how does the timeline look for you c00w to get a splice of slice scheduler combined with dynamicpenalty (using poolspeed/shares/duration) included in main bithopper version ?

c00w

full member

Activity: 196

Merit: 100

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.

hawks5999

full member

Activity: 168

Merit: 100

Quote from: c00w on August 05, 2011, 01:24:11 PM

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.

paraipan

legendary

Activity: 924

Merit: 1004

Firstbits: 1pirata

Quote from: EskimoBob on August 05, 2011, 01:33:25 PM

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

5) reload config files without stopping the script

added

EskimoBob

legendary

Activity: 910

Merit: 1000

Quality Printing Services by Federal Reserve Bank

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

5) reload config files without stopping the script

c00w

full member

Activity: 196

Merit: 100

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.

Clipse

hero member

Activity: 504

Merit: 502

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

Code:

[20:04:33] received lp from: digbtc
Traceback (most recent call last):
  File "./bitHopper.py", line 298, in 
    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()
---  ---
  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)

Starlightbreaker

legendary

Activity: 1764

Merit: 1006

Quote from: gnaget on August 05, 2011, 10:59:28 AM

Quote from: Starlightbreaker on August 05, 2011, 10:56:32 AM

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.

paraipan

legendary

Activity: 924

Merit: 1004

Firstbits: 1pirata

Quote from: MaGNeT on August 05, 2011, 11:48:17 AM

Quote from: paraipan on August 05, 2011, 06:42:13 AM

Quote from: MaGNeT on August 05, 2011, 05:06:28 AM

Quote from: hawks5999 on August 05, 2011, 02:28:43 AM

Quote from: MaGNeT on August 05, 2011, 02:11:55 AM

"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 Roll Eyes

I know

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

MaGNeT

legendary

Activity: 1526

Merit: 1002

Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na

Quote from: paraipan on August 05, 2011, 06:42:13 AM

Quote from: MaGNeT on August 05, 2011, 05:06:28 AM

Quote from: hawks5999 on August 05, 2011, 02:28:43 AM

Quote from: MaGNeT on August 05, 2011, 02:11:55 AM

"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 Roll Eyes

I know

gnaget

full member

Activity: 154

Merit: 102

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

c00w

full member

Activity: 196

Merit: 100

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

Clipse

hero member

Activity: 504

Merit: 502

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.

Topic: bitHopper: Python Pool Hopper Proxy - page 77. (Read 355813 times)