pushpool - open source pool software

[jgarzik]

for example, multiple pushpools and multiple bitcoind?  multiple pushpools and one bitcoind?  other? 

Multiple pushpoold's and multiple bitcoind's.  The only question is about database scaling...

[1713907857]

1713907857

[1713907857]

1713907857

[jgarzik]

Version 0.5 released.

Changes:

Jeff Garzik (2):
      applog: fix memory leak; check asprintf() return value
      Version 0.5.

Joerie de Gram (1):
      Make ntime rolling support configurable

Luke Dashjr (1):
      Bugfix: libraries must be in LDADD, not LDFLAGS

MtRed (1):
      memcached_get & memcached_set key length is off by 1. Double null make get

Shane Wegner (1):
      Output times on STDERR in human readable format.

[Wuked]

Just to warn you that the 0.5 build in the .tar.gz file doesn't work correctly.

Ius has a fix, I think it's been pushed to github but I'm not 100% sure.

[ius]

To clarify; the standard error logging option (-E) is broken in 0.5 Trivial fix is submitted as a pull request: https://github.com/jgarzik/pushpool/pull/27

[Crs]

question:does pushpool work with the namecoin chain ?

[redhatzero]

Hi, is it possible that even if upstream_result is Y, that it's an invalid share?

I have such a case, that upstream_result is Y but nothing shows up in listtransactions :/

[davout]

Hi, is it possible that even if upstream_result is Y, that it's an invalid share?

I have such a case, that upstream_result is Y but nothing shows up in listtransactions :/

I suggest to not rely on listtransactions to monitor generated blocks.

The approach I use is the following :
 - track shares with upstream_result = 'Y'
 - calculate block hash directly from the share result (block header)
 - use the getblockbyhash RPC call to do the tracking and validate there's actually a block that has been generated

I think it's a much cleaner approach

[redhatzero]

thanks davout, i'll give that a try

[eleuthria]

Just to help anybody out there who is struggling with pushpool scaling like BTC Guild has:

The major bottleneck that you'll run into assuming your hardware is good is going to be the communications between bitcoind and pushpoold.  Every getwork and sendresult request is opening a new local socket for the communication, eventually running the server out of open sockets due to a huge number of TIME_WAITs.  Around 300-400 GH/sec, depending on the server TCP settings, you will hit a point where there are no ports available to open a new local socket.

Changing your servers tcp settings in /proc/sys/net/ipv4/ to the following can help, but its only a bandaid fix, you'll still run into issues:
  tcp_fin_timeout   - Changing this to a much lower value, such as 5.
  ip_local_port_range  -  Changing this to a setting such as 10000 65000

My C/C++ skills for networking are pretty rusty, so I haven't yet been able to come up with a fix to get pushpoold/bitcoind to reuse sockets rather than open new ones yet.

[kripz]

Is it possible to set up a local server to connect to an existing pool? I'll then connect my miners to the local server, Dial up is a bitch...

[redhatzero]

more or less replying to eleuthria:

before I've updated to 0.5 I didn't have problems with the connections. But since I've updated, I'm running into these problems (With about the same GHash rate...)

[somebadger]

question:does pushpool work with the namecoin chain ?

yes it does, just interface with namecoind rpc

[nodemaster]

Hi all,

I have no problem with TIME_WAITs at the moment. But I have a massive problem with CLOSE_WAITs from pushpoold:



If I restart pushpoold they vanish. I never saw the amount decreasing during normal operations. I'm using the current git Version. Does anybody know how to mitigate this issue?

[Inaba]

blkmond will close those.  It's not a great design decision that it requires blckmond to close the tcp due to the SIG USR1 it receives when there's an LP.  If blkmond fails you will eventually have too many open connections.

[nodemaster]

blkmond will close those.  It's not a great design decision that it requires blckmond to close the tcp due to the SIG USR1 it receives when there's an LP.  If blkmond fails you will eventually have too many open connections.

Thank you for your answer. This explains a bit BTW I have blkmond running by fire and forget. I just start it with the configuration file as parameter and send it to the background using the job control, pipeing its output to the bit bucket. Is this the correct usage? I feel it should be a daemon which need to be restartet every time pushpoold is restartet (as it need to know the new PID)?! Or is it reading the PID from the file each loop?  However embedding it into a init-Skript is not that easy (due to the output) und thus I feel it is not intended to be startet as deamon. Am I right?

[Inaba]

Umm, I can't recall for sure, but I'm 99% positive it needs to be restarted when PP is restarted and gets a new PID.

[MrSam]

Please check my fork of pushpool for modified example-config and example db:
https://github.com/jine/pushpool



Regards, Jim

I changed you insert to delayed inserts

[d3c0n808]

I've been running pushpoold on my box for sometime and about every 12 hours of running or so it begins to error the error log says WARN too many open files anyone else run into any similar issues?

[Jine]

Modifiy ulimit -n

[Vladimir]

Anyone got it to compile on freebsd yet? Any pointers?