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

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


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.

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.

Nobody?

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

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.

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.

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?

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

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.

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.

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

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?

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.

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

4,8GH/s on pool ... 4,1GH/s on web interface, what the problem  web interface is a crappy thing after all. 

Anyone getting good numbers with S7? Seem to lose 400-500 GH/s.





Big difference in what is reported in cgminer, and at the pool.

crossroads installed on my ubuntu with running it with
to my p2pool run script I have added crossroads can be controled from web browser at 10.0.0.16:28332
while p2pool gave me an error if I put more than one rpc login/password, I have changed all rpc login/password at all bitcoind servers to be the same
if one of bitcoind servers dies than another took his work automatically

  Probably true, my other half is always correcting me 

Be careful to not offend him man! his english may be better than yours.
                       Edit --^
p3yot33at3r I was not saying yours is not good btw

OK - it's a little confusing, but here goes:

I inspected both downloads 1 & 3 and found that number 1 actually uses --no-submit-stale, while number 3 does not (this can be seen in the /etc/init.d/cgminer.sh file on line 69), which is where the confusion lies. So, the one to use is actually number 3 which is labelled SD-S5-20150107_cgm_4_9_0-queue_0_no-submit.tar.gz - as the "no-submit" part of the name actually means that it has been removed from the parameters & thus will submit stales.

It is also the one I uploaded here:   https://www.dropbox.com/s/gk6gva5e12g4qsr/SD-S5-20150107_cgm_4_9_0-queue_0_no-submit.tar.gz?dl=0

& igorwhite - it might be worthwhile swapping the names over to avoid any more confusion for native English speakers - or I can do an English translation for you if you like?