bitHopper: Python Pool Hopper Proxy - page 147.

macboy80

member

Activity: 102

Merit: 10

Quote from: EskimoBob on July 26, 2011, 02:14:26 PM

Code:

[22:02:43] Error in pool api for nofeemining
[22:02:45] Error in pool api for bitclockers

In localhost:8337/stats, both those jump to 10000000000 and obviously another pool is selected

When shares can be submitted just fine but the pools web page is not answering in a split second, scripts starts a completely unnecessary hop from a perfectly working pool. Can you calm this down a bit?

Cheers!

+1

Sukrim

legendary

Activity: 2618

Merit: 1007

Quote from: bb on July 26, 2011, 10:36:12 AM

Quote from: EskimoBob on July 26, 2011, 10:17:20 AM

*snip*

What do you guys think about it? I'll use it for sure.

This would totally invalidate the whole effort of pool hopping and roughly be the equivalent of just mining at the same pool for a longer period of time.

Not if we use only pools as backup that have hopping proof algorithms. It just lowers variance to mine at one of the 3 *PPS pools (ars, eligius, bitpit), in the longer run it does NOT hurt anyone to mine at PPLNS pools or others instead as backup.

After all, I still have a lot of accounts on a lot of pools where I could mine instead when no Prop. Pool is "hot" right now.

If we use "highest number of round shares" as measurement, we will help these pools even more, as many less educated miners tend to run away once rounds take longer and we can provide a quite high hash rate with the users of this program (~100 GH/s). Also we have more backup pools.

I personally would enable any pool with automatic + full 8-digit payouts (I hate checking + logging in to a dozen webpages every few days) as backup pool.

EskimoBob

legendary

Activity: 910

Merit: 1000

Quality Printing Services by Federal Reserve Bank

Code:

[22:02:43] Error in pool api for nofeemining
[22:02:45] Error in pool api for bitclockers

In localhost:8337/stats, both those jump to 10000000000 and obviously another pool is selected

When shares can be submitted just fine but the pools web page is not answering in a split second, scripts starts a completely unnecessary hop from a perfectly working pool. Can you calm this down a bit?

Cheers!

c00w

full member

Activity: 196

Merit: 100

1)beef errors wtih stats.py?
Yeah turning on bitclockers screwed things up. Its fixed in the latest version.

2) mine_slush?
I thik I accidentally made it jump at 1.6 instead of .1. Oops. I'll fix that.

macboy80

member

Activity: 102

Merit: 10

Quote from: hawks5999 on July 26, 2011, 01:59:44 PM

is mtred IP banning now? or is it just me?

I'm still mining away...

EDIT: MtRed timed out for me now.

Tmoney

newbie

Activity: 40

Merit: 0

Quote from: hawks5999 on July 26, 2011, 01:59:44 PM

is mtred IP banning now? or is it just me?

I'm also banned.

hawks5999

full member

Activity: 168

Merit: 100

is mtred IP banning now? or is it just me?

macboy80

member

Activity: 102

Merit: 10

Quote from: joulesbeef on July 26, 2011, 08:50:56 AM

Quote

could you also add my pool-stats graph

Pict looks cool.. did you change the addy to reach the webpage?... I've tried all I can think of to reach it.

c00w.. i get this when I start up yours.. probably something I did.. do you have an idea?

[09:50:43] Database Setup

Code:

Unhandled error in Deferred:
Unhandled Error
Traceback (most recent call last):
  File "D:\Users\joulesbeef\Desktop\c00w-bitHopper-july24th\bitHopper.py", line
425, in 
    main()
  File "D:\Users\joulesbeef\Desktop\c00w-bitHopper-july24th\bitHopper.py", line
420, in main
    stats_call.start(117*4)
  File "D:\Python27\lib\site-packages\twisted\internet\task.py", line 163, in st
art
    self()
  File "D:\Python27\lib\site-packages\twisted\internet\task.py", line 194, in __
call__
    d = defer.maybeDeferred(self.f, *self.a, **self.kw)
---  ---
  File "D:\Python27\lib\site-packages\twisted\internet\defer.py", line 133, in m
aybeDeferred
    result = f(*args, **kw)
  File "D:\Users\joulesbeef\Desktop\c00w-bitHopper-july24th\stats.py", line 106,
 in update_api_stats
    d = work.get(self.bitHopper.json_agent,info['user_api_address'])
exceptions.NameError: global name 'work' is not defined

@ JB: That is the same error I got yesterday. Issue #45 on GitHub. I believe it happens when you enable/mine bitclockers. c00w had me fixed in the latest commit.

ryouiki

newbie

Activity: 33

Merit: 0

Quote from: hawks5999 on July 26, 2011, 01:23:06 PM

Quote from: ed64 on July 26, 2011, 12:48:44 PM

Nice to know... which fork do you think has the most promise? I'm divided where I should do some of my hacking...

I tried Ryouiki's latest changes and just based on a few hours of mining, the dynamic penalty thing isn't working out too well for me. Stays on a pool too long in some cases...

agreed. Need a "Use Dynamic Penalty []" option somewhere.

from my tests,

- round time based selection enhances efficiency ~10%
- multi-pass selection enhances efficiency ~ 15%
- dynamic penalty : ~2%

efficiency gain with dynamic penalty is marginal, but I think it is worth.
btw, current fork is tuned to find maximal profit without hopping frequently
i plan to research more aggressive (frequent) hopping algorithms next week.

hawks5999

full member

Activity: 168

Merit: 100

Quote from: ed64 on July 26, 2011, 12:48:44 PM

Nice to know... which fork do you think has the most promise? I'm divided where I should do some of my hacking...

I tried Ryouiki's latest changes and just based on a few hours of mining, the dynamic penalty thing isn't working out too well for me. Stays on a pool too long in some cases...

agreed. Need a "Use Dynamic Penalty []" option somewhere.

ed64

newbie

Activity: 42

Merit: 0

Nice to know... which fork do you think has the most promise? I'm divided where I should do some of my hacking...

I tried Ryouiki's latest changes and just based on a few hours of mining, the dynamic penalty thing isn't working out too well for me. Stays on a pool too long in some cases...

joulesbeef

sr. member

Activity: 476

Merit: 250

moOo

>would be nice if everybody just take a look in the code before using it

I did .. some of us arent coders.. wow crazy. I saw reference to index.html in bithopper.py but couldnt see the whole path.. maybe it is elsewhere.. i looked through a few of the pys but not all.

>but anyway: you should not use this fork.

it seemed a bit dated, but I liked the web stats and wanted to check it out.

>i'll integrate the stats graph in c00w's version later this evening

kick ass.. it looked nice.

>slice algorithm already available in another fork.

yeah, echiu64, I try all you forkers. }:=D

sorry to see stop adding, but thanks for the addons.

flower1024

legendary

Activity: 1428

Merit: 1000

would be nice if everybody just take a look in the code before using it

but anyway: you should not use this fork.

i will not continue development
i'll integrate the stats graph in c00w's version later this evening
slice algorithm already available in another fork.

and c00w's a much better py dev than me Cheesy

joulesbeef

sr. member

Activity: 476

Merit: 250

moOo

Quote

(yes i changed the location, sorry. link ist http:///info

LOL it would be nice if all you forkers would agree on the small things.

Wink

farfiman

legendary

Activity: 1449

Merit: 1001

Quote from: EskimoBob on July 26, 2011, 10:17:20 AM

This is from:
http://forum.bitcoin.org/index.php?topic=31400.msg397680#msg397680

Quote from: gnaget on July 25, 2011, 12:41:57 PM

Quote from: enmaku on July 25, 2011, 12:15:32 PM

Quote from: EskimoBob on July 25, 2011, 11:21:15 AM

What if pool hoppers put a positive spin to the the game?

Les say, you hop to pool X and then you jump to next, when you are at your N rate from difficulty and so on.
What if you hop back to the pool X, when they are in trouble and are cranking at 50+ h block? Jump in, help them out, suck some honey from the first shares and move on. But do not forget to hop back, when they actually need you,
For example, look at the Triplemining. 52 hours and counting, 3 855 573 share and no end is sight.

Poolhoppers can bring 50-80 GH/s power to any pool.
Pool-hoppers, its time to give something back to a small pool. It will be really cool and I can bet, most small pools will make the real time stats etc available to you

and you probably end up earning more than now.

Cheers!

This is actually a pretty decent idea. The pool-hopping scripts I've played with so far all have "backup" pools that are mined when none of your other pools are under the magic 43% mark. I doubt it would be that tough to change the logic up a bit to mine whatever pool has the highest share count during these times instead and I'm sure it would make us all the more welcome at already hopper-friendly pools (or pools which are undecided). I'd be happy to see such a change. I'll see if I can bash it out myself and I'll also suggest it to those who control the code for the major projects.

Even I can get behind this idea. I'd be more than willing to donate some time to the development of it. Question is, would people use it?

What do you guys think about it? I'll use it for sure.

Great Idea , The small pools that are the main "targets" for the hopping could use that kind of help and it would shine some positive light on the hoppers ( for the ones that actually care).

bb

member

Activity: 84

Merit: 10

Quote from: EskimoBob on July 26, 2011, 10:17:20 AM

*snip*

What do you guys think about it? I'll use it for sure.

This would totally invalidate the whole effort of pool hopping and roughly be the equivalent of just mining at the same pool for a longer period of time.

EskimoBob

legendary

Activity: 910

Merit: 1000

Quality Printing Services by Federal Reserve Bank

This is from:
http://forum.bitcoin.org/index.php?topic=31400.msg397680#msg397680

Quote from: gnaget on July 25, 2011, 12:41:57 PM

Quote from: enmaku on July 25, 2011, 12:15:32 PM

Quote from: EskimoBob on July 25, 2011, 11:21:15 AM

What if pool hoppers put a positive spin to the the game?

Les say, you hop to pool X and then you jump to next, when you are at your N rate from difficulty and so on.
What if you hop back to the pool X, when they are in trouble and are cranking at 50+ h block? Jump in, help them out, suck some honey from the first shares and move on. But do not forget to hop back, when they actually need you,
For example, look at the Triplemining. 52 hours and counting, 3 855 573 share and no end is sight.

Poolhoppers can bring 50-80 GH/s power to any pool.
Pool-hoppers, its time to give something back to a small pool. It will be really cool and I can bet, most small pools will make the real time stats etc available to you

and you probably end up earning more than now.

Cheers!

This is actually a pretty decent idea. The pool-hopping scripts I've played with so far all have "backup" pools that are mined when none of your other pools are under the magic 43% mark. I doubt it would be that tough to change the logic up a bit to mine whatever pool has the highest share count during these times instead and I'm sure it would make us all the more welcome at already hopper-friendly pools (or pools which are undecided). I'd be happy to see such a change. I'll see if I can bash it out myself and I'll also suggest it to those who control the code for the major projects.

Even I can get behind this idea. I'd be more than willing to donate some time to the development of it. Question is, would people use it?

What do you guys think about it? I'll use it for sure.

farfiman

legendary

Activity: 1449

Merit: 1001

Quote from: Clipse on July 26, 2011, 09:50:26 AM

Quote from: farfiman on July 26, 2011, 09:39:49 AM

Quote from: Clipse on July 26, 2011, 09:33:19 AM

I dont really believe its just after a new block, your server seems to simply not handle alot of traffic.

Right now I cant even with normal miner hold a steady connection for more than 2minutes before it times out and retries. Ive tested this from a server in uk and us.

So i hope this is a known issue and gets resolved as you mentioned about some update to the system coming.

it isn't my pool I'm just a miner like everyone else.

Ok but thats still not the situation, I keep dropping no matter what from various locations that Ive tested this on. Its definitely not phoenix miner(and just your pool) or the connection from the US and UK datacentre.

So as for the server issues, I think its a general server problem even at current load, around 20gh I could keep a connection. This brings me to another point, if the server cant handle 60-90Gh without dropping and timing out, how does nofeemining plan to get normal users to dedicated their gpu's when the server cant scale from absolutely minimal usage.

Wait till next week... New system should be in place ( I hope....) and who knows , maybe a new payment system...

Clipse

hero member

Activity: 504

Merit: 502

Quote from: farfiman on July 26, 2011, 09:39:49 AM

Quote from: Clipse on July 26, 2011, 09:33:19 AM

I dont really believe its just after a new block, your server seems to simply not handle alot of traffic.

Right now I cant even with normal miner hold a steady connection for more than 2minutes before it times out and retries. Ive tested this from a server in uk and us.

So i hope this is a known issue and gets resolved as you mentioned about some update to the system coming.

In general 1 min after a block is found... the speed shoots up from about 20-30 ( our usual speed) to about 60-90 and yes it is very hard to connect at those speeds. after we get to 1M shares speed drops ....and connection is stable

edit: and just to be clear... it isn't my pool I'm just a miner like everyone else.

Ok but thats still not the situation, I keep dropping no matter what from various locations that Ive tested this on. Its definitely not phoenix miner(and just your pool) or the connection from the US and UK datacentre.

So as for the server issues, I think its a general server problem even at current load, around 20gh I could keep a connection. This brings me to another point, if the server cant handle 60-90Gh without dropping and timing out, how does nofeemining plan to get normal users to dedicated their gpu's when the server cant scale from absolutely minimal usage.

farfiman

legendary

Activity: 1449

Merit: 1001

Quote from: Clipse on July 26, 2011, 09:33:19 AM

I dont really believe its just after a new block, your server seems to simply not handle alot of traffic.

Right now I cant even with normal miner hold a steady connection for more than 2minutes before it times out and retries. Ive tested this from a server in uk and us.

So i hope this is a known issue and gets resolved as you mentioned about some update to the system coming.

In general 1 min after a block is found... the speed shoots up from about 20-30 ( our usual speed) to about 60-90 and yes it is very hard to connect at those speeds. after we get to 1M shares speed drops ....and connection is stable

edit: and just to be clear... it isn't my pool I'm just a miner like everyone else.

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