torepia
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 26, 2015, 02:39:09 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 27, 2015, 10:58:25 AM |
|
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
Legendary
Offline
Activity: 2548
Merit: 2264
1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 27, 2015, 01:45:39 PM |
|
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).
|
1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
|
|
|
jonnybravo0311
Legendary
Offline
Activity: 1344
Merit: 1024
Mine at Jonny's Pool
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 27, 2015, 07:20:56 PM |
|
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.
|
Jonny's Pool - Mine with us and help us grow! Support a pool that supports Bitcoin, not a hardware manufacturer's pockets! No SPV cheats. No empty blocks.
|
|
|
Richy_T
Legendary
Offline
Activity: 2548
Merit: 2264
1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 27, 2015, 09:21:48 PM |
|
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.
|
1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
|
|
|
jedimstr
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 28, 2015, 10:44:18 AM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 28, 2015, 11:06:12 AM Last edit: October 28, 2015, 11:25:19 AM by 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 ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) 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/270Can anyone else report if they have found an NMC block merge mining with p2pool over the last 2 - 3 months?
|
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 28, 2015, 12:02:54 PM |
|
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
Legendary
Offline
Activity: 1344
Merit: 1024
Mine at Jonny's Pool
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 28, 2015, 04:15:48 PM |
|
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.
|
Jonny's Pool - Mine with us and help us grow! Support a pool that supports Bitcoin, not a hardware manufacturer's pockets! No SPV cheats. No empty blocks.
|
|
|
kano
Legendary
Offline
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 29, 2015, 11:59:05 AM |
|
Hardware performance obviously has an overall performance effect. getblocktemplate performance if affected by mempool size and also, of course, CPU/RAM No guessing required ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif)
|
|
|
|
p3yot33at3r
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 29, 2015, 08:20:48 PM |
|
I can't remember the last time I found an NMC block - anyone else found one lately?
Nobody?
|
|
|
|
jtoomim
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 30, 2015, 12:43:32 AM |
|
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.
|
Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power. http://Toom.im
|
|
|
jtoomim
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 30, 2015, 12:47:22 AM Last edit: October 30, 2015, 05:22:15 AM by jtoomim |
|
For those of you having trouble with excessive memory consumption with bitcoind, the cause and a workaround has been discovered. Run 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.
|
Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power. http://Toom.im
|
|
|
Polyatomic
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 30, 2015, 02:45:27 AM Last edit: November 25, 2015, 04:56:03 AM by 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/efe29c7661ce9b6620a7Another Ed: Fri Oct 30 20:49:34 ACDT 2015 p2pool deployed 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 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 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 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.htmlhttps://www.ibm.com/developerworks/community/blogs/kevgrig/entry/linux_glibc_2_10_rhel_6_malloc_may_show_excessive_virtual_memory_usage?lang=en
|
|
|
|
OgNasty
Donator
Legendary
Offline
Activity: 4858
Merit: 4594
Leading Crypto Sports Betting & Casino Platform
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 30, 2015, 03:48:16 AM |
|
This round is getting ugly...
|
..Stake.com.. | | | ▄████████████████████████████████████▄ ██ ▄▄▄▄▄▄▄▄▄▄ ▄▄▄▄▄▄▄▄▄▄ ██ ▄████▄ ██ ▀▀▀▀▀▀▀▀▀▀ ██████████ ▀▀▀▀▀▀▀▀▀▀ ██ ██████ ██ ██████████ ██ ██ ██████████ ██ ▀██▀ ██ ██ ██ ██████ ██ ██ ██ ██ ██ ██ ██████ ██ █████ ███ ██████ ██ ████▄ ██ ██ █████ ███ ████ ████ █████ ███ ████████ ██ ████ ████ ██████████ ████ ████ ████▀ ██ ██████████ ▄▄▄▄▄▄▄▄▄▄ ██████████ ██ ██ ▀▀▀▀▀▀▀▀▀▀ ██ ▀█████████▀ ▄████████████▄ ▀█████████▀ ▄▄▄▄▄▄▄▄▄▄▄▄███ ██ ██ ███▄▄▄▄▄▄▄▄▄▄▄▄ ██████████████████████████████████████████ | | | | | | ▄▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄ █ ▄▀▄ █▀▀█▀▄▄ █ █▀█ █ ▐ ▐▌ █ ▄██▄ █ ▌ █ █ ▄██████▄ █ ▌ ▐▌ █ ██████████ █ ▐ █ █ ▐██████████▌ █ ▐ ▐▌ █ ▀▀██████▀▀ █ ▌ █ █ ▄▄▄██▄▄▄ █ ▌▐▌ █ █▐ █ █ █▐▐▌ █ █▐█ ▀▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀█ | | | | | | ▄▄█████████▄▄ ▄██▀▀▀▀█████▀▀▀▀██▄ ▄█▀ ▐█▌ ▀█▄ ██ ▐█▌ ██ ████▄ ▄█████▄ ▄████ ████████▄███████████▄████████ ███▀ █████████████ ▀███ ██ ███████████ ██ ▀█▄ █████████ ▄█▀ ▀█▄ ▄██▀▀▀▀▀▀▀██▄ ▄▄▄█▀ ▀███████ ███████▀ ▀█████▄ ▄█████▀ ▀▀▀███▄▄▄███▀▀▀ | | | ..PLAY NOW.. |
|
|
|
Richy_T
Legendary
Offline
Activity: 2548
Merit: 2264
1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 30, 2015, 04:02:50 AM |
|
For those of you having trouble with excessive memory consumption with bitcoind, the cause and a workaround has been discovered. Run 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.
|
1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
|
|
|
nicklello
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 193
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 30, 2015, 10:44:17 AM |
|
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
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 193
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 30, 2015, 10:53:32 AM |
|
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
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 76
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 30, 2015, 03:20:02 PM |
|
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
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
October 30, 2015, 03:23:54 PM |
|
P2pool hash rate has always been pretty erratic, especially with the luck hunters running around in circles..... ![Wink](https://bitcointalk.org/Smileys/default/wink.gif) 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](https://bitcointalk.org/Smileys/default/cheesy.gif) 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/270Can 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.
|
|
|
|
|