Pages:
Author

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

member
Activity: 118
Merit: 10
BTCServ Operator
August 17, 2011, 03:39:07 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 ..
legendary
Activity: 1379
Merit: 1003
nec sine labore
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
full member
Activity: 196
Merit: 100
August 16, 2011, 09:41:01 PM
@--nolp
Old option for when client side LP was broken for some people. I think I removed it.
member
Activity: 68
Merit: 10
August 16, 2011, 02:40:53 PM
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?
newbie
Activity: 42
Merit: 0
August 16, 2011, 02:23:21 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
legendary
Activity: 924
Merit: 1004
Firstbits: 1pirata
August 16, 2011, 02:18:28 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
newbie
Activity: 40
Merit: 0
August 16, 2011, 02:10:03 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
legendary
Activity: 924
Merit: 1004
Firstbits: 1pirata
August 16, 2011, 02:00:55 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.

--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.

--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 Smiley

edit: lol, I'm definitely not sure about this one, better ask c00w when we see him
legendary
Activity: 924
Merit: 1004
Firstbits: 1pirata
August 16, 2011, 01:57:42 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 ?
newbie
Activity: 40
Merit: 0
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!
legendary
Activity: 1512
Merit: 1036
August 16, 2011, 12:36:01 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.

--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.

--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.

full member
Activity: 129
Merit: 100
August 16, 2011, 12:11:08 PM
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.
member
Activity: 68
Merit: 10
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.
--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..
sr. member
Activity: 302
Merit: 250
August 16, 2011, 10:55:32 AM
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?
legendary
Activity: 1512
Merit: 1036
August 16, 2011, 09:01:54 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
donator
Activity: 2058
Merit: 1007
Poor impulse control.
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?
legendary
Activity: 1526
Merit: 1002
Waves | 3PHMaGNeTJfqFfD4xuctgKdoxLX188QM8na
August 16, 2011, 06:26:10 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.
newbie
Activity: 42
Merit: 0
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?
legendary
Activity: 1428
Merit: 1000
August 16, 2011, 03:30:23 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.
hero member
Activity: 556
Merit: 500
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.
Pages:
Jump to: