bitHopper: Python Pool Hopper Proxy - page 144.

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

Quote from: gnaget on July 27, 2011, 01:03:33 AM

Quote from: macboy80 on July 27, 2011, 12:48:53 AM

2) Can we add something to skip/not show disabled servers in the new stats like gnaget did a couple pages back or add a role like removefromlist?

Actually, if you use the role of removefromlist, and change my code from comparing to =="disable" to =="removefromlist" you'd probably get the exact behavior you are looking for

...or if you're as lazy as me but want to keep all the info in pools.cfg, just comment out the config for the pools you dont want showing up.

macboy80

member

Activity: 102

Merit: 10

Quote from: gnaget on July 27, 2011, 01:03:33 AM

Actually, if you use the role of removefromlist, and change my code from comparing to =="disable" to =="removefromlist" you'd probably get the exact behavior you are looking for

c00w just merged flower's stats into the master fork. I looked for your code in the new index.html and had no luck finding it. I like the way you think though. 2 hours ago that would have covered it damn well. That's the type of coding I can do. If you figure out the new stats, I'd love to see your changes. Thanks.

gnaget

full member

Activity: 154

Merit: 102

Quote from: macboy80 on July 27, 2011, 12:48:53 AM

2) Can we add something to skip/not show disabled servers in the new stats like gnaget did a couple pages back or add a role like removefromlist?

Actually, if you use the role of removefromlist, and change my code from comparing to =="disable" to =="removefromlist" you'd probably get the exact behavior you are looking for

macboy80

member

Activity: 102

Merit: 10

Quote from: Sukrim on July 27, 2011, 12:55:40 AM

Nice ideas, code a patch/fork and do a pull request!

Not quite the "debate" I was looking for... My programing level is that of a first ~~year~~ semester C++ flunkie. I am, however, willing to provide modest tips and loads of feedback for improvements, and even if I could, I wouldn't want to make changes that weren't appreciated by the community.

That being said, how are you guys using the efficiency function of the stats page?

gnaget

full member

Activity: 154

Merit: 102

Quote from: Sukrim on July 27, 2011, 12:55:40 AM

Nice ideas, code a patch/fork and do a pull request!

That is so much harder than just letting c00w worry about it

Sukrim

legendary

Activity: 2618

Merit: 1007

Nice ideas, code a patch/fork and do a pull request!

macboy80

member

Activity: 102

Merit: 10

Ok, I have a whole laundry list of questions/feature request. I will number them.

1) How does the efficiency work?
2) Can we add something to skip/not show disabled servers in the new stats like gnaget did a couple pages back or add a role like removefromlist?
3) Can we sort the stats by: %Difficulty, %Efficiency, Role (mine; mine_slush; mine_nmc; backup; disabled)?
4) Can we show round duration like ryouiki?
5) Would it be worth it to move some of the more specific/custom variables into a .cfg file like: API Timeout Tries, %Diff to hop Backup and %Diff to hop Slush (possibly per pool in pool.cfg), Server Port, Stats sort-by (possibly from above question), etc?

Just want stoke the debate a little here. Let me know what you think.

EDIT: I do like flower's stats as a basis for future optimizations.

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

Quote from: tigereye on July 27, 2011, 12:13:45 AM

Quote from: organofcorti on July 27, 2011, 12:08:21 AM

I think you might find all pools are above the jump off point. When there are no other suitable pools bitHopper defaults to XXPPS type pool until a better pool is found.

I thought that was the problem at first, which is why I cleared out the stats (deleted stats.db)
When I restarted bitHopper it showed 0 stats across the board.

Wouldn't this make it choose one of the "mine" pools over the "backup" pool?
Or am I misunderstanding bitHopper?

Yes, you are misunderstanding bitHopper i think. Let me rephrase my last message: All proportional pools are above about 700000 shares total. This makes them unhoppable, so we go to backup. Backups are PPS or a PPS variant , meaning you get paid for every share and have an efficiency of 1.0

So I'm mining a backup at the moment, too.

Moussekateer

member

Activity: 69

Merit: 10

Quote from: tigereye on July 27, 2011, 12:13:45 AM

Quote from: organofcorti on July 27, 2011, 12:08:21 AM

I think you might find all pools are above the jump off point. When there are no other suitable pools bitHopper defaults to XXPPS type pool until a better pool is found.

I thought that was the problem at first, which is why I cleared out the stats (deleted stats.db)
When I restarted bitHopper it showed 0 stats across the board.

Wouldn't this make it choose one of the "mine" pools over the "backup" pool?
Or am I misunderstanding bitHopper?

Bithopper looks at the total number of shares submitted for a round for any pool, not just yours. Deleting your stats won't change that, your number of submitted shares isn't relevant. If the number of total shares for a round exceeds a certain number then it hops to another pool below this threshold. If there are none then it drops down to the backup pool until one of the pool rounds end.

tigereye

member

Activity: 79

Merit: 10

Quote from: organofcorti on July 27, 2011, 12:08:21 AM

I think you might find all pools are above the jump off point. When there are no other suitable pools bitHopper defaults to XXPPS type pool until a better pool is found.

I thought that was the problem at first, which is why I cleared out the stats (deleted stats.db)
When I restarted bitHopper it showed 0 stats across the board.

Wouldn't this make it choose one of the "mine" pools over the "backup" pool?
Or am I misunderstanding bitHopper?

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

Quote from: tigereye on July 27, 2011, 12:06:31 AM

I've noticed a problem with bitHopper on one of my mining rigs; the problem doesn't seem to affect the others.

It seems to ONLY mine on my backup pool, eligius.
I have other pools configured as the "mine" role, but none of them are chosen.

I just briefly saw it choose one pool for 7 shares, then it jumped right back to Eligius.

I thought maybe it had to do with the share counts (and reject counts) so I stopped it, blew away the stats.db, and restarted it.
Again it is only mining on Eligius.

The code is identical to my other rigs, and those rigs have identical cfg files which define identical pools.
It's the same version of git code too, so the algorithms they're using are the same too.

Can anyone offer a suggestion on why one rig is choosing my "backup" pool while the other rigs are properly hopping between my "mine" pools?

I think you might find all pools are above the jump off point. When there are no other suitable pools bitHopper defaults to XXPPS type pool until a better pool is found.

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

Quote from: c00w on July 26, 2011, 11:38:39 PM

total pool shares are shown in the html... They might not be shown for mine_slush and mine_nmc. I'll check and fix it.

Sorry. I didn't make that very clear, I was typing from my phone. I meant that they weren't being shown for mine_slush. So far I'm on 140% for slush and 120% for mineco, but it's only a few rounds and I haven't checked to see if they were more or less than difficulty. So far so good though.

If this does work there are a bunch of pplns pools to try. None like slush though.

tigereye

member

Activity: 79

Merit: 10

I've noticed a problem with bitHopper on one of my mining rigs; the problem doesn't seem to affect the others.

It seems to ONLY mine on my backup pool, eligius.
I have other pools configured as the "mine" role, but none of them are chosen.

I just briefly saw it choose one pool for 7 shares, then it jumped right back to Eligius.

I thought maybe it had to do with the share counts (and reject counts) so I stopped it, blew away the stats.db, and restarted it.
Again it is only mining on Eligius.

The code is identical to my other rigs, and those rigs have identical cfg files which define identical pools.
It's the same version of git code too, so the algorithms they're using are the same too.

Can anyone offer a suggestion on why one rig is choosing my "backup" pool while the other rigs are properly hopping between my "mine" pools?

c00w

full member

Activity: 196

Merit: 100

total pool shares are shown in the html... They might not be shown for mine_slush and mine_nmc. I'll check and fix it.

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

@c00w - mine_slush working well so far. Small request: could you show total pool shares in the html? Atm they don't show (like backup)

macboy80

member

Activity: 102

Merit: 10

I think poolmunity had an issue a few pages back. paraipanakos had a heated debate with admin on the poolmunity forum about hopping. I think the resolution was more civil, but i'm pretty sure there is some sort of hopping protection. Check their forum.

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

Quote from: muyoso on July 26, 2011, 10:25:43 PM

Has anyone taken a look at Deepbits statistics for the last 24 hours? They are solving a block every 15 minutes. It would be awesome if there could be some sort of trigger to switch to deepbit as a backup when they are getting lucky like this. They publish their "luck" on their stats page in the form of a percent of difficulty for solved blocks over the prior 24 hours. They are at -49% right now, which is INSANE luck.

They are basically giving 150% efficiency, which is amazing as a backup.

Previous rounds are no predictor of future unfortunately. You can't predict luck on deepbit. Sorry!

Sukrim

legendary

Activity: 2618

Merit: 1007

Quote from: muyoso on July 26, 2011, 10:25:43 PM

Has anyone taken a look at Deepbits statistics for the last 24 hours? They are solving a block every 15 minutes. It would be awesome if there could be some sort of trigger to switch to deepbit as a backup when they are getting lucky like this. They publish their "luck" on their stats page in the form of a percent of difficulty for solved blocks over the prior 24 hours. They are at -49% right now, which is INSANE luck.

They are basically giving 150% efficiency, which is amazing as a backup.

Past luck does NOT say anything about future luck. Period.

macboy80

member

Activity: 102

Merit: 10

Quote from: gnaget on July 26, 2011, 10:51:38 PM

Quote from: macboy80 on July 26, 2011, 10:47:11 PM

Quote from: gnaget on July 26, 2011, 10:01:50 PM

oh, and c00w if you find a moment, perhaps you can give the option on the stats page to not show disabled pools? Not a big deal either way, I put a quick 2 lines of code in there to not show them

What's your code? I'd like that also.

In index.html I did this:

Code:

for(v in data["servers"]) {
  var srv = data["servers"][v]
  if (srv["role"]=="disable")
      continue;
  h += "";

In the javascript I moved the h+=""; line down, and added the if satement, so when it comes across a disabled server, it doesn't write it out, but simply continues on

Thanks! gnaget
I think this is ready for c00w.

gnaget

full member

Activity: 154

Merit: 102

I'm now running:

poolmunity.com
polmine.pl
bitclockers.com
bitcoinmonkey.com
mtred
bitcoins.lc
rfcpool.com
triplemining.com
nofeemining.com
ozco.in

Anything obviously stupid stands out?

Topic: bitHopper: Python Pool Hopper Proxy - page 144. (Read 355689 times)