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

[torepia]

Hello!
torepia, you configure s7 btc_address/5000+16384 you do not know what values are needed for s5?

There is no "perfect" number for you to run. I just sat diff to 16384 to see if it could help on the hashrate, because p2pool was giving me 1k diff.

[p3yot33at3r]

Bad luck seems to be a problem with many pools atm, I've been reading loads of theories on pool threads as to why. Personally, I think it's just the increased diff - any thoughts anyone?

BTW, I can't remember the last time I found an NMC block - anyone else found one lately?

[Richy_T]

Bad luck seems to be a problem with many pools atm, I've been reading loads of theories on pool threads as to why. Personally, I think it's just the increased diff - any thoughts anyone?

BTW, I can't remember the last time I found an NMC block - anyone else found one lately?

Isn't the global has rate just calculated by the rates as self-reported by pools? If a pool added a bunch of hash rate and didn't report it, that could explain it.

One thing is sure, if some are getting unlucky, someone else is getting lucky. Unless the time between blocks is getting longer (and there's another difficulty adjustment soon and it looks like it's going up, not down).

[jonnybravo0311]

Bad luck seems to be a problem with many pools atm, I've been reading loads of theories on pool threads as to why. Personally, I think it's just the increased diff - any thoughts anyone?

BTW, I can't remember the last time I found an NMC block - anyone else found one lately?

Isn't the global has rate just calculated by the rates as self-reported by pools? If a pool added a bunch of hash rate and didn't report it, that could explain it.

One thing is sure, if some are getting unlucky, someone else is getting lucky. Unless the time between blocks is getting longer (and there's another difficulty adjustment soon and it looks like it's going up, not down).

No, global hash rate is calculated based upon the current network difficulty and the block solve times.  That's why you see crazy spikes up and down in the overall hash rate - it's just an estimate.  The global rate has no knowledge of any pools or their hash rate.  Even pools only calculate their hash rate based upon submitted shares.  They really have no idea what at what rate your miner is hashing.  They estimate it based upon share submission.

That's why the difficulty adjusts every 2016 blocks... that was assumed to be a long enough time to get a pretty good overall feeling on how the network is performing and still be relatively resistant to variant spikes.

[Richy_T]

No, global hash rate is calculated based upon the current network difficulty and the block solve times.  That's why you see crazy spikes up and down in the overall hash rate - it's just an estimate.  The global rate has no knowledge of any pools or their hash rate.  Even pools only calculate their hash rate based upon submitted shares.  They really have no idea what at what rate your miner is hashing.  They estimate it based upon share submission.

That's why the difficulty adjusts every 2016 blocks... that was assumed to be a long enough time to get a pretty good overall feeling on how the network is performing and still be relatively resistant to variant spikes.

OK, that makes sense. In which case, bad luck should just be bad luck unless there's something inherent in certain ways some pools do things.

[jedimstr]

Bad luck seems to be a problem with many pools atm, I've been reading loads of theories on pool threads as to why. Personally, I think it's just the increased diff - any thoughts anyone?

BTW, I can't remember the last time I found an NMC block - anyone else found one lately?

Regarding NMC - If you're using the Namecoin client version 3.80 or older, you won't be able to find a block.
Only the newer Namecoin Core clients are supported after BIP66 was implemented.  I stopped merge-mining NMC since they haven't had a working client for Mac (yet).
I was helping them test new Mac versions a few months back, but the devs were arguing about whether or not to continue to support bitcoin derived QT GUI or another GUI and the test clients they made for me failed at merge-mining (including the namecoind daemon client).

BIP66 started to be enforced in July.

There are beta clients available for Windows and Linux, but only from the Namecoin forums and not the main Namecoin site which only hosts the now useless legacy Namecoin clients:

Details here: https://forum.namecoin.info/viewtopic.php?f=7&t=2354

[p3yot33at3r]

Yeah - I've been using the namecoin-core client since day one, compiled from source, although there are constant updates to the client making it a race to keep up    Interesting that the GUI versions failed to merge mine, I'm curious as to weather this problem persists in the daemon, or is specific with p2pool?

Edit: I remember that forrestv had to make a few changes to p2pool to accommodate the new code, & am now wondering if maybe there was something we missed?

https://github.com/p2pool/p2pool/issues/270

Can anyone else report if they have found an NMC block merge mining with p2pool over the last 2 - 3 months?

[kano]

No, global hash rate is calculated based upon the current network difficulty and the block solve times.  That's why you see crazy spikes up and down in the overall hash rate - it's just an estimate.  The global rate has no knowledge of any pools or their hash rate.  Even pools only calculate their hash rate based upon submitted shares.  They really have no idea what at what rate your miner is hashing.  They estimate it based upon share submission.

That's why the difficulty adjusts every 2016 blocks... that was assumed to be a long enough time to get a pretty good overall feeling on how the network is performing and still be relatively resistant to variant spikes.

OK, that makes sense. In which case, bad luck should just be bad luck unless there's something inherent in certain ways some pools do things.

Of course there is "something inherent in certain ways some pools do things."

There's block change times, which affect the appearance of blocks and the amount of orphans.
There's block format that affects the distribution of blocks (and the amount of orphans)
There's pool distribution of blocks which affects the amount of orphans.

To put it simply, as an example, eligius fails on all of these.

Block change times are slow on eligius, I've compared my pool to eligius on multiple occasions, and each time found eligius wanting.
luke of course lied about it in the bitcoin github, but it's a simple thing to compare the block change times of 2 pools by running two miners and seeing the block changes on the two ... ... ...

They also use the same format for the coinbase as p2pool.
A p2pool block has a large coinbase, so that coinbase will slow down the propagation of the block around the internet.
This is OK on p2pool since it has a good distribution network by design - every p2pool miner distributes the blocks found.
For any other (non distributed) pool, a large coinbase will have a bigger effect on producing more orphans.

Then there's block distribution itself, which as I've already said, p2pool solves that itself by having a large network of miners each with a bitcoind
However, many p2pool nodes have been centralising p2pool, so this of course reduces that advantage over normal pools.

So there's just a few of the very specific items that affect what is incorrectly called "luck" by everyone, since some of those items are NOT luck.

[jonnybravo0311]

From a purist's perspective luck is simply figuring out how long it actually took to find a block compared to how long it was expected to take.

The only measure we have of this is shares.  How many shares were submitted vs how many shares were expected.  As kano has previously pointed out, p2pool struggles with this (because of orphaned shares never making it to the share chain), and therefore, p2pool luck figures are overstated.

[kano]

Hardware performance obviously has an overall performance effect.
getblocktemplate performance if affected by mempool size and also, of course, CPU/RAM
No guessing required

[p3yot33at3r]

I can't remember the last time I found an NMC block - anyone else found one lately?

Nobody?

[jtoomim]

e46btc, p2pool's performance is mostly dependent on single-core speed. Also, getblocktemplate/CreateNewBlock is also single-threaded. That's two threads total. You're better off with a $150 dual core Core i3 4370 @ 3.8 GHz than a $2000 16-core 2.2 GHz Xeon E5.

[jtoomim]

For those of you having trouble with excessive memory consumption with bitcoind, the cause and a workaround has been discovered. Run

Code:

export MALLOC_ARENA_MAX=1

in your shell before starting bitcoind. The problem appears to be that glibc's malloc function will use something like [number of cores] heap allocation arenas by default, and with the small amount of fragmentation caused by CreateNewBlock's allocation pattern, will end up using [number of cores] times the mempool size of total unused memory due to this fragmentation.

Edit: This issue is only relevant for bitcoind processes that run getblocktemplate -- i.e. bitcoind full nodes that are being used for mining, like with p2pool. For more info, https://github.com/bitcoin/bitcoin/issues/6876.

[Polyatomic]

Hyperenthusiastic linux user here.
Is this issue specific to a release of glibc or a linux distribution maybe,
given that some distros patch glibc quite heavily.
By all means call me brain damaged for asking this but I'm not an engineer.

Awesome data centre btw.

Ed: Fri Oct 30 16:37:12 ACDT 2015
ah k
since glibc 2.10 according to
https://gist.github.com/laanwj/efe29c7661ce9b6620a7

Another Ed: Fri Oct 30 20:49:34 ACDT 2015
p2pool deployed

Code:

p2pool 14.0-23-g6514fd8
Bitcoin Core RPC client version v0.11.1.0-dfe55bd
GNU C Library (Polyatomic 2.22-d5dff79 Testing) development release version 2.22.90, by Roland McGrath et al.
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 5.2.0.
Available extensions:
	crypt add-on version 2.1 by Michael Glad and others
	GNU Libidn by Simon Josefsson
	Native POSIX Threads Library by Ulrich Drepper et al
	BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

cat /proc/$(pidof bitcoind)/status

Code:

Name:	bitcoind
State:	S (sleeping)
Tgid:	31556
Ngid:	0
Pid:	31556
PPid:	1
TracerPid:	0
Uid:	1000	1000	1000	1000
Gid:	1000	1000	1000	1000
FDSize:	64
Groups:	11 12 90 999 1000 
NStgid:	31556
NSpid:	31556
NSpgid:	31556
NSsid:	31556
VmPeak:	 3743996 kB
VmSize:	 3612744 kB
VmLck:	     160 kB
VmPin:	       0 kB
VmHWM:	 1572224 kB
VmRSS:	 1564436 kB
VmData:	 3319996 kB
VmStk:	     244 kB
VmExe:	    4580 kB
VmLib:	   11888 kB
VmPTE:	    3860 kB
VmPMD:	      28 kB
VmSwap:	       0 kB
Threads:	31
SigQ:	0/128000
SigPnd:	0000000000000000
ShdPnd:	0000000000000000
SigBlk:	0000000000000000
SigIgn:	0000000000000080
SigCgt:	0000000180004003
CapInh:	0000000000000000
CapPrm:	0000000000000000
CapEff:	0000000000000000
CapBnd:	0000003fffffffff
Seccomp:	0
Cpus_allowed:	ffff
Cpus_allowed_list:	0-15
Mems_allowed:	1
Mems_allowed_list:	0
voluntary_ctxt_switches:	84090
nonvoluntary_ctxt_switches:	162

cat /proc/meminfo

Code:

MemTotal:       32796084 kB
MemFree:         5840788 kB
MemAvailable:   29846636 kB
Buffers:         1216152 kB
Cached:         21996348 kB
SwapCached:            0 kB
Active:          9820104 kB
Inactive:       16062692 kB
Active(anon):    2647968 kB
Inactive(anon):    49044 kB
Active(file):    7172136 kB
Inactive(file): 16013648 kB
Unevictable:         180 kB
Mlocked:             180 kB
SwapTotal:      16777208 kB
SwapFree:       16777208 kB
Dirty:                16 kB
Writeback:             0 kB
AnonPages:       2670452 kB
Mapped:           265412 kB
Shmem:             26748 kB
Slab:             960876 kB
SReclaimable:     905768 kB
SUnreclaim:        55108 kB
KernelStack:       10096 kB
PageTables:        29880 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    33175248 kB
Committed_AS:    4806364 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       33364 kB
VmallocChunk:   34359685208 kB
AnonHugePages:   2076672 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

for (( i=0; i <= 20; ++i )) do cat /proc/meminfo | grep MemFree ; done

Code:

MemFree:         5844328 kB
MemFree:         5844328 kB
MemFree:         5844272 kB
MemFree:         5843852 kB
MemFree:         5844208 kB
MemFree:         5843804 kB
MemFree:         5844128 kB
MemFree:         5844128 kB
MemFree:         5844128 kB
MemFree:         5844128 kB
MemFree:         5844116 kB
MemFree:         5843680 kB
MemFree:         5843680 kB
MemFree:         5843300 kB
MemFree:         5843228 kB
MemFree:         5842816 kB
MemFree:         5843180 kB
MemFree:         5842304 kB
MemFree:         5842296 kB
MemFree:         5841844 kB
MemFree:         5841264 kB

yet another Ed:
Sat Oct 31 08:34:04 ACDT 2015
links here:
http://journal.siddhesh.in/posts/malloc-per-thread-arenas-in-glibc.html
https://www.ibm.com/developerworks/community/blogs/kevgrig/entry/linux_glibc_2_10_rhel_6_malloc_may_show_excessive_virtual_memory_usage?lang=en

[OgNasty]

This round is getting ugly...

[Richy_T]

For those of you having trouble with excessive memory consumption with bitcoind, the cause and a workaround has been discovered. Run

Code:

export MALLOC_ARENA_MAX=1

in your shell before starting bitcoind. The problem appears to be that glibc's malloc function will use something like [number of cores] heap allocation arenas by default, and with the small amount of fragmentation caused by CreateNewBlock's allocation pattern, will end up using [number of cores] times the mempool size of total unused memory due to this fragmentation.

Sweet. Hopefully this will help the bitcoind that I have running on a Raspberry Pi which brings down the whole thing when it's started for the last few weeks too.

[nicklello]

I think this is a not secret that p2pool is not multithreaded for now (or maybe I don't know how to force it?) and this is running only on 1 CPU core.
With several conditions this can be a huge problem of its performance.  
It may doesn't matter if you have 16 CPU w/ 32 cores total, but python will own 1 core at 100% rate.

e46btc Given the different threading models; you may want to include processor affinity in your testing --- try 'jailing' bitcoind into the last 8 processors (8-15) and 'jailing' p2pool into processor 7 so the 2 processes do not compete for cycles.

I'm not saying that this WILL give you performance benefits but it *may* give a slight improvement.

[nicklello]

This round is getting ugly...

Every time they go so long I start to wonder whether there is some edge case bug in the code no one noticed where we have passed some threshold in the blockchain/mempool causing it to corrupt any p2pool block creation attempts. This drought is really kicking my ass.

I'm glad you posted this; I was starting to wonder if I had somehow messed up my installation... I have not seen a block completed for about 4 days.

[Songminer]

Miners are bailing.. down another 5 this morning.. now 288 from 300+ a few days ago.

If we could just get our hash up to 2.5-3 PHs on an average..  no?

[p3yot33at3r]

P2pool hash rate has always been pretty erratic, especially with the luck hunters running around in circles.....

Yeah - I've been using the namecoin-core client since day one, compiled from source, although there are constant updates to the client making it a race to keep up    Interesting that the GUI versions failed to merge mine, I'm curious as to weather this problem persists in the daemon, or is specific with p2pool?

Edit: I remember that forrestv had to make a few changes to p2pool to accommodate the new code, & am now wondering if maybe there was something we missed?

https://github.com/p2pool/p2pool/issues/270

Can anyone else report if they have found an NMC block merge mining with p2pool over the last 2 - 3 months?

Well, as nobody has reported finding any NMC blocks merge mining with the new core client, I'm beginning to think that there is still a problem with the code somewhere that's specific to p2pool, as other centralized pools seem to work fine with it. I'll pop over to the NMC forum & ask domob to maybe have a look into it, just in case.