bitHopper: Python Pool Hopper Proxy - page 24.

wtfman

member

Activity: 118

Merit: 10

BTCServ Operator

Quote from: spiccioli on August 17, 2011, 03:35:17 AM

Hi all,

I set up bitHopper yesterday, to see what I can gain from its use, but then, looking inside user.cfg I saw that a lot of proportional pools ( I looked at three or four of them in the hoppable section ), apart from mtRed, are very small pools, so I fear that variance could kill in that pools.

Apart from mtRed, what pool has at least 100Gh of hashing capacity? Or, are you using such small pools without being affected by variance, maybe because you're hopping?

spiccioli

they are so empty because of pool hopping. you cant pool hop and expect to have no downside ..

spiccioli

legendary

Activity: 1379

Merit: 1003

nec sine labore

Hi all,

I set up bitHopper yesterday, to see what I can gain from its use, but then, looking inside user.cfg I saw that a lot of proportional pools ( I looked at three or four of them in the hoppable section ), apart from mtRed, are very small pools, so I fear that variance could kill in that pools.

Apart from mtRed, what pool has at least 100Gh of hashing capacity? Or, are you using such small pools without being affected by variance, maybe because you're hopping?

spiccioli

c00w

full member

Activity: 196

Merit: 100

@--nolp
Old option for when client side LP was broken for some people. I think I removed it.

r2edu

member

Activity: 68

Merit: 10

There´s something wrong with that pool anyway.. I have submited 1576 shares and have an estimated of 0.03683698, so making simple maths the total shares at the moment must be something near 2139154 shares.... and BH is showing 1524666 84,44%, is a lot of difference

Edit: I´am getting a lots of "unknown work" in the bh console? is that bad?

cirz8

newbie

Activity: 42

Merit: 0

Quote from: cuqa on August 16, 2011, 01:08:11 PM

i recommend to remove bitcoinpool from the rotation. its obvious that they fake their shares as decoy and then even demand a fee. also they are so unprofessional in every way.. avoid!

Don't use json on them, that is why it changed to grabbing their webpage instead, update your pools.cfg

paraipan

legendary

Activity: 924

Merit: 1004

Firstbits: 1pirata

Quote from: cuqa on August 16, 2011, 02:10:03 PM

Quote from: paraipan on August 16, 2011, 01:57:42 PM

Quote from: cuqa on August 16, 2011, 01:08:11 PM

i recommend to remove bitcoinpool from the rotation. its obvious that they fake their shares as decoy and then even demand a fee. also they are so unprofessional in every way.. avoid!

you have some screen capt to sustain that ?

you dont need a screen capture. just watch their json file for a couple of mins and you will see

http://bitcoinpool.com/pooljson.php

yep, you're right about that Sad

@cirz8 yep seems like it was updated when I was out

cuqa

newbie

Activity: 40

Merit: 0

Quote from: paraipan on August 16, 2011, 01:57:42 PM

Quote from: cuqa on August 16, 2011, 01:08:11 PM

i recommend to remove bitcoinpool from the rotation. its obvious that they fake their shares as decoy and then even demand a fee. also they are so unprofessional in every way.. avoid!

you have some screen capt to sustain that ?

you dont need a screen capture. just watch their json file for a couple of mins and you will see

http://bitcoinpool.com/pooljson.php

paraipan

legendary

Activity: 924

Merit: 1004

Firstbits: 1pirata

Quote from: deepceleron on August 16, 2011, 12:36:01 PM

Quote from: r2edu on August 16, 2011, 12:00:38 PM

Anyone with problems with Ozco? It doesn´t show me any "est.earnings" and i send about 800 shares!

Edit: wich one of these commands works better or are necessary with the "mine_deepbit" mode? or the three of those at the same time?

--startLP = Seeds the LP module with known pools.

This is now the default, it doesn't need to be specified at the command-line any more.

Quote from: r2edu on August 16, 2011, 12:00:38 PM

--noLP = Turns off client side longpolling*
*i don´t understand what this one does..

I believe client-side means that Bithopper doesn't push LPs to your miner with this option, your miners would just request new work when their queue is empty, which would increase stale shares.

Quote from: r2edu on August 16, 2011, 12:00:38 PM

--p2pLP = Starts up an IRC bot to validate LP based hopping

I would encourage people to set up pool worker accounts for at least a dozen pools and add them as 'info' before using this option, otherwise the information you will be sharing with others using the IRC LP info-sharing technique would be sub-optimal.

--noLP = Turns off client side longpolling* is exactly the opposite of startLP, so now it's only function is to disable LP based hopping. Client side (local miner) LP can't be disabled atm and it's not recommended

edit: lol, I'm definitely not sure about this one, better ask c00w when we see him

paraipan

legendary

Activity: 924

Merit: 1004

Firstbits: 1pirata

Quote from: cuqa on August 16, 2011, 01:08:11 PM

i recommend to remove bitcoinpool from the rotation. its obvious that they fake their shares as decoy and then even demand a fee. also they are so unprofessional in every way.. avoid!

you have some screen capt to sustain that ?

cuqa

newbie

Activity: 40

Merit: 0

i recommend to remove bitcoinpool from the rotation. its obvious that they fake their shares as decoy and then even demand a fee. also they are so unprofessional in every way.. avoid!

deepceleron

legendary

Activity: 1512

Merit: 1036

Quote from: r2edu on August 16, 2011, 12:00:38 PM

Anyone with problems with Ozco? It doesn´t show me any "est.earnings" and i send about 800 shares!

Edit: wich one of these commands works better or are necessary with the "mine_deepbit" mode? or the three of those at the same time?

--startLP = Seeds the LP module with known pools.

This is now the default, it doesn't need to be specified at the command-line any more.

Quote from: r2edu on August 16, 2011, 12:00:38 PM

--noLP = Turns off client side longpolling*
*i don´t understand what this one does..

I believe client-side means that Bithopper doesn't push LPs to your miner with this option, your miners would just request new work when their queue is empty, which would increase stale shares.

Quote from: r2edu on August 16, 2011, 12:00:38 PM

--p2pLP = Starts up an IRC bot to validate LP based hopping

I would encourage people to set up pool worker accounts for at least a dozen pools and add them as 'info' before using this option, otherwise the information you will be sharing with others using the IRC LP info-sharing technique would be sub-optimal.

Houseonfire

full member

Activity: 129

Merit: 100

Can someone help me add in a complete addition of all the gained BTC on the top of the page up by by speed? And also the current system time. For example:

Code:

bcpool @71MHash | 1.000 BTC Earned  |  10:00PM

And by earned, i dont mean cashed out. I mean the total of what is earned so far.

r2edu

member

Activity: 68

Merit: 10

Anyone with problems with Ozco? It doesn´t show me any "est.earnings" and i send about 800 shares!

Edit: wich one of these commands works better or are necessary with the "mine_deepbit" mode? or the three of those at the same time?

--startLP = Seeds the LP module with known pools.
--noLP = Turns off client side longpolling*
--p2pLP = Starts up an IRC bot to validate LP based hopping

*i don´t understand what this one does..

ahitman

sr. member

Activity: 302

Merit: 250

Just wanted to remind people that we should be giving a donation to all the pool hopper friendly pools, I dont keep track of my efficiencies as well as I should, but because of the friendly pools I make more than I would on PPS.

How much are you guys donating? Do you think 2% is fair to pools that don't screw hoppers around?

deepceleron

legendary

Activity: 1512

Merit: 1036

Quote from: organofcorti on August 16, 2011, 06:58:55 AM

I don't have sim figures for slice vs standard yet but if you work it out scheduling, number of pools and pool size choice affect efficiency and variance as follows:

Standard scheduling has better efficiency but higher variance than slice
Larger pools have lower variance than smaller pools
Larger number of hoppable pools available lead to higher efficiency.

So a couple of choices are:

Have lots of pools including the smaller ones and use slicing to reduce variance
Only mine larger pools for better variance and use OldDefaultScheduler for best efficiency

Anyone else spot other tactics?

"Standard scheduling has better efficiency but higher variance than slice" - I think that's a misguided assumption there.

You are already greatly reducing your variance by spreading your love over many different pools. Even a 100Ghash pool is going to be solving a block in less than 24 hours on average; five that size, and you are averaging 5 smaller-payout blocks a day vs. one pool's variance. Add in hopping a "top five" pool and your daily payments are clockwork. The old scheduler wants to submit the same percentage of shares to every pool, and the same number of shares to every pool round.

Decreasing variance at the cost of mining efficiency shouldn't enter into any consideration you make. Instantaneous share value quickly drops from 13x to 1x within difficulty N/.43 shares, and a +28% per pool return estimate only happens when you start mining right at new round start. A pool has a five minute round, and now you've only put in half as many shares as you could have by sub-optimal slicing.

If there was a time-slicing option to be made at the expense of profitability (which, only as a side effect, would reduce variance), it would be to spread random shares around to all the pools you are checking for stats and LP pushes when no pool is

organofcorti

donator

Activity: 2058

Merit: 1007

Poor impulse control.

I don't have sim figures for slice vs standard yet but if you work it out scheduling, number of pools and pool size choice affect efficiency and variance as follows:

Standard scheduling has better efficiency but higher variance than slice
Larger pools have lower variance than smaller pools
Larger number of hoppable pools available lead to higher efficiency.

So a couple of choices are:

Have lots of pools including the smaller ones and use slicing to reduce variance
Only mine larger pools for better variance and use OldDefaultScheduler for best efficiency

Anyone else spot other tactics?

MaGNeT

legendary

Activity: 1526

Merit: 1002

Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na

Quote from: cirz8 on August 16, 2011, 06:12:47 AM

Isn't it just hopping between, and not doing multiple shares from multiple pools simultaneously?
At least that is how I read Keninishna's question.

Quote

best way is to always take the pool with lowest round shares.

The Pools hashrates are important variables here?

I guess it doesn't.
Low hashrate pools make variance bigger but it levels over time.

cirz8

newbie

Activity: 42

Merit: 0

Isn't it just hopping between, and not doing multiple shares from multiple pools simultaneously?
At least that is how I read Keninishna's question.

Quote

best way is to always take the pool with lowest round shares.

The Pools hashrates are important variables here?

flower1024

legendary

Activity: 1428

Merit: 1000

Quote from: Keninishna on August 16, 2011, 03:28:10 AM

how about connecting to multiple pools at the same time and then distributing the hashrate accordingly? That is pools with lower share counts get more mh/s. That would be the ideal hopper. I suppose the scheduling would be difficult to code.

there are two schedulers which actually do this. DefaultScheduler (guess what: its the default) or AltSliceScheduler (which was "invented" by me, but integrated by some other guy).

anyway: at hoppersden is a simulation software which shows clearly: any slicing does reduce variance but with a cose. your total earnings are lowered. best way is to always take the pool with lowest round shares.

Keninishna

hero member

Activity: 556

Merit: 500

how about connecting to multiple pools at the same time and then distributing the hashrate accordingly? That is pools with lower share counts get more mh/s. That would be the ideal hopper. I suppose the scheduling would be difficult to code.

Topic: bitHopper: Python Pool Hopper Proxy - page 24. (Read 355768 times)