Author

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

legendary
Activity: 1066
Merit: 1098

Regarding NMC merge mining - I have posted about my concerns in the NMC forum:

https://forum.namecoin.info/viewtopic.php?f=6&t=2371&p=15989#p15989

Hopefully domob or another dev will look into it. In the meantime, if anyone does actually find an NMC block - please report it, thanks.

I would think that whether or not anyone has actually FOUND a block is not really the question at hand.  The real question is "Do you have a best share higher than the current NMC difficulty AND that share did not mine a block?"

If the answer to that question is yes, there is a problem.
sr. member
Activity: 266
Merit: 250
Thank you for reply.  Actually I am not expert and I thought that we should find block before (or when) all shares in chain will be verified and found.   For example 2 days ago there was this count in p2pool log file
Code:
2015-10-29 21:21:25.788644 P2Pool: 17367 shares in chain (10488 verified/17371 total)
But for present moment all shares in chain were verified according to log file, what does it mean?

It means your node is still verifying shares - it can take a while if you have recently downloaded the sharechain.

Regarding NMC merge mining - I have posted about my concerns in the NMC forum:

https://forum.namecoin.info/viewtopic.php?f=6&t=2371&p=15989#p15989

Hopefully domob or another dev will look into it. In the meantime, if anyone does actually find an NMC block - please report it, thanks.
full member
Activity: 157
Merit: 103
Thank you for reply.  Actually I am not expert and I thought that we should find block before (or when) all shares in chain will be verified and found.   For example 2 days ago there was this count in p2pool log file
Code:
2015-10-29 21:21:25.788644 P2Pool: 17367 shares in chain (10488 verified/17371 total)
But for present moment all shares in chain were verified according to log file, what does it mean?
legendary
Activity: 1258
Merit: 1027
Who knows what we are still verifying ?

Code:
2015-11-01 04:40:47.880774  Pool: 1311TH/s Stale rate: 20.0% Expected time to block: 2.4 days
17402 shares in chain (17406 verified/17406 total)

I'm not sure I fully understand you question but a maximum of the last 8,640 shares are paid (often less) when a block is found...
full member
Activity: 157
Merit: 103
Khm..and this is decreasing

Code:
2015-11-01 04:58:25.163393 P2Pool: 17328 shares in chain (17332 verified/17332 total)
full member
Activity: 157
Merit: 103
Who knows what we are still verifying ?

Code:
2015-11-01 04:40:47.880774  Pool: 1311TH/s Stale rate: 20.0% Expected time to block: 2.4 days
17402 shares in chain (17406 verified/17406 total)
sr. member
Activity: 257
Merit: 250
In a desperate attempt for answers, you could ask in #p2pool on Freenode.
Though the channel appears to be a remnant of a great era now.
newbie
Activity: 58
Merit: 0
Namecoin merge mining works

I'm not so sure, can you confirm you found a block merge mining with the core client & p2pool?

there is no sharechain so it basically solomining

Yes, I'm aware of that.

There haven't been changes to auxpow

There have been many changes to auxpow, see the github page:    https://github.com/namecoin/namecoin-core/tree/auxpow

Again, I'm not saying that there is definitely a problem with merge mining NMC with p2pool, I just want to confirm that there isn't a problem with it, & until someone can report finding a block while merge mining NMC there simply isn't any proof. I find it strange that since the implementation of namecoin-core, nobody has found one. I think it's just too much of a coincidence & want to make sure.

As I said earlier:


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


...yet everyone assumed it was working fine then also, only it wasn't. If we missed something before, we could quite easily have missed something else, either in the NMC code or p2pool (but I suspect NMC tbh, as all my other merge mined coins are working normally).

I have not found a namecoin block and would have to look deeper to see if any of my shares met the target.  I figure it is working since it says it is receiving work in the logs... Sorry I thought you meant changes to auxpow in p2pool.

Perhaps something is wrong?..
sr. member
Activity: 266
Merit: 250
Namecoin merge mining works

I'm not so sure, can you confirm you found a block merge mining with the core client & p2pool?

there is no sharechain so it basically solomining

Yes, I'm aware of that.

There haven't been changes to auxpow

There have been many changes to auxpow, see the github page:    https://github.com/namecoin/namecoin-core/tree/auxpow

Again, I'm not saying that there is definitely a problem with merge mining NMC with p2pool, I just want to confirm that there isn't a problem with it, & until someone can report finding a block while merge mining NMC there simply isn't any proof. I find it strange that since the implementation of namecoin-core, nobody has found one. I think it's just too much of a coincidence & want to make sure.

As I said earlier:


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


...yet everyone assumed it was working fine then also, only it wasn't. If we missed something before, we could quite easily have missed something else, either in the NMC code or p2pool (but I suspect NMC tbh, as all my other merge mined coins are working normally).
newbie
Activity: 58
Merit: 0
Well, as long as the implementation of the auxpow code hasn't been touched in the new NMC codebase, then it should work as it previously did.  I believe Eligius is still merge mining blocks of NMC successfully.

Maybe forrestv could take a look into it to see if there's an issue.

Of course, my next question: if you are merge mining, have you found a share high enough to solve a block of NMC, but the block didn't get submitted?
Namecoin merge mining works, but there is no sharechain so it basically solomining.  There haven't been changes to auxpow.
legendary
Activity: 1344
Merit: 1024
Mine at Jonny's Pool
Well, as long as the implementation of the auxpow code hasn't been touched in the new NMC codebase, then it should work as it previously did.  I believe Eligius is still merge mining blocks of NMC successfully.

Maybe forrestv could take a look into it to see if there's an issue.

Of course, my next question: if you are merge mining, have you found a share high enough to solve a block of NMC, but the block didn't get submitted?
sr. member
Activity: 266
Merit: 250
Yeah, I found a few NMC blocks myself prior to the code change to the newer core client, but nothing since then, and from what I can see, neither has anyone else. I'm not saying there is definitely a problem with the core client & p2pool - but think it's worth looking into, just in case.
legendary
Activity: 1344
Merit: 1024
Mine at Jonny's Pool
To those thinking there might be a bug... it's called variance.  Take off the tinfoil hats. Tongue

p3yot33at3r, I haven't merge mined any coins for a while.  However, when I was, I only ever found 2 NMC blocks (maybe it was 3).  Back then, a block of NMC was actually worth a little bit of coin on the exchanges.  Not sure if jtoomin is merge mining, but it appears he's got the most hash, so he'd have a better chance of finding a block of NMC.  Here's from jedimstr earlier:

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
sr. member
Activity: 266
Merit: 250
P2pool hash rate has always been pretty erratic, especially with the luck hunters running around in circles..... Wink

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  Cheesy  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.
member
Activity: 76
Merit: 10
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?
member
Activity: 193
Merit: 10
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.
member
Activity: 193
Merit: 10
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.
legendary
Activity: 2576
Merit: 2267
1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
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.
donator
Activity: 4760
Merit: 4323
Leading Crypto Sports Betting & Casino Platform
This round is getting ugly...
sr. member
Activity: 257
Merit: 250
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:
.
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




Jump to: