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

1.8MH/s with 3% DOA

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?

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.

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

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.

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).

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.

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.

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.

Hard fork coming!
https://bitcointalksearch.org/topic/m.2562076

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.

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.


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.

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).

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

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

http://imgur.com/a/cfqgK

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.

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.

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.

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

I too got 106% efficiency, without jalapeno 115. Using slush to be safe for now hoping for a fix. I'll be back either way.

Many many rejects but I guess it didn't matter

http://imgur.com/EOVlFrm

Im wrong, it was skewed by 10ghs of other miners. Only 10/20ghs was jalapeno.

Don't post inaccurate information and I won't ignore it. You reference a post quoting an assertion that is clearly bullshit: "these guys claim the ASICs blow through an entire nonce range in a few ms". Why do you still expect me to waste my time with a post like this when I clearly explained it was impossible 2 posts earlier?

Now a newbie user (seems to be the same) claimed in the P2Pool thread that he got 106% efficiency after enough shares that it shouldn't be a fluke so I'll update my guide to reflect that. But I certainly won't write that BFL Asics are working properly, only that they might: between a newbie report I don't know at all and ckolivas' report there's clearly a difference in trust.
This would change if for example ckolivas confirmed that his device is working properly and he made a mistake in his earlier tests, there's a new firmware for BFL ASICs solving early problems or there are some other trusted user reporting good efficiency.
Currently I have conflicting reports with the most trusted user claiming it doesn't work properly with p2pool and a newbie I don't know claiming otherwise, like I said in my earlier post... do the math!

If I were in your shoes, I'll look for an explanation for why ckolivas' ASIC didn't work like it should or find trusted members of the forum to verify the newbie's claim. I'm only collecting information here, if there isn't enough information I can't do much.