A guide for mining efficiently on P2Pool, includes FUD repellent and FAQ

[gyverlb]

Here are some screen shots of my P2Pool and cgminer output if they help:

http://imgur.com/a/cfqgK

do you have to use stratum?   it has some 1/2 second delay or so for me

it looks like whatever you're using has 1500-2000ms latency.  so we'll be optimistic and consider that 15% DOA.     now, can you set up your pool so you have 5% or less orphans?  probably not with 6 outgoing connections and 0 incoming

i don't understand why people run pools locally when they'd be better off using a remote server.  i ran mine locally for about 2 days

zvs, your experience is only showing what works for you and may not apply to others, it must be compared to other results to be meaningful.

Based on what we already know, the right choice depends on what your options are and is a bit difficult to find: by moving the node to a remote server you save on the bandwidth used on your local connection (miner <-> node traffic is very low compared to node <-> P2Pool network traffic) but you may add a bit of latency to your setup (miner <-> P2Pool network traffic is routed through the remote host you choose).

If you don't have any local bandwidth problems, using a remote node adds latency to your setup. That said if you chose the remote node right this additional latency might be negligible and even be compensated by other gains. For example if your remote node has more CPU power available for bitcoind and P2Pool you can get an advantage there.

If you have local bandwidth problems, using a remote node might be a safe bet, but using a public node will either decrease the fees P2Pool users get or add latency. The best solution then is a dedicated node (until there's a fix for the high latencies with multi-payout addresses on a single node case).

[gyverlb]

Guide updated for conflicting reports about BFL ASICs and one success report for ASICMINER Block Erupter blades.

Hi, I'm the newbie mentioned.  Thanks for updating the guide with my findings.  Hopefully more users will try their BFL ASICs on P2Pool as they get them and we can get more evidence either way.

Hope so, sorry if I look paranoid, but it seems that sockpuppetting is an official bitcointalk sport now and there's big money involved: if a vendor looks bad on P2Pool even if we aren't a big pool it probably can reflect on sales.

FWIW my local DOA rate is high (Local rate: 5.64GH/s (22% DOA) Expected time to share: 0.206 hours) but my efficiency has been fine (Shares: 43 total (3 orphaned, 3 dead) Efficiency: 105.6%).  The only change I have done over stock cgminer is I run it with username/6000 to increase the share difficulty.  This was suggested by a user on the BFL forums.

If you have any questions or want me to share anymore information I'd be happy to.

Hum, are you sure you changed your share difficulty in the screenshots you published? Your expected share interval doesn't match a 6000 difficulty with a 5.5GH/s device but matches the current ~1000 difficulty.
43 shares isn't bad for estimating efficiency, but 100 would be better (the confidence interval is still 89-115 in your screenshot). With your hashrate, waiting for one or 2 whole days instead of ~10 hours would help estimate your actual efficiency.

[gyverlb]

I'm sorry I didn't do the digging to figure it out for you.  It appears it is raising the share difficulty that saves your efficiency.  I just figured you were the expert and could figure it out easier.  Sorry for wasting your time.  I clearly keyed in on an incorrect statement, which caused you to dismiss everything I had to say.

Sorry if I look a bit harsh, but I don't spend much time on bitcointalk right now: I have a lot of work currently and I'm slowly recovering from a broken back at the same time so if I even suspect I won't find useful information I don't dig to save time.
The meds I take may not help either: they are known to have several side effects on the mood and short-temper is one (I may be predisposed for this one...).

Raising share difficulty may not be the solution: as I wrote in the previous post the published results match a configuration with standard share difficulty.

[bitpop]

Hard fork coming!
https://bitcointalk.org/index.php?topic=18313.msg2562076#msg2562076

[notme]

I'm sorry I didn't do the digging to figure it out for you.  It appears it is raising the share difficulty that saves your efficiency.  I just figured you were the expert and could figure it out easier.  Sorry for wasting your time.  I clearly keyed in on an incorrect statement, which caused you to dismiss everything I had to say.

Sorry if I look a bit harsh, but I don't spend much time on bitcointalk right now: I have a lot of work currently and I'm slowly recovering from a broken back at the same time so if I even suspect I won't find useful information I don't dig to save time.
The meds I take may not help either: they are known to have several side effects on the mood and short-temper is one (I may be predisposed for this one...).

Raising share difficulty may not be the solution: as I wrote in the previous post the published results match a configuration with standard share difficulty.

I'm sorry to hear that.  I truly wish you have a speedy recovery.  Thank you for updating the guide to be less discouraging for BFL owners.  P2Pool is experiencing very long block times and if BFL hardware can potentially help with that we should certainly admit it is complicated, but not actively discourage them from trying.

[maqifrnswa]

Re: p2pool and BFL SCs

There appears to have been a recent change to the firmware from one job per board to one job per chip
https://forums.butterflylabs.com/announcements/692-bfl-asic-status-3.html#post43041

They claim, "This has fixed a lot of the latency issues we were experiencing with the early firmware."

jalepenos only have 2 chips, so at best this is a factor of 2...

Anyways, the new p2pool release should help a bit too.

[gyverlb]

Future changes will indeed be a game-changer for miners with high latencies (mainly Avalon and BFL ASICs).

If you read this and are/were discouraged by low Avalon or BFL efficiency, please watch this thread and/or the main P2Pool thread to be notified when the fork becomes active, testing P2Pool after that will probably change your results for the better.

[gyverlb]

Re: p2pool and BFL SCs

There appears to have been a recent change to the firmware from one job per board to one job per chip
https://forums.butterflylabs.com/announcements/692-bfl-asic-status-3.html#post43041

They claim, "This has fixed a lot of the latency issues we were experiencing with the early firmware."

jalepenos only have 2 chips, so at best this is a factor of 2...

Anyways, the new p2pool release should help a bit too.

Does not compute in our case. If you suppose you can't interrupt a job, having one per board is better as it finishes faster.

So either Josh didn't understand at all and the switch was from one per chip to one per board (which would be good for P2Pool) or they solved a problem completely different from what was spotted by ckolivas (and it's probably bad for P2Pool, you might not want to update your firmware unless you can downgrade it later).

[notme]

Re: p2pool and BFL SCs

There appears to have been a recent change to the firmware from one job per board to one job per chip
https://forums.butterflylabs.com/announcements/692-bfl-asic-status-3.html#post43041

They claim, "This has fixed a lot of the latency issues we were experiencing with the early firmware."

jalepenos only have 2 chips, so at best this is a factor of 2...

Anyways, the new p2pool release should help a bit too.

Does not compute in our case. If you suppose you can't interrupt a job, having one per board is better as it finishes faster.

So either Josh didn't understand at all and the switch was from one per chip to one per board (which would be good for P2Pool) or they solved a problem completely different from what was spotted by ckolivas (and it's probably bad for P2Pool, you might not want to update your firmware unless you can downgrade it later).

EDIT: Come to think of it, you are probably right since the chips should compute nonce ranges in very close to the same amount of time, so I'm happy if you ignore this.  I'll just post in case anyone else has a similar objection.

Are you sure about that?  Needing to reset work is a stochastic event and thus each chip will be somewhere in the range from just starting to almost done.  You are very clearly right if all chips are synchronized, but I'm not sure they are.  I'm a bit weak on stats, so I'm not sure here.  I could probably review a proof, but if I had to prove it either way myself, I would probably just do a monte carlo simulation.

[daemondazz]

It would be a maximum of twice as responsive for the jallies, assuming each chip starts work 180 degrees from each other.

[notme]

It would be a maximum of twice as responsive for the jallies, assuming each chip starts work 180 degrees from each other.

And potentially much better with the rigs with higher chip counts, but in practice they would likely be fairly close to synced, so the improvement would be small if it even surpassed the extra overhead.

[Mr. Jinx]

I have a question about DOA's and efficiency.

With p2pool scrypt-mining (ltc) I get a local rate of 2MH/s with 20% DOA. This is with intensity in cgminer set at 20.
If I lower intensity to 17, the local rate drops to 1.8MH/s with DOA 3%.
In both cases, efficiency is 100%+

Which one is better, 2MH/s with 20% DOA, or 1.8MH/s with 3% DOA?

[bitpop]

1.8MH/s with 3% DOA

[daemondazz]

Which one is better, 2MH/s with 20% DOA, or 1.8MH/s with 3% DOA?

The math is pretty simple:

2MH/s - 20% = 1.6MH/s effective
1.8MH/s - 3% = 1.747MH/s effective

[gyverlb]

Which one is better, 2MH/s with 20% DOA, or 1.8MH/s with 3% DOA?

The math is pretty simple:

2MH/s - 20% = 1.6MH/s effective
1.8MH/s - 3% = 1.747MH/s effective

The OP on this particular subject should do the math for intensity 18 and 19 too. I'll guesstimate that 19 should be the right spot.

Edit: BTW, as soon as the P2Pool network you are on switch to a 30s block interval (BTC and LTC will) all these computations will have to be done again.

[Mr. Jinx]

Thanks for clarifying! There was some confusion in this thread where someone said DOA's are not wasted work and can still payout.

[maqifrnswa]

I have a question about DOA's and efficiency.

With p2pool scrypt-mining (ltc) I get a local rate of 2MH/s with 20% DOA. This is with intensity in cgminer set at 20.
If I lower intensity to 17, the local rate drops to 1.8MH/s with DOA 3%.
In both cases, efficiency is 100%+

Which one is better, 2MH/s with 20% DOA, or 1.8MH/s with 3% DOA?

DOA shares do payout and don't necessarily negatively affect payout (as long as you have < average DOA) but in the case of a difference of 3% and 20% - that should affect payout.

In both cases efficiency is > 100%, but were they the same?

Please correct me if I'm wrong, but shouldn't the real calculation be:

2MH/s x efficiency = effective rate
1.8MH/s x efficiency = effective rate

Not
MH/s - doa% = effective rate

[gyverlb]

Thanks for clarifying! There was some confusion in this thread where someone said DOA's are not wasted work and can still payout.

DOAs aren't wasted work and can still generate a valid block which would pay everyone.

However DOAs aren't used to compute the share of a miner in the payouts, only shared accepted in the sharechain. This is explained in more details in the original post of this thread.

[abbeytim]

hi I have a question p2pool is sending my miner diff 1 shares and I want it to send the p2pool diff


now somewhere I read you could put /1000 next to the miners name so I tried user/1000 and its still getting diff 1 shares from p2pool

[gyverlb]

hi I have a question p2pool is sending my miner diff 1 shares and I want it to send the p2pool diff


now somewhere I read you could put /1000 next to the miners name so I tried user/1000 and its still getting diff 1 shares from p2pool

This is a question better asked in the main P2Pool thread (see first post for a link).