[1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool

[forrestv]

I'm showing pool stale rate at 18%.  Aside from making my 4% very very efficient, is this normal for a hard branch?

I'm showing 8 at 20% right now.

Nothing has actually happened yet. The switchover happens at 95% upgraded, and until then, nothing should change.

I think the jump in the pool's stale rate was someone joining with a lot of misconfigured miners (FPGAs?). Looking at http://forre.st:9332/static/graphs.html?Day , the good (non-stale) hashrate didn't decline.

[1715153254]

1715153254

[1715153254]

1715153254

[1715153254]

1715153254

[mdude77]

I'm showing pool stale rate at 18%.  Aside from making my 4% very very efficient, is this normal for a hard branch?

I'm showing 8 at 20% right now.

Nothing has actually happened yet. The switchover happens at 95% upgraded, and until then, nothing should change.

I was wondering how that worked.  Clever!

M

[rav3n_pl]

seeing the same atm.

Seems to be normal?

Code:

2012-10-18 23:48:46.318000 P2Pool: 17452 shares in chain (9324 verified/17456 total) Peers: 12 (2 incoming)
2012-10-18 23:48:46.319000  Local: 3851MH/s in last 10.0 minutes Local dead on arrival: ~4.3% (2-7%) Expected time to share: 13.0 minutes
2012-10-18 23:48:46.320000  Shares: 7 (1 orphan, 3 dead) Stale rate: ~57.1% (25-85%) Efficiency: ~51.2% (18-90%) Current payout: 0.0174 BTC
2012-10-18 23:48:46.321000  Pool: 399GH/s Stale rate: 16.3% Expected time to block: 9.2 hours

57% stales? Looks like failed miner config to me.
If you use cgminer (best miner imo) change in config:
"queue" : "0",
"gpu-threads" : "1",

[BR0KK]

no  i don't use GPUs

im testing p2pool, with my ztex boards (so FPGAs). I figured it takes some time for them to do real work.

[rav3n_pl]

no  i don't use GPUs

im testing p2poo, with my ztex boards (sop FPGAs). I figured it takes some time for them to do real work.

If this boards not catching longpools properly and not returning shares just after they found it p2pool is not good for them.
I read about some FPGAs that making full nonce then returning shares it found. But if longpool hit in mean time they are DOA.
If you using cgminer change
"queue" : "0",
to prevent miner from fetching more work than it need.

[BR0KK]

might try cgminer on them (i use btcminer; ztex own miner; for them). But im not sure how to use that

and I'm testing a beta release of the ztex bitstream. that might be a problem too here.

Code:

Version: 8.2

Pool rate: 366GH/s (14% stale) Share difficulty: 703

Node uptime: 0.098 days Peers: 10 out, 2 in

Local rate: 3.87GH/s (2.6% DOA) Expected time to share: 0.217 hours

Shares: 7 total (1 orphaned, 3 dead) Efficiency: 49.76%

thats what the stats page gives me. Ill let it run for a night and report back. Im online for a few minutes now. As i recall that behavior was the same with p2pool 5 (and all versions below) ittl correct itself after running a while..... I hope so :/

thats the printout of btcminer:

Code:

bus-0-0: ztex_ufm1_15d4-04A32E1205-1: f=204,00MHz,  errorRate=0,07%,  maxErrorRate=0,90%,  hashRate=203,9MH/s,  submitted 16 new nonces,  luckFactor=1,21
bus-0-0: ztex_ufm1_15d4-04A3468E00-1: f=208,00MHz,  errorRate=0,07%,  maxErrorRate=0,86%,  hashRate=207,9MH/s,  submitted 16 new nonces,  luckFactor=0,97
bus-0-0: ztex_ufm1_15d4-04A3469756-1: f=212,00MHz,  errorRate=0,41%,  maxErrorRate=1,25%,  hashRate=211,1MH/s,  submitted 15 new nonces,  luckFactor=0,87
bus-0-0: ztex_ufm1_15d4-04A346BF8B-1: f=212,00MHz,  errorRate=0,03%,  maxErrorRate=0,71%,  hashRate=211,9MH/s,  submitted 14 new nonces,  luckFactor=1,00
bus-0-0: ztex_ufm1_15d4-04A346D523-1: f=216,00MHz,  errorRate=0,02%,  maxErrorRate=0,50%,  hashRate=216,0MH/s,  submitted 17 new nonces,  luckFactor=1,02
bus-0-0: ztex_ufm1_15d4-04A346E12C-1: f=204,00MHz,  errorRate=1,17%,  maxErrorRate=2,36%,  hashRate=201,6MH/s,  submitted 18 new nonces,  luckFactor=1,22
bus-0-0: ztex_ufm1_15y1-04A3461185-1: f=228,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=228,0MH/s,  submitted 10 new nonces,  luckFactor=0,57
bus-0-0: ztex_ufm1_15y1-04A3461185-2: f=228,00MHz,  errorRate=0,68%,  maxErrorRate=1,36%,  hashRate=226,4MH/s,  submitted 20 new nonces,  luckFactor=0,93
bus-0-0: ztex_ufm1_15y1-04A3461185-3: f=228,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=228,0MH/s,  submitted 14 new nonces,  luckFactor=0,89
bus-0-0: ztex_ufm1_15y1-04A3461185-4: f=228,00MHz,  errorRate=0,13%,  maxErrorRate=0,51%,  hashRate=227,7MH/s,  submitted 10 new nonces,  luckFactor=0,91
bus-0-1: ztex_ufm1_15y1-04A34644C6-1: f=220,00MHz,  errorRate=0,00%,  maxErrorRate=1,00%,  hashRate=220,0MH/s,  submitted 12 new nonces,  luckFactor=0,80
bus-0-1: ztex_ufm1_15y1-04A34644C6-2: f=228,00MHz,  errorRate=0,07%,  maxErrorRate=0,82%,  hashRate=227,8MH/s,  submitted 8 new nonces,  luckFactor=0,69
bus-0-1: ztex_ufm1_15y1-04A34644C6-3: f=224,00MHz,  errorRate=0,00%,  maxErrorRate=0,94%,  hashRate=224,0MH/s,  submitted 14 new nonces,  luckFactor=0,80
bus-0-1: ztex_ufm1_15y1-04A34644C6-4: f=228,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=228,0MH/s,  submitted 15 new nonces,  luckFactor=0,93
bus-0-1: ztex_ufm1_15y1-04A36E24F2-1: f=220,00MHz,  errorRate=0,74%,  maxErrorRate=1,32%,  hashRate=218,4MH/s,  submitted 15 new nonces,  luckFactor=1,03
bus-0-1: ztex_ufm1_15y1-04A36E24F2-2: f=216,00MHz,  errorRate=0,00%,  maxErrorRate=0,00%,  hashRate=216,0MH/s,  submitted 21 new nonces,  luckFactor=1,12
bus-0-1: ztex_ufm1_15y1-04A36E24F2-3: f=220,00MHz,  errorRate=0,00%,  maxErrorRate=0,98%,  hashRate=220,0MH/s,  submitted 24 new nonces,  luckFactor=1,06
bus-0-1: ztex_ufm1_15y1-04A36E24F2-4: f=216,00MHz,  errorRate=0,75%,  maxErrorRate=1,03%,  hashRate=214,4MH/s,  submitted 21 new nonces,  luckFactor=1,09
bus-0-0: poll loop time: 49ms (USB: 46ms network: 3ms)   getwork time: 7ms  submit time: 2ms
bus-0-1: poll loop time: 51ms (USB: 49ms network: 3ms)   getwork time: 8ms  submit time: 3ms
Total hash rate: 3931,1 MH/s
Total submitted hash rate: 3699,5 MH/s
 --------
bus-0-0: ztex_ufm1_15y1-04A3461185-1: Set frequency from 228,00MHz to 232,00MHz
New block detected by long polling (submitold = true)
New block detected by long polling (submitold = true)
New block detected by long polling (submitold = true)
bus-0-0: ztex_ufm1_15y1-04A3461185-1: Set frequency from 232,00MHz to 228,00MHz
New block detected by long polling (submitold = true)
New block detected by long polling (submitold = true)

Note: Boards are still in the clocking phase.... so that might be an efficiency killer too?

[rav3n_pl]

Code:

Local rate: 3.87GH/s (2.6% DOA) Expected time to share: 0.217 hours

THIS looks good, only 2,6% DOA

Code:

Shares: 7 total (1 orphaned, 3 dead) Efficiency: 49.76%

This looks worse, IMO too many dead shares, looks like something lagging there.

[BR0KK]

That might be caused from USB lagging ..... Have to restart the Mac again. I'll leave tit running now till tomorrow morning (desperately need sleep!)

Need to buy another miner base....( The mac mini draws way to much power) Since the pi is not good for this I'm still searching :/

How many deads should there be for 3,9 ghs?

[ChipGeek]

Need to buy another miner base....( The mac mini draws way to much power) Since the pi is not good for this I'm still searching :/

Why is the Raspberry Pi not good for this? 

I have a R-Pi and have been using it with a BFL Single on non-p2p pools quite well.  But as soon as (or if) ASICs arrive I plan on switching back to p2pool on my R-Pi.  Assuming there is NOT the same inefficiency that currently exists with BFL on p2pool.

[stevegee58]

I thought I'd try p2pool again but I'm having a heck of a time getting the client to run this time around.  I'm running bitcoin-qt 0.7.0 with the .conf file set up correctly as a server.  I'm running the latest p2pool client 8.2

When I start run_p2pool.exe I get this in the log file:

Code:

2012-10-18 20:03:33.221000 p2pool (version 8.2)
2012-10-18 20:03:33.221000 
2012-10-18 20:03:33.221000 Testing bitcoind RPC connection to 'http://127.0.0.1:8332/' with username 'user'...
2012-10-18 20:03:33.861000 Testing bitcoind P2P connection to '127.0.0.1:8333'...

It just sits there and never says success.

[Smoovious]

I thought I'd try p2pool again but I'm having a heck of a time getting the client to run this time around.  I'm running bitcoin-qt 0.7.0 with the .conf file set up correctly as a server.  I'm running the latest p2pool client 8.2

When I start run_p2pool.exe I get this in the log file:

Code:

2012-10-18 20:03:33.221000 p2pool (version 8.2)
2012-10-18 20:03:33.221000 
2012-10-18 20:03:33.221000 Testing bitcoind RPC connection to 'http://127.0.0.1:8332/' with username 'user'...
2012-10-18 20:03:33.861000 Testing bitcoind P2P connection to '127.0.0.1:8333'...

It just sits there and never says success.

Are you limiting the # of connections in bitcoind, and, is bitcoind already at that limit? (that's what the problem is on my end when that happens... it keeps retrying so if you lose a peer connection in bitcoind, then p2pool can get in)

-- Smoov

[stevegee58]

I haven't done anything special to limit connections to my knowledge.

I'm not using bitcoind BTW, I'm using bitcoin-qt (the GUI client).  I was using it earlier this year like this successfully.

[Smoovious]

I haven't done anything special to limit connections to my knowledge.

I'm not using bitcoind BTW, I'm using bitcoin-qt (the GUI client).  I was using it earlier this year like this successfully.

daemon=1
server=1
rpcuser=username
rpcpassword=password
rpcport=8332
rpcallowip=127.0.0.1

all these defined in bitcoin.conf?

-- Smoov

[stevegee58]

I've been running everything through Tor for the last couple of months.  I changed bitcoin-qt's settings so it's direct again and now the client connects.
Not sure what's up with that.

[BR0KK]

Code:

2012-10-19 08:47:15.565000 P2Pool: 17604 shares in chain (12558 verified/17608 total) Peers: 11 (1 incoming)
2012-10-19 08:47:15.566000  Local: 4008MH/s in last 10.0 minutes Local dead on arrival: ~3.6% (2-6%) Expected time to share: 13.6 minutes
2012-10-19 08:47:15.567000  Shares: 45 (4 orphan, 3 dead) Stale rate: ~15.6% (7-29%) Efficiency: ~89.8% (75-99%) Current payout: 0.2186 BTC
2012-10-19 08:47:15.568000  Pool: 369GH/s Stale rate: 6.0% Expected time to block: 9.9 hours

Code:

Version: 8.2

Pool rate: 367GH/s (5.8% stale) Share difficulty: 770

Node uptime: 0.452 days Peers: 10 out, 1 in

Local rate: 3.99GH/s (3.6% DOA) Expected time to share: 0.230 hours

Shares: 45 total (4 orphaned, 3 dead) Efficiency: 89.60%

See .... it goes down slowly

Need to buy another miner base....( The mac mini draws way to much power) Since the pi is not good for this I'm still searching :/

Why is the Raspberry Pi not good for this? 

I have a R-Pi and have been using it with a BFL Single on non-p2p pools quite well.  But as soon as (or if) ASICs arrive I plan on switching back to p2pool on my R-Pi.  Assuming there is NOT the same inefficiency that currently exists with BFL on p2pool.

Cause its a real bitch when it comes to USB connections .....

[zvs]

i had similar problem with 50% doa/stale rates on one computer (one i had got from someone else, all assembled, etc) on p2pool.... on other servers it was fine.  anyway, in the network config the flow control was off.  when i turned it on, it dropped to 1% or so like normal.

[rav3n_pl]

Trying to complie scrypt module on my win7 64 machine:
(...)
Any ideas? I have no troubles on win7 32bit...

Ok, have done it bit around:
- compiled scrypt module on win32 machine
- copied it to my python installation on win64 machine
It works
Compiled fully functional win64 build 8.2-4, posted on my skydrive
Have fun

Next step will be python 64bit Maybe... ;]

[Diapolo]

I've been running everything through Tor for the last couple of months.  I changed bitcoin-qt's settings so it's direct again and now the client connects.
Not sure what's up with that.

As I've got some proxy related patches in the pipe, can you tell me what command-line you used for tor?

https://github.com/bitcoin/bitcoin/pull/1781
https://github.com/bitcoin/bitcoin/pull/1778

Another thing I intend to add is an enhanced Bitcoin-Qt network settings tab.



Thanks,
Dia

[stevegee58]

I use Vidalia so I don't actually know what command line goes to Tor.  I can say I didn't use any fancy settings, just the stock client with no relay etc.

[cabin]

Thanks for this.. I was wondering why I have to try a few times to get p2pool to connect on that line and the # connections was it!

I thought I'd try p2pool again but I'm having a heck of a time getting the client to run this time around.  I'm running bitcoin-qt 0.7.0 with the .conf file set up correctly as a server.  I'm running the latest p2pool client 8.2

When I start run_p2pool.exe I get this in the log file:

Code:

2012-10-18 20:03:33.221000 p2pool (version 8.2)
2012-10-18 20:03:33.221000 
2012-10-18 20:03:33.221000 Testing bitcoind RPC connection to 'http://127.0.0.1:8332/' with username 'user'...
2012-10-18 20:03:33.861000 Testing bitcoind P2P connection to '127.0.0.1:8333'...

It just sits there and never says success.

Are you limiting the # of connections in bitcoind, and, is bitcoind already at that limit? (that's what the problem is on my end when that happens... it keeps retrying so if you lose a peer connection in bitcoind, then p2pool can get in)

-- Smoov