I’ve uploaded 2.1.0-RC8 on https://bitbucket.org/JordanLeePeershares/nubit/downloads
That should solve the performance issue CoinGame reported. It also improves the initial download.
Has the source code been updated as well, I mean the code on Bitbucket that is available for download?
I don’t want to compile on my RaPi just to find out, I have the wrong source code 
It looks like it is.
1 Like
Already running way better for me on Windows. Looking real good so far. I’m going to redo some tests once it fully syncs. Thanks @sigmike
Same problem here on Mint 17.3.
Nothing conclusive from the logs. Just peer connections.
Tried to delete peers.dat. Same thing.
Testing RC8, syncing is still very slow, sometimes application window is greying out for a few seconds on a machine with no load at all indicating stalling. Do we have a lack of nodes (still 8 connected), is it the performance of the nodes or a combination or is there still a bug in the client?
Haven’t tested without peers.dat but might not be relevant given willys response. I’m also still waiting to have at least one wallet synced on 2.1 RC8. Still 7 weeks behind and speed is around 3-6 Kb/s with some peaks a little higher. That results in a sync time from scratch of over 24h 
On a positive note, the memory requirements appear a lot lower, more testing is need to be conclusive though.
Is BerkeleyDB required for compiling because of the conversion features (to LevelDB)?
git status
# On branch v2.1.0-RC8
# Changes not staged for commit:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: makefile.unix
#
no changes added to commit (use "git add" and/or "git commit -a")
pi@redacted ~/downloads/nu/nubit/src $ make -f makefile.unix
g++ -c -O2 -pthread -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -g -DBOOST_SPIRIT_THREADSAFE -D_FILE_OFFSET_BITS=64 -I/home/pi/downloads/nu/nubit/src -I/home/pi/downloads/nu/nubit/src/obj -DUSE_UPNP=1 -DUSE_IPV6=1 -I/home/pi/downloads/nu/nubit/src/leveldb/include -I/home/pi/downloads/nu/nubit/src/leveldb/helpers -DHAVE_BUILD_INFO -fno-stack-protector -fstack-protector-all -Wstack-protector -D_FORTIFY_SOURCE=2 -MMD -MF obj/scanbalance.d -o obj/scanbalance.o scanbalance.cpp
In file included from scanbalance.cpp:5:0:
db.h:17:20: fatal error: db_cxx.h: No such file or directory
compilation terminated.
makefile.unix:190: recipe for target 'obj/scanbalance.o' failed
make: *** [obj/scanbalance.o] Error 1I exported the BerkeleyDB paths according to https://docs.nubits.com/nu-raspberry-minting/#installing-berkeleydb48-from-source---in-case-no-repository-with-compiled-packages-can-be-found
Now the compiling seems to continue.
edit:
compilling complete.
Started nud on my brave RaPi2.
Looks like it’s processing the blockchain files, right?
tail debug.log
2016-01-11 10:14:21 SetBestChain: new best=385cab0025f0b71aa06ed7f5b6d2f27ddda97239d0bb9baf0ffc8e650b41017f height=3416 log2_trust=31.558522 moneysupply(S)=1000116721.00 moneysupply(B)=0.00 tx=6599 date=2014-08-28 03:18:48 progress=0.000023
2016-01-11 10:14:21 ProcessBlock: ACCEPTED
2016-01-11 10:14:21 SetBestChain: new best=cafe1472f485e85e91b039b8cad8aa38b1b4d51c72d46185f2cb00871b526fb3 height=3417 log2_trust=31.559 moneysupply(S)=1000116761.00 moneysupply(B)=0.00 tx=6601 date=2014-08-28 03:25:34 progress=0.000023
2016-01-11 10:14:21 ProcessBlock: ACCEPTED
2016-01-11 10:14:21 SetBestChain: new best=13b7f1a8bb53804dd36cef517e4a6bd1de7fb803c98f0c59aeaebb095e7da710 height=3418 log2_trust=31.559478 moneysupply(S)=1000116801.00 moneysupply(B)=0.00 tx=6603 date=2014-08-28 03:29:11 progress=0.000023
2016-01-11 10:14:21 ProcessBlock: ACCEPTED
2016-01-11 10:14:21 SetBestChain: new best=27561549dca895bed83d780fa0c0f392732e13d272fe61384691009b81fefee3 height=3419 log2_trust=31.559956 moneysupply(S)=1000116841.00 moneysupply(B)=0.00 tx=6605 date=2014-08-28 03:51:34 progress=0.000023
2016-01-11 10:14:21 ProcessBlock: ACCEPTED
2016-01-11 10:14:21 SetBestChain: new best=dd4d55244e51e24aa38da8647cf6a5ec6f927ce03a58c3b08e1a5b5d73540ecf height=3420 log2_trust=31.560434 moneysupply(S)=1000116881.00 moneysupply(B)=0.00 tx=6607 date=2014-08-28 03:51:51 progress=0.000023
2016-01-11 10:14:21 ProcessBlock: ACCEPTEDedit2:
this will take for ages on a RaPi2
tail debug.log
2016-01-11 11:28:36 SetBestChain: new best=5ac301984b0bee8acb61cbcf282aae1f0e6ffd1b8eb266869b97a4cdf67d84f6 height=23589 log2_trust=34.505486 moneysupply(S)=1000921309.00 moneysupply(B)=2036447.1433 tx=47299 date=2014-09-26 03:13:16 progress=0.000164
2016-01-11 11:28:36 ProcessBlock: ACCEPTED
2016-01-11 11:28:36 SetBestChain: new best=b0cbebf8d19ff981ec8d399cae275893e3967b4691e6978f6a7a10a754867612 height=23590 log2_trust=34.505548 moneysupply(S)=1000921349.00 moneysupply(B)=2036447.1433 tx=47301 date=2014-09-26 03:13:27 progress=0.000164
2016-01-11 11:28:36 ProcessBlock: ACCEPTED
2016-01-11 11:28:36 SetBestChain: new best=cefeb31e65d8a4d2f4e4fa8c81ee3f03f563a1820640915e9b5bb864faffd376 height=23591 log2_trust=34.50561 moneysupply(S)=1000921389.00 moneysupply(B)=2036447.1433 tx=47303 date=2014-09-26 03:15:33 progress=0.000164
2016-01-11 11:28:36 ProcessBlock: ACCEPTED
2016-01-11 11:28:37 SetBestChain: new best=33d800c1f1ccfbeb3d1667a4ee5b86e52fffcf316bfe3607e6573d12d5529072 height=23592 log2_trust=34.505672 moneysupply(S)=1000921429.00 moneysupply(B)=2036447.1433 tx=47305 date=2014-09-26 03:15:48 progress=0.000164
2016-01-11 11:28:37 ProcessBlock: ACCEPTED
2016-01-11 11:28:37 SetBestChain: new best=07f524f0186f4acf0326fe0df9b457877969aa000892eb044790ecc05ee55cd8 height=23593 log2_trust=34.505734 moneysupply(S)=1000921469.00 moneysupply(B)=2036447.1433 tx=47307 date=2014-09-26 03:15:51 progress=0.000164
2016-01-11 11:28:37 ProcessBlock: ACCEPTEDedit3:
tail -n 2 debug.log
2016-01-11 13:15:05 SetBestChain: new best=3da2cb81cc5b60a39fe0b5de84a7e6cc51f526e20c31f6a8bffb93eda286c712 height=40955 log2_trust=35.314006 moneysupply(S)=1001614797.00 moneysupply(B)=2240448.7302 tx=82461 date=2014-10-09 15:06:46 progress=0.000286
2016-01-11 13:15:05 ProcessBlock: ACCEPTED
tail -n 2 debug.log
2016-01-11 14:51:39 SetBestChain: new best=a8259f5cb01ec832aba84c8a86bb14460dcf7291c970199e57ff02ecd4c6e62e height=56102 log2_trust=35.779953 moneysupply(S)=1002220451.00 moneysupply(B)=6280447.7432 tx=112908 date=2014-10-20 09:03:12 progress=0.000391
2016-01-11 14:51:39 ProcessBlock: ACCEPTEDRoughly 10,000 blocks per hour at the current position of the blockchain. Will report back in 3 days.
I am experiencing the same problem as Cybnate with the client hanging at the splash screen and connection failures in debug.log. Removing peers.dat did not help. I’m running Ubuntu 14 with the 32-bit binary. Have not tried to build from source.
Do you see a recent error in the log file?
Yes, the connection errors are piling up as the client is running. A connection refusal/timeout every 5–7 seconds.
It’s been several months since I’ve minted. My nu.conf is configured with:
addnode=198.52.160.71
addnode=198.52.217.4
addnode=198.52.199.75
addnode=198.52.199.46
addnode=162.242.208.43
addnode=192.237.200.146
addnode=119.9.75.189
addnode=119.9.12.63
Connection errors I find are usually fairly normal. You’ll have a big list of IP’s in the peer database and not all of them will always be available. Are you noticing that you get fewer connections with 2.1 than you do with 2.0.3 (let’s say over the course of like 30 minutes)?
@CoinGame Looking back through debug.log, it’s hard to determine previous node availability because I don’t see the timestamps that I’m presently getting. I haven’t been able to mint since early September 2015 and was never able to get 2.0.3 to synch.
I can report one impressive improvement of 2.1.0 compared to 2.0.3 - the memory consumption has, like announced, gone down - to roughly one third.
While nud 2.0.3 occupied above 700 MB, the nud 2.1.0 requires approximately 240 MB:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
25309 pi 20 0 441m 237m 9052 S 100.7 24.4 633:25.37 nudUpdate:
Memory usage went up:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
25309 pi 20 0 1043m 822m 0 S 178.2 84.5 3841:09 nudnud 2.1.0 is still converting the blockchain files:
tail -n 2 .nu/debug.log
2016-01-13 21:12:07 SetBestChain: new best=01a56356c21d1fb9bf604353ea2fd8c011ebc1f917a0a062b6be2c3a46bd229d height=472951 log2_trust=39.336951 moneysupply(S)=1007201549.1383 moneysupply(B)=4590212.0851 tx=962748 date=2015-08-07 13:34:45 progress=0.003326
2016-01-13 21:12:07 ProcessBlock: ACCEPTEDUpdate2
I needed to restart nud, because the RaPi2 started swapping. Now the memory consumption is low again:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28317 pi 20 0 508m 294m 7556 S 127.3 30.2 66:10.98 nud
3 Likes
Can confirm the reduced memory requirements on Linux, but on m y PC it is about 1Gb for Nu 2.03 and around 650Mb for Nu 2.1.
Something else which doesn’t appear to be right is the synchronization. Nu2.1 is 2-3 times slower than 2.03. Earlier I noticed that syncing Nu 2.1 is very slow, but this emphasizes it further.
nud got stuck at block 690,960:
nud getinfo
{
"version" : "v2.1.0-RC8-dirty-beta",
"protocolversion" : 2000000,
"walletversion" : 1,
"walletunit" : "S",
"balance" : 0.0,
"newmint" : 0.0,
"stake" : 0.0,
"parked" : 0.0,
"blocks" : 690960,
"moneysupply" : 833757804.61170006,
"timeoffset" : -4,
"connections" : 8,
"proxy" : "",
"ip" : "redacted",
"difficulty" : 0.000211,
"testnet" : false,
"keypoololdest" : 1452165519,
"keypoolsize" : 101,
"paytxfee" : 1.0,
"errors" : ""
}
tail -n 20 ~/.nu/debug.log
2016-01-15 08:26:00 accepted liquidity info from BEU9G1YCwCtaVa3mMPvX4NcqKngbA2jJ7C
2016-01-15 08:26:00 accepted liquidity info from B8DZADD7UrMkzEmTWyvn2cEoxcnog1D8MK
2016-01-15 08:26:00 accepted liquidity info from BA9tumP4zyM1g2M8ZNieD2iAnMgdVPuQe3
2016-01-15 08:26:00 accepted liquidity info from BA9tumP4zyM1g2M8ZNieD2iAnMgdVPuQe3
2016-01-15 08:26:01 accepted liquidity info from BA9tumP4zyM1g2M8ZNieD2iAnMgdVPuQe3
2016-01-15 08:26:01 received block d072c16c6205814dc239211af9352395236bbadf09862e36e981181e5cdac3c4
2016-01-15 08:26:01 ERROR: CheckProofOfStake() : INFO: check kernel failed on coinstake 55ce9710986bbe72ee4062454be5d7f6cd75fa5e5560f6b1d43fe0213655a1c1, hashProof=0000000000000000000000000000000000000000000000000000000000000000
2016-01-15 08:26:01 WARNING: ProcessBlock(): check proof-of-stake failed for block d072c16c6205814dc239211af9352395236bbadf09862e36e981181e5cdac3c4
2016-01-15 08:26:01 Flushed 9055 addresses to peers.dat 184ms
2016-01-15 08:26:08 ThreadRPCServer method=getinfo
2016-01-15 08:26:08 Misbehaving: 192.230.167.139:7890 (6 -> 7)
2016-01-15 08:26:09 accepted liquidity info from BA9tumP4zyM1g2M8ZNieD2iAnMgdVPuQe3
2016-01-15 08:26:09 accepted liquidity info from BEU9G1YCwCtaVa3mMPvX4NcqKngbA2jJ7C
2016-01-15 08:26:09 accepted liquidity info from B8DZADD7UrMkzEmTWyvn2cEoxcnog1D8MK
2016-01-15 08:26:09 accepted liquidity info from BEbkDnBh71ZaXHXkr63HXP4bMda9m9BN7B
2016-01-15 08:26:09 accepted liquidity info from BEbkDnBh71ZaXHXkr63HXP4bMda9m9BN7B
2016-01-15 08:26:10 accepted liquidity info from BA9tumP4zyM1g2M8ZNieD2iAnMgdVPuQe3
2016-01-15 08:26:10 accepted liquidity info from BA9tumP4zyM1g2M8ZNieD2iAnMgdVPuQe3
2016-01-15 08:26:10 accepted liquidity info from BA9tumP4zyM1g2M8ZNieD2iAnMgdVPuQe3
2016-01-15 08:26:10 accepted liquidity info from BA9tumP4zyM1g2M8ZNieD2iAnMgdVPuQe3I decided to restart nud.
Is that new - “nu-shutoff” after issuing “nud stop”? Haven’t recognized that before. Anyway: nice!
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
28317 pi 20 0 829m 652m 6880 R 100.0 67.0 1898:23 nu-shutoffAfter restarting nud, nud stopped. The debug.log shows:
tail -n 20 ~/.nu/debug.log
/bin/nud[0x5e234]
/bin/nud[0x5e234]
/bin/nud[0x5e234]
/bin/nud[0x5e234]
/bin/nud[0x5e234]
/bin/nud[0x5e234]
/bin/nud[0x5e234]
2016-01-15 08:42:01 ERROR: bool CBlock::ReadFromDisk(const CDiskBlockPos&)() : deserialize or I/O error
2016-01-15 08:42:01 ERROR: VerifyDB() : *** block.ReadFromDisk failed at 690915, hash=21c3ce1f5d0cb4828dce3753b2ce8fa5dfb1646a90c608582cb7310e1cd742b6
2016-01-15 08:42:01 : Corrupted block database detected.
Do you want to rebuild the block database now?
2016-01-15 08:42:01 Shutdown : In progress...
2016-01-15 08:42:01 Flush(false)
2016-01-15 08:42:01 DBFlush(false) ended 1ms
2016-01-15 08:42:01 StopNode()
2016-01-15 08:42:01 Flushed 0 addresses to peers.dat 11ms
2016-01-15 08:42:01 Committing 135 changed transactions to coin database...
2016-01-15 08:42:01 Flush(true)
2016-01-15 08:42:01 DBFlush(true) ended 0ms
2016-01-15 08:42:01 Shutdown : doneLooks like converting from BerkeleyDB to LevelDB can’t be done (due to SD card issues?) and I need to sync from scratch, right?
Are there already bootstrap files available for LevelDB?
Update:
syncing from scratch failed at block 8,776 from debug.log:
2016-01-15 10:27:41 WARNING: ProcessBlock(): check proof-of-stake failed for block 40b8290a5d783d1fcae0089e10c34378d87f35ab4604a758ef0ef1cf76b89d6c
And there’s a lot messages about misbehaving nodes in debug.log - whatever that means.
Another finding: it’s impressive how responsive nud is; right after starting it, issuing commands like nud getinfo is possible and lead to output.
I’ve started with syncing the blockchain from scratch once more.
Update2:
Syncing blockchain from scratch got stuck again at block 8,776.
I added
addnode=104.156.247.229
addnode=104.238.165.61
addnode=104.239.228.107
addnode=192.237.200.146
addnode=212.129.19.120
addnode=128.199.96.127
addnode=188.226.223.94(from Super nodes - for nu.conf ) to nu.conf, restarted nud and downloading the blockchain could be continued.
Update3:
nud on my RaPi2 (1 GB RAM) is syncing the blockchain awfully slow (only 46,198 blocks so far with 8 connections in the last 8 hours), but the memory comsumption is (in difference to the database conversion I tried before) constantly on very low level (approx. 125 MB!):
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29590 pi 20 0 332m 121m 8684 S 2.3 12.5 270:40.64 nud
1 Like
I’m seeing the same on my 1Gb and 2Gb Linux Debian VPS’s syncing very slow no matter what, but low memory usage of Nud, although 125Mb is a record. I haven’t seen it under 350Mb, 400-450Mb on average, peaks to 600Mb Haven’t encountered being stuck though yet, running for 3 days on a row now. RaPi Nud apparently behaves differently for some reason.
Berkeley DB is used for the conversion but it’s also still used for the wallet. So it’s still required.
1 Like
Sorry I haven’t posted an update here. Just got back from traveling and may have bricked my laptop trying to move everything over to a bigger hard drive. Fun times! Hopefully will get back into the grind by tomorrow
I did some tests on the initial download. It’s expected to be slower on 2.1 because everything is not kept in memory anymore so the blocks need to be loaded from disk on demand. So I/O speed is an important factor here. But even with optimal I/O and network conditions it’s still 2 times slower. We will try to improve that, but it may be better to start with a bootstrap file.
Does this mean downloading the blockchain from a trusted source instead of on the network initially?