Pages:
Author

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

legendary
Activity: 2955
Merit: 1049
August 05, 2011, 03:46:00 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...
hero member
Activity: 504
Merit: 502
August 05, 2011, 03:42:03 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.
legendary
Activity: 1526
Merit: 1002
Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na
August 05, 2011, 03:39:24 PM
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...
hero member
Activity: 504
Merit: 502
August 05, 2011, 03: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.

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.
legendary
Activity: 924
Merit: 1004
Firstbits: 1pirata
August 05, 2011, 03:34:37 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
full member
Activity: 196
Merit: 100
August 05, 2011, 03:33:27 PM
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.
full member
Activity: 168
Merit: 100
August 05, 2011, 03: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...
hero member
Activity: 504
Merit: 502
August 05, 2011, 03:19:38 PM
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 ?
full member
Activity: 196
Merit: 100
August 05, 2011, 03:05:11 PM
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.
full member
Activity: 168
Merit: 100
August 05, 2011, 02:58:09 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.
legendary
Activity: 924
Merit: 1004
Firstbits: 1pirata
August 05, 2011, 02:36:35 PM
feature request (https://github.com/c00w/bitHopper/issues/121)

5) reload config files without stopping the script


added
legendary
Activity: 910
Merit: 1000
Quality Printing Services by Federal Reserve Bank
August 05, 2011, 02:33:25 PM
feature request (https://github.com/c00w/bitHopper/issues/121)

5) reload config files without stopping the script
full member
Activity: 196
Merit: 100
August 05, 2011, 02: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.
hero member
Activity: 504
Merit: 502
August 05, 2011, 02:06:31 PM
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)
legendary
Activity: 1764
Merit: 1006
August 05, 2011, 01:54:17 PM
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.
legendary
Activity: 924
Merit: 1004
Firstbits: 1pirata
August 05, 2011, 01:51:32 PM
"We don't need grasshoppers... We need miners..."

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

 Grin

I think he's referring to your signature MaGNeT   Roll Eyes

I know  Grin

and ?... ahh I get it, you don't change sides atm
legendary
Activity: 1526
Merit: 1002
Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na
August 05, 2011, 12:48:17 PM
"We don't need grasshoppers... We need miners..."

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

 Grin

I think he's referring to your signature MaGNeT   Roll Eyes

I know  Grin
full member
Activity: 154
Merit: 102
August 05, 2011, 12:40:59 PM
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
full member
Activity: 196
Merit: 100
August 05, 2011, 12:34:16 PM
@user5716
Update. A bunch of those errors should be fixed.
hero member
Activity: 504
Merit: 502
August 05, 2011, 12:16:32 PM
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.
Pages:
Jump to: