 Show Posts
|
|
Pages: [1]
|
You should lower blockprioritysize and increase mintxfee/minrelaytxfee a bit more. Blockprioritysize=500000 is way too much, you are allocating 500 kB to free transactions!
Oops. I misunderstood what blockprioritysize meant, thanks! |
|
|
|
FWIW, adding this to the bottom of my bitcoind.conf fixed the massive recent latency issues. Now, I'm not sure if this is the best-for-the-network settings, but it certainly fixed my latency. I increased the relay fee minimum some, and I think most importantly I doubled the time it takes for txns to become high priority. Of course, that part is only a temporary fix... EDIT: This only helped for a couple hours....  blockprioritysize=500000 mintxfee =0.0002 minrelaytxfee=0.0002 |
|
|
|
cgminer: [2012-02-22 08:44:00] Accepted 00000000.1c5c9ad1.2ea00ae6 GPU 0 thread 0
[2012-02-22 08:44:06] Pool 0 not providing work fast enough
[2012-02-22 08:45:06] Pool 0 http://127.0.0.1:9332 not responding!
I used to get that on older versions of cgminer - what version are you using / try updating to 2.2.7? |
|
|
|
|
9f55b0458c8064ca899b0992500802e52dee37eb fixed things for me, thanks!
|
|
|
|
Just updated (0ad46ea0be3cae43184fef40d34469880d86f02e -> 5e04126742449ed026b2ea940f33a19656de6a6d), started getting a new error I haven't seen before: 2012-02-22 08:55:57.536599 > Traceback (most recent call last):
2012-02-22 08:55:57.536700 > File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 823, in _inlineCallbacks
2012-02-22 08:55:57.536739 > result = g.send(result)
2012-02-22 08:55:57.536774 > File "/home/.../p2pool/p2pool/util/jsonrpc.py", line 105, in render_POST
2012-02-22 08:55:57.536808 > result = yield method_meth(request, *params)
2012-02-22 08:55:57.536842 > File "/home/.../p2pool/p2pool/bitcoin/worker_interface.py", line 21, in rpc_getwork
2012-02-22 08:55:57.536877 > return self.parent._getwork(request, data, long_poll=self.long_poll)
2012-02-22 08:55:57.536911 > File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 944, in unwindGenerator
2012-02-22 08:55:57.536960 > return _inlineCallbacks(None, f(*args, **kwargs), Deferred())
2012-02-22 08:55:57.536994 > --- <exception caught here> ---
2012-02-22 08:55:57.537028 > File "/usr/lib/python2.6/dist-packages/twisted/internet/defer.py", line 823, in _inlineCallbacks
2012-02-22 08:55:57.537062 > result = g.send(result)
2012-02-22 08:55:57.537095 > File "/home/.../p2pool/p2pool/bitcoin/worker_interface.py", line 63, in _getwork
2012-02-22 08:55:57.537129 > defer.returnValue(self.merkle_root_to_handler[header['merkle_root']](header, request))
2012-02-22 08:55:57.537164 > File "/home/.../p2pool/p2pool/main.py", line 652, in got_response
2012-02-22 08:55:57.537197 > reactor.callLater(1, grapher.add_localrate_point, bitcoin_data.target_to_average_attempts(target), not on_time)
2012-02-22 08:55:57.537232 > exceptions.NameError: global name 'grapher' is not defined
I'm running python 2.6.5 (Ubuntu 10.04 LTS). P2Pool continues to run but dumps a lot of these, and appears to be failing to receive work from the worker. Not sure if it's failing to accept just the low-difficulty work or if shares will be missed too - haven't let it run long enough to "probably" have missed a share. The data/rrd.poolrate and rrd.stalerate files seem to be udpated, but not the rrd.local*rate files. |
|
|
|
But how do I tune my miner to maxamize shares and payout? Increase I to increase hash rate and U (shares/min) or decrease I to increase own efficiency?
I find that lower stales is better for payout than higher U/hashrate. AFAIK it depends on your exact hardware and how much of a difference it makes. Basically, you need to look at how U changes compared to how stales change. If U increases more than total dead+orphan (per min) then I think it makes sense for you to go with a higher U because total accepted (by p2pool, non-dead non-orphan) shares/min is higher. But I think most people find that U increases 5-10% for stales increasing 10-20%, meaning that overall p2pool good shares per hour is decreased by increasing I. In summary: YMMV. (I use dynamic I and haven't found enough difference to matter with either higher or lower I.) Also, keep in mind that statistics for <100 p2pool shares is unlikely to be useful when comparing these relatively small changes. |
|
|
|
Strange things going on here:
The windows exe (p2pool_0.8.1_c7feb00.zip) works as expected, about one share per hour or so.
Today I tried installing Python 2.7 and using the source (forrestv-p2pool-release-0.8.1-71-gfff1dd9.zip).
Now cgminer 2.1.2 suddenly finds about 3 or 4 shares per minute.
p2pool is showing this after about 13 minutes and 45 shares:
Pool: 109GH/s in 25941 shares (25945/25945 verified) Recent: 0.00% >0H/s Shares: 0 (0 orphan, 0 dead) Peers: 10 (0 incoming)
I get similar behavior - some (most) of the "accepted" shares don't seem to meet the difficulty requirement in p2pool I think. But wait enough and you'll get "true" accepted shares in p2pool (in my experience).
Can you explain this more. I get a higher hashrate and U with a higher intensity, but also a lower own efficiency (from more stales). What is a better indicator of paid work, p2pool own efficiency or cgminer U (which I thought was accepted shares/min)?
The best indicators of paid work are Shares: X and Payout if block: BTC from p2pool. Shares is how many shares you have accepted to the pool (minus orphan and dead), payout is the payout to you if your node is the one to find a block. Most of your payouts will be this - 0.5% (the bonus given to the finder of a "true" block). If I've made any mistakes, experts please correct! |
|
|
|
|
Might be because I have a static IP - back up to 25 peers as of now. Well, I'm not contributing (much) hashing power but at least I'm giving a little network stability?
|
|
|
|
|
I currently have 30 peers reported. Just reset to update to the latest from git - hit 10 peers quickly, after couple minutes it's up to 13. So it CAN happen...
|
|
|
|
|
will try out the poclbm branch... (edit: results below)
Seems to work fine, still a significantly higher stale proportion (~.5) than median but I suppose someone has to get higher than median for it to be the median... Set on a high target fps as recommended but haven't had time to experiment with exactly how this changes things.
cgminer 1.5.8 (the last version that I got working correctly) got ~.7, so it's an improvement.
|
|
|
|
|
cgminer 1.5.8 seems to work for me but not, as you note, the newer versions. I was getting very low stale rates (usually around .12-.18) until recently, where I'm getting around .4 rather than the ~.2 median - not sure what changed but at least it still works?
|
|
|
|
|
I'm just trying to provide some feedback on the p2pool project. I've got everything up and running but occasionally see a problem that hasn't been widely encountered. Don't really have anything to say on the newbie boards so haven't, except for one on the introduce-self to unlock a PM to the developer of p2pool (pending). Thanks!
|
|
|
|
|
just tryin' to put my radeons to good use trying out p2pool and wanted to post feedback. Can't until I escape newbie board though! So: hi!
|
|
|
|
|
