|
And PPOC finds the fifth block!
After I get back from dinner I will make a better post.
|
|
|
|
|
Well then I don't know what to tell you. Something strange is going on with your build machine. The Makefile you posted doesn't match the output of what should be there with RELEASE=1. The library it is complaining about comes as a part of the command line tools. Are you sure you have the proper versions of Xcode and the CLT installed for the version of the OS you're trying to use?
|
|
|
|
Hopefully you bring the luck with you and hit  |
|
|
|
What you posted doesn't make sense if you're trying to build on the old architecture (unless that's the mistake you fixed manually). Here's what happens when I run qmake RELEASE=1 USE_QRCODE=1: CC = clang
CXX = clang++
DEFINES = -DQT_GUI -DBOOST_THREAD_USE_LIB -DBOOST_SPIRIT_THREADSAFE -DUSE_IPV6 -DUSE_QRCODE -DUSE_UPNP=1 -DSTATICLIB -DHAVE_BUILD_INFO -DMAC_OSX -DMSG_NOSIGNAL=0 -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED
CFLAGS = -pipe -mmacosx-version-min=10.7 -mmacosx-version-min=10.5 -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk -O2 -arch x86_64 -Wall -W $(DEFINES)
CXXFLAGS = -pipe -stdlib=libc++ -mmacosx-version-min=10.7 -mmacosx-version-min=10.5 -arch i386 -isysroot /Developer/SDKs/MacOSX10.5.sdk -fstack-protector -O2 -arch x86_64 -fdiagnostics-show-option -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -D__NO_SYSTEM_INCLUDES $(DEFINES)
Your new error should be resolved by doing this in terminal: |
|
|
|
|
Back-to-back blocks for kano. You guys are on a hell of a roll today!
|
|
|
|
|
11... damn. Back-to-back blocks for Kano.
|
|
|
|
Yeah, kano's pool has been on fire today. Would love for some of that good luck to rub off here and get a couple nice quick green blocks |
|
|
|
|
Run qmake and post the contents of the Makefile it creates here.
|
|
|
|
|
90 blocks left... who's gonna walk away with the bonus coin?
|
|
|
|
Those settings are only applied if you're building the release. You'd have to run qmake RELEASE=1 for it to attempt to apply those settings. What does the Makefile look like - especially the CFLAGS and CXXFLAGS? It is there you'll find the architecture being used. For example, after running qmake USE_QRCODE=1 on my system, my Makefile looks like this: CC = clang
CXX = clang++
DEFINES = -DQT_GUI -DBOOST_THREAD_USE_LIB -DBOOST_SPIRIT_THREADSAFE -DUSE_IPV6 -DUSE_QRCODE -DUSE_UPNP=1 -DSTATICLIB -DHAVE_BUILD_INFO -DMAC_OSX -DMSG_NOSIGNAL=0 -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -DQT_SHARED
CFLAGS = -pipe -mmacosx-version-min=10.7 -O2 -arch x86_64 -Wall -W $(DEFINES)
CXXFLAGS = -pipe -stdlib=libc++ -mmacosx-version-min=10.7 -fstack-protector -O2 -arch x86_64 -fdiagnostics-show-option -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -D__NO_SYSTEM_INCLUDES $(DEFINES)
...
Notice the -arch x86_64. Also notice the min OS version: 10.7. Building for earlier versions of OS X requires you to have the proper SDKs installed, or that you build it directly on the older OS that contains the SDKs to which the build refers. |
|
|
|
As I stated to you in PM, the error is that you aren't providing an architecture to the compiler. You need to do something like "-arch native". If you're trying to build for old OS X, you'll probably want to use "-arch i386". Alphacoin? That code hasn't been touched in 3 years. Why are you trying to compile a dead coin wallet? By the way, here's AlphaCoin compiled on OS X 10.11.4:  It needs some help... the icon set is Litecoin... lol |
|
|
|
Yup, it'll be 2 BTC if you hit the block prior to the diff change and it's under 100% of expected shares. As of right now, you've got 121 blocks and just over 20% of shares |
|
|
|
A little incentive... If you hit the block before the diff change, I'll give you 1 BTC bonus on top of the current promotion. So, if you hit before the diff change and we are at 100% or fewer of expected shares you'll end up with 2 BTC on top of whatever you earned mining. I was going to put the 2 BTC into a rental - but figured it would be more fun this way  |
|
|
|
|
So, hammering bitcoind with GBT calls definitely makes it unhappy. Has someone done any benchmarking on this? It would be great to see how things pan out on different hardware specs vs calls to GBT.
|
|
|
|
It certainly would. My last rental came kind of close, popping a 115G share. Looks like Rozo's got a rental going now... come on, daddy needs a new pair of shoes!  |
|
|
|
|
The -daemon option runs it in the background. Without the option, it'll run in the foreground and will die when you hit control-c or if you shut down the terminal window.
|
|
|
|
|
I'm still researching this to give a better bug report.
It definitely boils down to calling getblocktemplate. I know there were a bunch of issues around memory (see jtoomin's posts about it), but that's not the problem I'm having here. The problem I'm seeing is that at some point - which almost always corresponds to a long time between blocks on the network - the coin daemon just gets stuck.
For example, I pulled one of the bitcoin daemons out of the pool and suddenly it's behaving perfectly normally. Block updates come through fine, CPU usage is virtually nil. Sure, you could argue that I could reduce the number of calls to getblocktemplate - but that doesn't solve the problem it merely tries to avoid it. If there's a limitation on calling getblocktemplate, I haven't seen it documented anywhere. It's not like I'm hardware or bandwidth limited, either. Unless I missed the notice somewhere that states you need 16 cores and 64G of RAM with 1GBit network to successfully use bitcoin daemon to call getblocktemplate every 5 seconds. As it is, I've tested this on machines (bare metal and VPS) ranging from 4 cores / 4G RAM to 8 cores / 32G RAM. On the 4 core / 4G RAM server, the effect was almost immediately noticeable. Any time network blocks took longer than a few minutes, the daemon would enter this zombie-like stuck state. On the 8 core / 16G RAM server, it would usually require blocks to not be found for around 45 minutes to an hour.
|
|
|
|
|
Some more information...
When the bitcoin daemon gets "stuck" I notice that CPU usage remains constant. For example, one of the servers is a quad-core Xeon processor (effectively 8 CPU). It's a dedicated server with 16G RAM and a 256G SDD running Debian 8.3. As the time passes between blocks, the CPU usage steadily creeps up until a new block is received, at which point the CPU usage drops. If too long passes between blocks being received (i.e. like the last block which took nearly an hour) the CPU usage levels out and the bitcoin daemon exhibits the behavior of being "stuck". Once that point is reached, no new blocks are received. Calling any function via bitcoin-cli results in either the call returning that it couldn't parse the results from the server, or a wait of quite a few seconds before it returns the results.
Restarting the bitcoin daemon immediately resolves the problem. The CPU usage drops to nearly zero. This cycle continuously repeats itself.
At no point is the server using anywhere over 8G of RAM total out of the 16G available. It doesn't even touch the swap (which is 4G).
I see this exact behavior on every single bitcoin daemon. I have tried daemons compiled from source and those precompiled and installed via the bitcoin repository. I see it on VPS instances as well as bare metal.
|
|
|
|
Good luck everyone . I look forward to sending one of you the bonus coins! |
|
|
|
|
Show Posts
