blockmap.cpp: In member function ‘void BlockMap::cleanup()’:
blockmap.cpp:217:228: warning: format ‘%lld’ expects argument of type ‘long long int’, but argument 5 has type ‘std::set::size_type {aka long unsigned int}’ [-Wformat=]
nloaded, nLoadedNow, nLoadedSinceLastCleanup, setKnown.size(), mapPrev.size());
^
blockmap.cpp:217:228: warning: format ‘%lld’ expects argument of type ‘long long int’, but argument 6 has type ‘std::map<uint256, uint256>::size_type {aka long unsigned int}’ [-Wformat=]
In file included from /home/xev/nubit/src/leveldb/include/leveldb/slice.h:18:0,
from /home/xev/nubit/src/leveldb/include/leveldb/iterator.h:18,
from /home/xev/nubit/src/leveldb/include/leveldb/db.h:10,
from leveldb.h:9,
from txdb.h:9,
from blockmap.cpp:3:
blockmap.cpp: In member function ‘void BlockMap::assert_loaded(const CBlockIndex*) const’:
blockmap.cpp:226:20: error: could not convert ‘pindex->CBlockIndex::hashBlock’ from ‘const uint256’ to ‘bool’
assert(pindex->hashBlock);
^
makefile.unix:191: recipe for target ‘obj/blockmap.o’ failed
make: *** [obj/blockmap.o] Error 1
@exev@masterOfDisaster could you please do a fetch on the download branch and merge it again? @woodstockmerkle has resolved the issue. I was able to build successfully and i’m currently syncing.
edit: You fixed it!
I could compile nud successfully and started it with a fresh datadir only containing nu.conf.
I was impressed by the startup speed.
Seconds after I started nud, it was already syncing blocks.
I have developed the habit to tail -f the debug.log to see when nud is starting to get responsive for RPC.
So I started nud and tail right after that just to see that the first few hundred block had already been already processed!
I made a cronjob to log the block height each hour.
I’ll keep you updated.
So far it looks great!
Thanks, but what is in your opinion better?
The output and the behaviour is almost the same, except that terminating it requires more than CTRL+C and the output is stuttering.
tail -f can be stopped with CTRL+C, whereas less +F requires CTRL+C followed by Q - at least on my bash.
…but we digress from the topic of this thread.
As it’s educational we might receive a pardon for that
Wed Apr 13 06:17:33 UTC 2016
"blocks" : 1163,
Wed Apr 13 07:00:01 UTC 2016
"blocks" : 39007,
Wed Apr 13 08:00:01 UTC 2016
"blocks" : 76485,
Wed Apr 13 09:00:01 UTC 2016
"blocks" : 112783,
Wed Apr 13 10:00:01 UTC 2016
"blocks" : 144920,
Wed Apr 13 11:00:01 UTC 2016
"blocks" : 178225,
Remark: this is not on my RaPi, but my ASRock BeeBox.
With 30k to 40k blocks per hour, the whole sync might be done in one day, which would be amazingly fast.
As the blocks are always rather small due to the low number of tx, I don’t expect the sync speed to go down.
update:
nud got stuck and lost all connections. From debug.log:
2016-04-13 12:12:37 Misbehaving: 176.9.65.41:7890 (65 -> 66)
2016-04-13 12:12:37 IsInitialBlockDownload 0, nBestHeight 185046
2016-04-13 12:12:38 trying connection 104.239.228.107:7890 lastseen=298.8hrs
2016-04-13 12:12:38 connect() failed after select(): No route to host
2016-04-13 12:12:38 trying connection 128.199.96.127:7890 lastseen=306.3hrs
2016-04-13 12:12:39 connect() failed after select(): Connection refused
2016-04-13 12:12:39 trying connection 128.199.96.127:7890 lastseen=306.3hrs
2016-04-13 12:12:39 connect() failed after select(): Connection refused
2016-04-13 12:12:43 trying connection 104.239.228.107:7890 lastseen=298.8hrs
2016-04-13 12:12:43 connect() failed after select(): No route to host
2016-04-13 12:12:44 trying connection 128.199.96.127:7890 lastseen=306.3hrs
2016-04-13 12:12:44 connect() failed after select(): Connection refused
2016-04-13 12:12:47 trying connection 128.199.96.127:7890 lastseen=306.3hrs
2016-04-13 12:12:47 connect() failed after select(): Connection refused
2016-04-13 12:12:49 received block 45cef244464c60ef9e406733e83ca5a6ef9f4b922013111f98dbc45d55ad33b4
2016-04-13 12:12:49 ERROR: CheckProofOfStake() : txPrev not found
2016-04-13 12:12:49 WARNING: ProcessBlock(): check proof-of-stake failed for block 45cef244464c60ef9e406733e83ca5a6ef9f4b922013111f98dbc45d55ad33b4
2016-04-13 12:12:49 Misbehaving: 176.9.65.41:7890 (66 -> 67)
2016-04-13 12:12:49 IsInitialBlockDownload 0, nBestHeight 185046
I have no overview of all the issue tracker at Bitbucket for this project.
That being said, I believe the block download/processing speed was one of those.
The RAM consumption of the client is low, the block processing speed is high and the client is responsive (e.g. to RPC) soon after start.
It looks quite good so far.
The output is the same on the two 2.0.3 and the two 2.1.1 clients I checked.
So it doesn’t look like machine related, but related to the version of the client.
Can @CoinGame confirm? and what would be the suggested time for Nu service providers to upgrade to v2.1.1? Thank you.
@masterOfDisaster, I remember you mentioned an issue regarding V2.1.1 work with Nubot. I can’t find where it was posted now. May I ask is that issue fixed now? Thank you.
The issue was that I couldn’t make a connection from NuBot 0.4.1 to a nud 2.1.1 on the same machine (localhost).
Before I upgraded to 2.0.3 I was using the local nud.
At the moment it’s still using a remote nud 2.0.3, which works fine. I haven’t done any further troubleshooting so far.
It might be related to my setup.
The next test will be to use a remote 2.1.1.
The NuBots and nud from my setup run on Raspbian, btw.
Sorry for the delay. I’ve been using @woodstockmerkle’s 2.1.1 updates (using the instructions above) on my Supernode for some time now. It used to crash multiple times per day, but since using his branch it crashes less than once per week. Mind you this is on a VPS with 1 GB of RAM so we’re making good progress. Downloading speeds are vastly improved as well.
With all that said it’s still not in a state to give it an official production sign off otherwise we would deliver it as a release. But if anyone wanted to compile and run the binaries themselves it’s not like I can stop you . The daemon seems to be very stable. There still needs to be some work performed to resolve instability with the QT client.
. The daemon seems to be very stable. There still needs to be some work performed to resolve instability with the QT client.