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

Yeah, that'll be pulling out the last 360 samples - at 10 seconds each for an hour in total.

Perfect! Thanks!

Do you have a pretty low hash rate? If you don't get a share every 24 hours, your payout will drop to zero at times.


No, one hour (3600 seconds).

...I have them right now. And my payout's back to normal. I'm not sure about before. If it happens again, I'll check.

SHARE_PERIOD=10, # seconds for BTC...

So... I would guess that it's a 10 sec resolution?

Do you have any peer connections?

Yep, useful. What time period are those stats over? In particular I mean the miner_hash_rates and miner_dead_hash_rates. I need them over a reasonably short period for alarming to be able to react if a miner goes away.

For the first time in a month of mining on p2pool, the page is saying "Payout if a block were found now: 0 BTC". This is in spite of the hashrate being shown normal and DOAs/orphans next to nonexistent. And about an hour ago it was showing a non-zero payment. I restarted the entire btc, p2pool, bfgminer ensemble but it's still showing 0. Why does this happen?

I get ---ERROR---

Wow, I didn't know that existed. That makes something I'm trying to do a lot easier.

I think http://localhost:9554/local_stats is as close as you can get. 

M

it seems that the latency is better now, i get 0.06ms, before was 0.290 or something

when he say" lost 8 share due to connection lost" it's equal to= i lost 8 transiction?

Is there any way of getting the per-miner stats from p2pool as JSON or even just a raw number? I want to set up Nagios to alert me if any of my miners stop working.

Something like:
http://cryptominer.org:9332/miner/

Returning (hash rate and dead/stale):
516.12312 12.1451

Currently getting familiar with the code, so I can add this if not already in place.

Another example where things aren't working optimally:

I unpacked the latest git into a new folder, and fired it up.  A number of times as it was "processing xxx shares from [...]" it would take so long that when it finished, a bunch of errors would be thrown because things timed out.  I don't know Python very well at all, but it doesn't seem like p2pool is multithreaded.  I know multithreading isn't a trivial task.  Am I missing something, or is p2pool multithreaded and I'm just not seeing it?

M

you're doing fine, but your efficiency is not has high as someone with 0.003 s getwork latency.
Your expected DOA due to getblocktemplate latency: .7/10 = 7%
Someone with a 0 tx fee blocks (3ms) .003/10= 0.03%

assuming everything else equal: if your efficiency is 100%, theirs can be 107%.

They get 7% more profit than you by choosing to not process any transactions at all.

Thus Kano's argument that if the optimal p2pool setup is to process 0 tx, then p2pool (as it stands with standard bitcoind) hurts the network

+1

I was trying to indicate bandwidth limitations earlier.  I don't have any ports forwarded at all, to p2pool or bitcoind.  I get 8 in on p2pool, and 9 in on bitcoind (atm).  I'm also running namecoind and ixcoin for merged mining, I'd imagine they have 8 each as well.  No problems at all, and my stale rate is usually lower than the pool, sometimes significantly moreso.  When I start forwarding ports, that's when things get out of control.

M

For what it's worth...

My node (http://ask.gxsnmp.org:9332/) has:
P2Pool - Peers   8 out, 29 in
Bitcoind:  "connections" : 51,
             "currentblocksize" : 66063,

Getwork Latency -Mean: 0.695s

And it seems to be doing fine.

Uptime: 11.257 days.

That's @ all the 'default' settings

Could it be better? Probably.. I'm just not really sure what to tweak to make it better, it seems to be working and I get payouts whenever a block is found.

Good counter argument

Edit: meaning - then - that the problem is him and being detrimental to bitcoin to solve his problem and advertising others to do that is really ... not ideal at all.

Honestly, the orphan thing has more to do with too many connections on bitcoind than it does on p2pool...

p2pool already goes out of its way to help facilitate found blocks getting distributed as fast as possible, but there is no way you're going to be 100% orphan free with the way the bitcoin network itself operates.

Processing transactions is what mining is all about. Too many have forgotten that, believing that mining is about getting coin, and if you can throw in some transactions while you do it, why not.

But... processing the transactions is what our sole purpose as miners, actually is.

Probably be better off to keep the connection counts down to 2-4 on bitcoind, and low connections on p2pool as well, so we're sending data to less people, allowing them to be sent, faster, and let the meganodes with the bandwidth to handle it, focus on the wide redistribution.

It does no good for a node with a residential-quality upstream, to pass along block data to 50 nodes, if it takes 10 seconds to do it.

The torrent community fights about this too, and the best nodes you find that are sending to you fast, are the ones who aren't trying to keep 500 connections open, giving each peer just a few kB/s at a time, making block propagation just drag out forever, much longer than it should, with extra wasted overhead.

Block propagation suffers the same way. Less really is sometimes more.

-- Smoov

He seems to think there's an orphan problem. There's only been 2 orphans in the past 3 months.

I function just fine w/o having to restrict transactions at all.  Must be something with his environment.

M