Topic: A guide for mining efficiently on P2Pool, includes FUD repellent and FAQ - page 10. (Read 174909 times)

I'm doing 13h work sessions interleaved with long commute times and sleep right now so don't have much energy left for anything else. My first quick reading makes me think I'll have to update the guide. I'll take the time to read your post more thoroughly later this week after resting a bit.

Thanks.

Hop 1 is to my router which is <1ms and I've removed.  Hop 2 would be my DSL latency, the last hop is the latency to the IP running p2pool.

Here is a log of my shares from roughly 4:00PM central time onwards:

log:2013-06-11 16:15:59.144244 GOT SHARE! MrT bab783a2 prev 92e2927f age 2.89s
log:2013-06-11 16:51:13.272338 GOT SHARE! Pandaemonium a6d3cf72 prev 0b640f2b age 1.66s
log:2013-06-11 17:16:53.168319 GOT SHARE! Pandaemonium c2aed4f2 prev 60efa42f age 16.31s
log:2013-06-11 17:25:01.871837 GOT SHARE! Altgard b0c4413f prev ea8fd70e age 2.77s
log:2013-06-11 17:25:36.690128 GOT SHARE! Altgard 5f0dfbfc prev 4ededa38 age 21.35s
log:2013-06-11 17:27:45.292548 GOT SHARE! MrT badbc46c prev bb3fe3aa age 4.02s
log:2013-06-11 17:48:34.515212 GOT SHARE! Pandaemonium fcd0270f prev e5bb6882 age 1.12s
log:2013-06-11 17:51:26.236705 GOT SHARE! Pandaemonium 018c1e21 prev 0b9a5cfc age 9.90s
log:2013-06-11 18:20:53.325194 GOT SHARE! Altgard 748c3653 prev ef7d5934 age 2.62s
log:2013-06-11 18:31:44.319511 GOT SHARE! MrT 69a9e53d prev 24e36d6e age 3.19s
log:2013-06-11 18:39:11.042228 GOT SHARE! Brusthonin 07d7bf61 prev e53450f7 age 15.11s
log:2013-06-11 18:46:31.711466 GOT SHARE! Altgard 31b3c8dd prev bd8899a2 age 7.47s
log:2013-06-11 18:54:19.677511 GOT SHARE! Brusthonin 23a09aac prev ea2c121a age 11.17s DEAD ON ARRIVAL
log:2013-06-11 19:10:09.639655 GOT SHARE! MrT 3cfea1bc prev da6f80d3 age 4.88s DEAD ON ARRIVAL
log:2013-06-11 19:15:58.787474 GOT SHARE! Pandaemonium cf3a066f prev 6704c588 age 6.58s
log:2013-06-11 19:34:18.549763 GOT SHARE! Pandaemonium 49edf44c prev 69f93d41 age 3.59s
log:2013-06-11 19:36:24.742229 GOT SHARE! Brusthonin af01fd65 prev ba206f9c age 1.38s
log:2013-06-11 19:45:09.319976 GOT SHARE! Pandaemonium b5cdefd9 prev adeef95e age 42.91s
log:2013-06-11 19:54:32.633016 GOT SHARE! Pandaemonium 12c9a260 prev aa6e334a age 20.10s
log:2013-06-11 19:55:14.390967 GOT SHARE! MrT a04f910d prev 0188a750 age 3.51s DEAD ON ARRIVAL
log:2013-06-11 19:58:04.727155 GOT SHARE! Pandaemonium bef8f8e9 prev a93386e1 age 7.55s
log:2013-06-11 20:24:09.943406 GOT SHARE! Pandaemonium bbd76a15 prev 0ff6593f age 12.61s
log:2013-06-11 20:36:33.468076 GOT SHARE! MrT 999e3378 prev 5d842f0d age 4.39s DEAD ON ARRIVAL
log:2013-06-11 20:51:52.202080 GOT SHARE! Altgard 6f508a8b prev 4f2ccadc age 7.23s
log:2013-06-11 21:14:23.426968 GOT SHARE! Altgard 16814b6a prev f0105104 age 25.33s
log:2013-06-11 21:37:40.949988 GOT SHARE! Pandaemonium 327e8884 prev 813d06be age 5.36s
log:2013-06-11 21:37:55.679323 GOT SHARE! Pandaemonium a55a51b9 prev 0048847b age 7.25s
log:2013-06-11 22:17:32.027947 GOT SHARE! Pandaemonium 01e23d8b prev dd322bbe age 3.29s
log:2013-06-11 22:21:09.732581 GOT SHARE! Brusthonin e61cad93 prev c7d57bc7 age 12.48s
log:2013-06-11 22:45:33.521705 GOT SHARE! Pandaemonium 89a2bc49 prev da8e5127 age 2.79s
log:2013-06-11 22:47:03.131315 GOT SHARE! MrT e675329d prev 1fabbb1a age 6.71s

4 DOAs in ~30 shares.  I'm showing 2 orphans out of 90 shares total.  I'm not sure which 2 were orphaned, but I guess you could say I had 4.33 DOA/orphaned in 30 shares...  that's still >100% efficiency at all times (I don't think I've ever seen p2pool under 13.5% orphan/DOA, at least in the last 6 months).  Not 110-115%, but a couple weeks ago I also wasn't dealing with oversold bandwidth.  4.33 out of 30 would probably usually be around 105% efficiency or so.

Here's what the link looked like for those times:



This is in response to the thing about latency needing to be under 45 or whatever.  With my normal latency (180ms, and much less packetloss), I get about 5% DOA, instead of 10-15%.....

basically my argument about why the most important thing in choosing a node is the node's orphan rate..  then you look at your latency and see how much DOA that should result in...  but I don't see any reason why someone should have <100% unless they're on a satellite connection or something

I should really just be mining on a normal pool until my link is fixed, just too lazy to change everything around

ed:  added two more, link is still crap, 500ms+...  this is worst time of day actually, it'll clear up in about 2 hours

ed2: well, more like 2 1/2 hrs.  my theory is summer break

I don't: this is why I ask questions. That's called the scientific method: I make an hypothesis and try to find out if it matches reality.

No: in the guide IIRC (didn't reread myself) I say it's safe below 40ms because I had reports up to 40ms. My questions are meant to find out if I can advise people with larger latencies to use a remote node too (without hurting their income in the process).


What's that? Your DSL latency with a random host? with your P2Pool node? Your P2Pool node latency with a random host?
Seriously, if you want to tell me I'm over my head, at least try to present your case clearly: depending on which latency you are showing me my answers/questions will be totally different.

what makes you think you know the answer to everything?

you state here you have the same efficiency as I do, yet you mention something earlier to the effect of not mining on a node that has >40ms latency?

how about this (ed: consolidated into one image):



Go ahead and get 115% efficiency with 500k blocksize on that, chief

that's called oversold DSL bandwidth and sunday afternoon/evening... the last hour is called game of thrones

It's the complete opposite of what I advise to do.
I have the same efficiency you have (between 110 and 115%), with nearly 10x less connections and 2000 times more maxblocksize. What makes you thing reducing maxblocksize help your efficiency? Or are you trying to solve another problem?

well, if you include the evenings of 500ms ping times and the packetloss, it averages out to around 5-6% DOA (weekends are worse than weekdays), add in 2-3% worth of orphans and so then theoretically efficiency would be anywhere from 110-117.  (this would have p2pool as a whole ranging from 18 to 25% doa/orphans)

it's hard to say what mine is exactly, since i have multiple people using my pool.  the 108% right now is worse than normal, but that's because 2 out of the first 5 were DOA.  i reset it this morning at 300 shares, 4 orphans, and like 50 DOA.   the DOA mostly from ASIC not working properly with p2pool

theoretically with a 1 second delay, you should only get 10% DOA?  if you're mining on a european node with plenty of bandwidth that's set up properly, you shouldn't get more than 2-3% orphans.   so, you'd still have higher than 100% efficiency

i use maxblocksize 5000, but i restarted this morning to experiment with 3000.

i run p2pool with about 60 nodes added as --p2pool-node and allow another 20 outgoing and 10 incoming

Can you share the efficiency you reach with your bitcoind version and settings (if not default ones) and p2pool settings if tuned?

sure, I mine on a remote node at 200ms

my DSL alone has base latency of 35ms

ed: ok, more like 30-32ms

oh, it also gets like this in the evenings:

I hear gpu's with getwork are stable.......

No

any updates with avalon? are they suitable for p2pool?

BFL SC (ASIC) have huge latencies making them unsuitable for P2Pool mining. Guide updated.

Update: include report of a remote node with RTT between remote node and miners up to 32ms and latency >110%.

Mining on a remote node should be doable with a RTT <40ms. I'd welcome reports on efficiency with RTT>40ms (please include your configuration details).

Update: new FAQ entry for low memory (~1GB) server.

Updated the guide with latest test results with bitcoind-git (with performance patch). bitcoind-0.8.2rc3 behaves the same.

Conclusion: it's time to upgrade bitcoind and tune bitcoin.conf to get more fees out of each block. You can probably stop worrying about high getblocktemplate latencies too (see the guide itself for details).

Given the extreme bitcoind tunings seen in the P2Pool thread that would hurt everyone's income I added a more detailed bitcoind tuning guide designed to give optimal getblocktemplate latencies.

Fixed a typo in the guide, the bitcoin P2P port is 8333 not 8332, if you setup QoS with high priority for port 8332, you should change it to 8333.

Updated the Avalon section with suggestions. There's no documented way to configure Avalon for P2Pool properly, but there have been partial reports. If you have Avalon(s) please report your success/failures with P2Pool here.

with intensity 7 i mine 575 mh, instead with int 9 only 550

above 9 nothing change, the max is still 575

The cgminer's README explains all these values. It's surprising that a lower intensity is better on a 7950, if your card behaves this way, you can lower the gpu-dyninterval value. Assuming the system is dedicated to mining, each time it's halved the intensity should be reduced by 1.

what this line really do? what is the benefit?
-Q 0 -g 1 --intensity d --gpu-dyninterval 50

with this line, my intensity is set to 9, but i found that intensity 7 is the best for 7950