Bitcoin Forum
March 19, 2024, 05:21:06 AM *
News: Latest Bitcoin Core release: 26.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 [683] 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 ... 814 »
  Print  
Author Topic: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool  (Read 2591571 times)
torepia
Full Member
***
Offline Offline

Activity: 140
Merit: 100


View Profile
October 26, 2015, 02:39:09 AM
 #13641

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.
"Bitcoin: the cutting edge of begging technology." -- Giraffe.BTC
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
p3yot33at3r
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
October 27, 2015, 10:58:25 AM
 #13642

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 Offline

Activity: 2380
Merit: 2100


1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k


View Profile
October 27, 2015, 01:45:39 PM
 #13643

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 Offline

Activity: 1344
Merit: 1023


Mine at Jonny's Pool


View Profile WWW
October 27, 2015, 07:20:56 PM
 #13644

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 Offline

Activity: 2380
Merit: 2100


1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k


View Profile
October 27, 2015, 09:21:48 PM
 #13645


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
Hero Member
*****
Offline Offline

Activity: 798
Merit: 1000



View Profile
October 28, 2015, 10:44:18 AM
 #13646

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
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
October 28, 2015, 11:06:12 AM
Last edit: October 28, 2015, 11:25:19 AM by p3yot33at3r
 #13647

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?
kano
Legendary
*
Offline Offline

Activity: 4438
Merit: 1794


Linux since 1997 RedHat 4


View Profile
October 28, 2015, 12:02:54 PM
 #13648


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.

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
jonnybravo0311
Legendary
*
Offline Offline

Activity: 1344
Merit: 1023


Mine at Jonny's Pool


View Profile WWW
October 28, 2015, 04:15:48 PM
 #13649

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 Offline

Activity: 4438
Merit: 1794


Linux since 1997 RedHat 4


View Profile
October 29, 2015, 11:59:05 AM
 #13650

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

Pool: https://kano.is - low 0.5% fee PPLNS 3 Days - Most reliable Solo with ONLY 0.5% fee   Bitcointalk thread: Forum
Discord support invite at https://kano.is/ Majority developer of the ckpool code - k for kano
The ONLY active original developer of cgminer. Original master git: https://github.com/kanoi/cgminer
p3yot33at3r
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
October 29, 2015, 08:20:48 PM
 #13651

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

Nobody?
jtoomim
Hero Member
*****
Offline Offline

Activity: 818
Merit: 1005


View Profile WWW
October 30, 2015, 12:43:32 AM
 #13652

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
Hero Member
*****
Offline Offline

Activity: 818
Merit: 1005


View Profile WWW
October 30, 2015, 12:47:22 AM
Last edit: October 30, 2015, 05:22:15 AM by jtoomim
 #13653

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.

Hosting bitcoin miners for $65 to $80/kW/month on clean, cheap hydro power.
http://Toom.im
Polyatomic
Sr. Member
****
Offline Offline

Activity: 257
Merit: 250


View Profile
October 30, 2015, 02:45:27 AM
Last edit: November 25, 2015, 04:56:03 AM by Polyatomic
 #13654

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
Donator
Legendary
*
Offline Offline

Activity: 4676
Merit: 4153


Leading Crypto Sports Betting & Casino Platform


View Profile WWW
October 30, 2015, 03:48:16 AM
 #13655

This round is getting ugly...

..Stake.com..   ▄████████████████████████████████████▄
   ██ ▄▄▄▄▄▄▄▄▄▄            ▄▄▄▄▄▄▄▄▄▄ ██  ▄████▄
   ██ ▀▀▀▀▀▀▀▀▀▀ ██████████ ▀▀▀▀▀▀▀▀▀▀ ██  ██████
   ██ ██████████ ██      ██ ██████████ ██   ▀██▀
   ██ ██      ██ ██████  ██ ██      ██ ██    ██
   ██ ██████  ██ █████  ███ ██████  ██ ████▄ ██
   ██ █████  ███ ████  ████ █████  ███ ████████
   ██ ████  ████ ██████████ ████  ████ ████▀
   ██ ██████████ ▄▄▄▄▄▄▄▄▄▄ ██████████ ██
   ██            ▀▀▀▀▀▀▀▀▀▀            ██ 
   ▀█████████▀ ▄████████████▄ ▀█████████▀
  ▄▄▄▄▄▄▄▄▄▄▄▄███  ██  ██  ███▄▄▄▄▄▄▄▄▄▄▄▄
 ██████████████████████████████████████████
▄▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄
█  ▄▀▄             █▀▀█▀▄▄
█  █▀█             █  ▐  ▐▌
█       ▄██▄       █  ▌  █
█     ▄██████▄     █  ▌ ▐▌
█    ██████████    █ ▐  █
█   ▐██████████▌   █ ▐ ▐▌
█    ▀▀██████▀▀    █ ▌ █
█     ▄▄▄██▄▄▄     █ ▌▐▌
█                  █▐ █
█                  █▐▐▌
█                  █▐█
▀▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▀█
▄▄█████████▄▄
▄██▀▀▀▀█████▀▀▀▀██▄
▄█▀       ▐█▌       ▀█▄
██         ▐█▌         ██
████▄     ▄█████▄     ▄████
████████▄███████████▄████████
███▀    █████████████    ▀███
██       ███████████       ██
▀█▄       █████████       ▄█▀
▀█▄    ▄██▀▀▀▀▀▀▀██▄  ▄▄▄█▀
▀███████         ███████▀
▀█████▄       ▄█████▀
▀▀▀███▄▄▄███▀▀▀
..PLAY NOW..
Richy_T
Legendary
*
Offline Offline

Activity: 2380
Merit: 2100


1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k


View Profile
October 30, 2015, 04:02:50 AM
 #13656

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.

1RichyTrEwPYjZSeAYxeiFBNnKC9UjC5k
nicklello
Member
**
Offline Offline

Activity: 193
Merit: 10


View Profile
October 30, 2015, 10:44:17 AM
 #13657

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
**
Offline Offline

Activity: 193
Merit: 10


View Profile
October 30, 2015, 10:53:32 AM
 #13658

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
**
Offline Offline

Activity: 76
Merit: 10


View Profile
October 30, 2015, 03:20:02 PM
 #13659

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
Sr. Member
****
Offline Offline

Activity: 266
Merit: 250



View Profile
October 30, 2015, 03:23:54 PM
 #13660

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.
Pages: « 1 ... 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 [683] 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 ... 814 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!