Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool - page 575. (Read 2591920 times)

P2Pool should establish outgoing connections right away and you should get incoming connections very slowly. If you don't get any stable established connections just after P2Pool is started, something (a firewall/router) is preventing them to be established.

Are you afraid of the word luck ?

It's not L*, it's variance

Rotten luck we'r having lately

It doesn't look terribly promising. Mostly it looks like it's connecting to three ips and then the handshakes are timing out.


Think I'm going to leave it for a while. It's bedtime anyway

it takes some time until p2pool has pulled the sharechain, check that it has connections.

Indeed I can. I am also capable of drawing logical conclusions. Though I've worked with code enough that not much surprises me, "downloading shares" does not particularly imply a causal link to "authorization denied" to me.

If that is the cause though, I'm happy to take it at that. Now I need to work out why it doesn't seem to be getting any shares, just a lot of handshake timeouts. I set up the port forward but it doesn't seem to have helped. Do I just need to leave it doing its thing for a while?

cant you read?

Having a little trouble. No luck searching and this thread is a little long to trawl through.

I think I have it all right. bitcoin.conf set up, running the Bitcoin Wallet, running p2pool, can connect with a browser and empty logs show up but when I try to connect with the miner, no luck


As far as I know, the username and password should not matter so no idea why this is failing. Any ideas?

Thanks

The reason BFL FPGA's suck on p2pool is that it takes ~5s to complete any work and it doesn't respond before the 5s is finished.
Since LP is 10s that means a LARGE % of time wasted/stale/DOA

If it is 60GH/s, a BFL SC Single would take ~72ms to complete any work ... so yeah it's rather obvious it will work fine on p2pool.
It's simply the faster nonce time vs 10s that makes the difference, there is no real difference in the WAY it processes that fixes the problem.

The real problem is the DOA because of latency, and whether we should change p2pool just for Avalons. BFL single FPGAs don't work on p2pool for the exact same reason (latency), and BFL has claimed (for what it's worth) that they designed the SCs so that they will work with p2pool. I don't have much of an opinion either way yet, but I wanted to show the numbers so people know what they are getting in to.

It may seem like a pittance for you now, but when everyone has ASICs it will be noticeable and currently the smaller GPU miners may feel it. And in the future, smaller miners may mean jalapenos, not GPU.

There are currently 241 users on p2pool right now (unique address, at least)
The current variance in pseduoshares is:
86400 seconds/day
10 seconds/pseudoshare
8640 pseudoshares/day
~36 pseudoshares per user per day
Variance = sqrt(36) = 6 shares (or ~17%)


Under the proposed 30 second block time target:
86400 seconds/day
30 seconds/pseudoshare
2880 pseudoshares/day
~12 pseudoshares per user per day
Variance = sqrt(12) = 3.5 shares (or ~29%)


So the average user (which in the future will be an ASIC user) will see  their variance increase from 17% per day to 29% per day. Again, I'm not trying to express an opinion - just show what the numbers are so others can form opinions.

I've been mining LTC on p2pool for almost a week now.  The pool seems to solve over 20 blocks per day.

What - twice in three months? I wouldn't bet on it......

Over 4 days.... looks like we will have lots of short blocks soon ;]

On a side note - what's the record for the longest period without finding a block? I have a feeling it's gonna be broken shortly......

(we usually find one when I mention something about it - let's hope it happens again.....soon )

yes, but it will be a pittance compared to ASIC. I'm using +32 difficulty now. I would go even higher but p2pool has problems or the work DOA because of age.

Longer LP means higher difficulty ...

I still don't see why a slightly longer share chain long poll time would be bad. It would let the slower miners get a share in easier before being cut off and helps higher latency. It would benefit just about everyone. It's still PPLNS so the payouts would still be equal to the balance of shares.

There's an easier way: just make the code compute the difficulty needed to get a maximum of shares in the PPLNS window to limit its share usage while maintaining the variance to an acceptable level (200 shares should probably be enough: I get a little more than 100 and variance is OK).

But someone (I think it's gmaxwell on IRC) pointed to me that there's a flaw: even if the pool tries to enforce this rule, there's nothing preventing a user mining with several payout addresses to lower his variance even more, defeating the mechanism.

I think it would be a sane default for p2pool to behave that way though. The current PPLNS setup only allows for ~40 miners with low (at least low according to my own definition) variance (I'm not sure of the N in PPLNS as it involves both 24h and the estimated time to get a block but there's 8640 shares in one day).

No, the BFL SC devices do not suffer this.