bitHopper: Python Pool Hopper Proxy - page 75.

joulesbeef

sr. member

Activity: 476

Merit: 250

moOo

yeah and my shares are back stuck.. sitting at 24

gettting a lot of those errors

Code:

000'] submitted to PolMine.pl
2011-08-05 23:57:53-0400 [HTTPChannel,94,127.0.0.1] 'data_callback_error'
2011-08-05 23:57:53-0400 [HTTPChannel,94,127.0.0.1] "unsupported operand type(s)
 for +=: 'NoneType' and 'int'"
2011-08-05 23:57:54-0400 [HTTP11ClientProtocol,client] 127.0.0.1 - - [06/Aug/201
1:03:57:53 +0000] "POST / HTTP/1.1" 200 40 "-" "phoenix/1.50"
2011-08-05 23:57:55-0400 [HTTPChannel,95,127.0.0.1] RPC request [u'00000001538e3

console says it is writting to the database.. shares dont change.

miner console looks fine to my eyes.. and it is set to -v

Code:

2011-08-06 00:00:04: Listener for "moohopper": [06/08/2011 00:00:04] Result 00000000adbdc6c1... accepted
2011-08-06 00:00:05: Listener for "moohopper": [06/08/2011 00:00:05] Server gave new work; passing to WorkQueue
2011-08-06 00:00:06: Listener for "moohopper": [06/08/2011 00:00:06] Result 000000002a84b32d... accepted
2011-08-06 00:00:18: Listener for "moohopper": [06/08/2011 00:00:18] Server gave new work; passing to WorkQueue
2011-08-06 00:00:36: Listener for "moohopper": [06/08/2011 00:00:36] Server gave new work; passing to WorkQueue
2011-08-06 00:00:44: Listener for "moohopper": [06/08/2011 00:00:44] Server gave new work; passing to WorkQueue
2011-08-06 00:00:51: Listener for "moohopper": [06/08/2011 00:00:51] Result 00000000a524e301... accepted
2011-08-06 00:01:04: Listener for "moohopper": [06/08/2011 00:01:04] Result 00000000a1adb4d5... accepted
2011-08-06 00:01:05: Listener for "moohopper": [06/08/2011 00:01:05] Result 000000007c65c020... accepted
2011-08-06 00:01:07: Listener for "moohopper": [06/08/2011 00:01:07] Server gave new work; passing to WorkQueue
2011-08-06 00:01:10: Listener for "moohopper": [06/08/2011 00:01:10] Result 000000006a25bc52... accepted
2011-08-06 00:01:15: Listener for "moohopper": [06/08/2011 00:01:15] Server gave new work; passing to WorkQueue
2011-08-06 00:01:17: Listener for "moohopper": [06/08/2011 00:01:17] Result 00000000a4736852... accepted
2011-08-06 00:01:20: Listener for "moohopper": [06/08/2011 00:01:20] Result 0000000082134aef... accepted
2011-08-06 00:01:31: Listener for "moohopper": [06/08/2011 00:01:31] Server gave new work; passing to WorkQueue
2011-08-06 00:01:38: Listener for "moohopper": [06/08/2011 00:01:38] Server gave new work; passing to WorkQueue
2011-08-06 00:01:52: Listener for "moohopper": [06/08/2011 00:01:52] Server gave new work; passing to WorkQueue

and as I finish this comment, still sitting at 24.. miner says it is mining

on a side note, my bud has been mining bitclockers with the hopper with no problems and no rejects.. he hasnt hopped as long as most of us, so it makes me wonder if they are qos'n certain ips

GenTarkin

legendary

Activity: 2450

Merit: 1002

Need help w/ the api errors....I think this is preventing the hopping from working right grrr....
Will bypass it for now and go back to direct pool hashing...till someone can give recommendation to try =)

joulesbeef

sr. member

Activity: 476

Merit: 250

moOo

something seems to be going on with the share count on the stats page.. it wont update for ages and yet my miner console seems to be happily going along getting work and submitting work and getting accepted messages.

restarted with debug.. so far it hasnt hung with the shares again

but i see this in the hopper console

Code:

000'] submitted to BitClockers.com
2011-08-05 23:48:12-0400 [HTTPChannel,17,127.0.0.1] 'data_callback_error'
2011-08-05 23:48:12-0400 [HTTPChannel,17,127.0.0.1] "unsupported operand type(s)
 for +=: 'NoneType' and 'int'"
2011-08-05 23:48:13-0400 [HTTP11ClientProtocol,client] 127.0.0.1 - - [06/Aug/201
1:03:48:13 +0000] "POST / HTTP/1.1" 200 40 "-" "phoenix/1.50"

also I havent had any getwork spam since I rebooted.. could it have anything to do with changing hoppers while leaving guiminer running? i noticed when it happened, the miner console would say , server sent work for past block, ignoring. Or something very close to that. anyways dont rock your brain with it.. the getwork problem seems to have been local.

Quote

Mining eclipsemc as backup along with bitp...those are my 2 backups / primary mine sites.

I thought we couldnt use them for a backup due to their score method.. maybe someone can clarify.

Not sure on the api... or the longpoll but i would guess leave it enabled since we are doing longpolls now

GenTarkin

legendary

Activity: 2450

Merit: 1002

Quote from: joulesbeef on August 05, 2011, 10:42:17 PM

are you using c00ws latest? or a different fork?

also how are you mining eclipsemc? er what role is it cause they use a score base system.. if you not mine_slush(which is sorta new and use at your own risk) then it should be disabled.

Mining eclipsemc as backup along with bitp...those are my 2 backups / primary mine sites.
I am using c00ws v.11 it did it with .1 as well, using master file/download.

Also, Im using CGminer as my miner...do I disable its LongPoll? or leave it enabled?

zybron

member

Activity: 66

Merit: 10

Should slush have both the 'mine_slush' role and a penalty of 4? Seems like all the currently implemented schedulers in c00w's latest would double apply a shares * 4 penalty while hopping. It should be one or the other, right, but not both?

Code:

for server in self.bh.pool.get_servers():
         info = self.bh.pool.get_entry(server)
         if info['api_lag'] or info['lag']:
            continue
         if info['role'] not in ['mine','mine_nmc','mine_slush']:
            continue
         if info['role'] in ['mine']:
            shares = info['shares']
         elif info['role'] == 'mine_slush':
            shares = info['shares'] * 4 <---( * 4 penalty applied here )
         elif info['role'] == 'mine_nmc':
            shares = info['shares']*difficulty / nmc_difficulty
         else:
            shares = 100* info['shares']
         # apply penalty
         if 'penalty' in info:
            shares = shares * float(info['penalty']) <---( * 4 penalty applied here )

joulesbeef

sr. member

Activity: 476

Merit: 250

moOo

are you using c00ws latest? or a different fork?

also how are you mining eclipsemc? er what role is it cause they use a score base system.. if you not mine_slush(which is sorta new and use at your own risk) then it should be disabled.

GenTarkin

legendary

Activity: 2450

Merit: 1002

Hi guys, I set this up and am having some issues. About 7 "Error in pool api for xxxxx" keep spamming the console, so I assume its not getting stats from them.
The pools are:
polmine
btcmonkey
mtred
eclipsemc
rfc
nofeemining
bitp

What could be wrong...Ive verified my login and passwords...

c00w

full member

Activity: 196

Merit: 100

With the default slice scheduler penalty only changes the share count which it jumps off at. It does nothing to effect share weighting.

joulesbeef

sr. member

Activity: 476

Merit: 250

moOo

ahh yeah i guess i could have done that.. I shut down and restarted when no one else seemed to be complaining but a bud of mine and me.. so far it looks ok.. but if it happens again,, I'll restart with debugging

c00w

full member

Activity: 196

Merit: 100

db issues should be fixed. Can someone get me a debuglog of the getwork spamming? My test machine is working but it basically has no hashing power. And doesn't show that error.

EDIT: If the storing user shares in DB error isn't fixed. Please tell me. Please.

macboy80

member

Activity: 102

Merit: 10

Quote from: ahitman on August 05, 2011, 08:49:33 PM

Feature request: Is it possible to have the current shares graph put red dots when the hopper was mining at that pool? That way you can have a history of when in the pool share count your hopper was mining at a particular pool.

I second that. Maybe green dots, or the color of the active miner. I was trying to get some dynamic colors into the graph code, but I can't figure out how to test for role or mining or not mining inside of the buildTable function. I have a couple ideas, but can't code them because I have no prior experience with what I think is javascript.

Help! djex?

ahitman

sr. member

Activity: 302

Merit: 250

Feature request: Is it possible to have the current shares graph put red dots when the hopper was mining at that pool? That way you can have a history of when in the pool share count your hopper was mining at a particular pool.

Clipse

hero member

Activity: 504

Merit: 502

Quote from: joulesbeef on August 05, 2011, 08:44:27 PM

also just got my first payment with rfc pool.

their last block was invalid? how does that exactly happen? shouldnt those shares be added to the next block? in calc prop?

and bitclockers seems to be screwing with me more than ever today.

Quote

I think that is the reason Bitclockers kills bithopper. Too many getworks. Switched to CherryPicker yesterday to test it out and OMFG:

the massive getworks is new.

and those rejects are comparable to bithopper most of the time. but yeah we should see what is the difference between how cherry picker does bitclocker

the only thing i can see is they use a slightly different api addy..

going to try it... see if it helps

theirs http://bitclockers.com/api.json
ours api_address: https://bitclockers.com/api
and no https

hmmm

I think for bitclockers we should just throttle the getworks , sure we could lose 1-2% efficiency or get a few more idle miner instances but atleast we would flood their pool with massive getworks, for some reason it seems my hopper loves to pull much more getworks than submits and only seems to happen with bitclockers.

The server timeouts isnt api/json related either, I even used my own custom json host that only pulled updates 1nc every 5mins and bitclockers still died. Its somewhere between bithopper and the way bithopper managed getworks that is stuffing with bitclockers and none of the other pools. Weird.

joulesbeef

sr. member

Activity: 476

Merit: 250

moOo

also just got my first payment with rfc pool.

their last block was invalid? how does that exactly happen? shouldnt those shares be added to the next block? in calc prop?

and bitclockers seems to be screwing with me more than ever today.

Quote

I think that is the reason Bitclockers kills bithopper. Too many getworks. Switched to CherryPicker yesterday to test it out and OMFG:

the massive getworks is new.

and those rejects are comparable to bithopper most of the time. but yeah we should see what is the difference between how cherry picker does bitclocker

the only thing i can see is they use a slightly different api addy..

going to try it... see if it helps

theirs http://bitclockers.com/api.json
ours api_address: https://bitclockers.com/api
and no https

hmmm

muyoso

member

Activity: 84

Merit: 10

Quote from: joulesbeef on August 05, 2011, 08:30:47 PM

Code:

1:29:36] slush: 4817926
1:29:36] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:36] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:36] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:37] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:37] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:38] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:38] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:38] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:39] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:39] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:39] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:40] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:40] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:40] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:41] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:41] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:41] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:42] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:42] btcpool24: 977187
1:29:42] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:43] RPC request [getwork] submitted to DigBTC.net (DigBIT)

is the newest version supposed to do this sooo much?

I think that is the reason Bitclockers kills bithopper. Too many getworks. Switched to CherryPicker yesterday to test it out and OMFG:

Worked flawlessly. Just need to figure out what Cherrypicker is doing differently and emulate it. Also, I am getting .2% stales with Cherrypicker and never got below 4% stales with bithopper. . . . . .

Edit: In fact, I am getting DRASTICALLY less stales on every pool. Like by a factor of 10.

joulesbeef

sr. member

Activity: 476

Merit: 250

moOo

Code:

1:29:36] slush: 4817926
1:29:36] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:36] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:36] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:37] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:37] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:38] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:38] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:38] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:39] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:39] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:39] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:40] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:40] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:40] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:41] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:41] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:41] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:42] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:42] btcpool24: 977187
1:29:42] RPC request [getwork] submitted to DigBTC.net (DigBIT)
1:29:43] RPC request [getwork] submitted to DigBTC.net (DigBIT)

is the newest version supposed to do this sooo much?

gtrrkicw

newbie

Activity: 26

Merit: 0

Quote from: djex on August 05, 2011, 07:26:01 PM

Quote from: msb8r on August 05, 2011, 06:31:08 PM

Quote from: c00w on August 05, 2011, 04:44:01 PM

I fixed some DB problems and LP looks fixed. So I tagged v0.1.1. If you're running a version which is moderately newish this is probably what you want to use.

I think you introduced a new one, though.

Whenever BH writes to database, no further submitted shares are updated, or if they are they're not showing up on the webpage.

Example starting with no database.
Before first "writing to database" user shares are updated for pool 1. As soon as the message shows up, user shares stay static.
Switching to pool 2, the same behaviour is evident. User shares for pool 2 updates up till the point that changes are written to the database, and then stay static.

Stales are still updating though, and as far as I can tell it has no impact on performance.

I can confirm this.

I thought it was just me... I'm seeing this too

Clipse

hero member

Activity: 504

Merit: 502

Anyone figured out a way to get these 2 pools supported yet? I know Ed said he got btcmp working but still testing it, any update?

http://www.btcmp.com/

https://pool.itzod.ru/

owowo

newbie

Activity: 43

Merit: 0

just downloaded. somehow the shares count at the statspage is getting stuck, stales are ok. I stopped, bitHopper and deleted stats.db but it's stuck again... I'm on ubuntu.

djex

full member

Activity: 196

Merit: 100

Quote from: msb8r on August 05, 2011, 06:31:08 PM

Quote from: c00w on August 05, 2011, 04:44:01 PM

I fixed some DB problems and LP looks fixed. So I tagged v0.1.1. If you're running a version which is moderately newish this is probably what you want to use.

I think you introduced a new one, though.

Whenever BH writes to database, no further submitted shares are updated, or if they are they're not showing up on the webpage.

Example starting with no database.
Before first "writing to database" user shares are updated for pool 1. As soon as the message shows up, user shares stay static.
Switching to pool 2, the same behaviour is evident. User shares for pool 2 updates up till the point that changes are written to the database, and then stay static.

Stales are still updating though, and as far as I can tell it has no impact on performance.

I can confirm this.

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