I’ve compiled nud and it seems to work amazingly fast syncing from the network in comparision… I’ll keep you updated if anything shows…
Thanks for your hard work!
Progress so far:
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 185046I restarted nud and here we go.
2 Likes
Blockchain download finished - since yesterday!
It took less than 36 hours; impressive!
Wed Apr 13 06:17:33 UTC 2016
"blocks" : 1163,
[...]
Thu Apr 14 16:00:01 UTC 2016
"blocks" : 806993,
"connections" : 8,
Thu Apr 14 17:00:01 UTC 2016
"blocks" : 831128,
"connections" : 8,
Thu Apr 14 18:00:01 UTC 2016
"blocks" : 831170,
"connections" : 8,
1 Like
Does this mean 2.1.1 is fixed? I haven’t been able to follow along because its too technical for me. Just wondering what this means.
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.
4 Likes
I’ve enountered a different output of totalparked NBT between 2.0.3 and 2.1.1 - not for the first time!
"version" : "v2.1.1-RC1-15-gcf6a10f-beta",
"protocolversion" : 2000000,
"walletversion" : 1,
"walletunit" : "B",
"balance" : 0.0,
"newmint" : 0.0,
"stake" : 0.0,
"parked" : 0.0,
"blocks" : 841729,
"moneysupply" : 1292032.7599,
"totalparked" : 2100.5649,
[...]
"version" : "v2.0.3-dirty-beta",
"protocolversion" : 2000000,
"walletversion" : 1,
"walletunit" : "B",
"balance" : 0.0,
"newmint" : 0.0,
"stake" : 0.0,
"parked" : 0.0,
"blocks" : 841729,
"moneysupply" : 1292032.7599,
"totalparked" : 2252.8017,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.
I suggest we should fund more the testing of Nu 2.1.1 to accelerate the process.
1 Like
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.
2 Likes
I’m creating an issue for this. When you reset the 2.1.1 daemon does the value reset to the same value reported by 2.0.3 correct?
1 Like
I will check that.
I can confirm the difference between the two clients re total parked. Seeing the same difference in my clients (not daemons)
Hi everyone-
So the 2.1.x release has been worked forward for quite some time. Many high-priority defects have been fixed since the release candidate was made available – since when the team took a step back on pushing 2.1 due to quality issues. These are on the “Download_optimizations_r2” on Bitbucket.
The improvements so far include:
- deadlocks when starting the app / reindexing have been fixed
- issues surrounding wallet unlocking have been fixed
- greatly improved memory usage and footprint (by keeping a subset of the chain in memory)
- greatly optimized download performance
This code is being used by some on the production network and is showing stability.
That being said, there is more to do. The remaining issues are lesser impact, but must have be further diagnosed and have solutions so that we can consider the codebase ready for the next release candidate:
- assertion fails that have resulted in crashes when using the GUI
- inaccuracies in the UI: nubits parked, NSR shown in the UI
- continued high memory usage in long-running / highly-connected nodes
If anybody has detailed “steps to reproduce” the above defects, I’d be greatly appreciative.
Specifically to my efforts, it has been a mix at learning the codebase, setting up multiple dev and test environments (with repeatable processes), and authoring fixes + testing them. I will need to extend my learning in the GUI code, while at the same time spinning up more environments to “soak test” the code for long periods.
I remain committed to this work and I am honored to be working for JordanLee and with the devs – this is a great team who has and will continue to accomplish a lot. I wish my personal circumstances would allow for a larger time commitment.
It is imperative that these core changes get extensive ‘soak testing’, to make sure they are stable in the real world over days and weeks and not just in a dev environment for a few hours. The code is not just a merge from Bitcoin, but a refactoring to be compatible with the Nu codebase.
For those that have merged in the PR, compiled, and are running this latest code, thank you for your effort and help in testing.
For those that have the skill, but have not tried to set up a build environment to compile from source, this is my rally call for you to do so, since having more people who can compile the code from source will add to the community’s and network’s strength.
Thanks!
ps: A huge thank you and shout-out to CoinGame for helping along in 2.1.x with defect reporting, testing, and working this thread.
8 Likes
Thank you for the report!
Does that mean you continue with the limited time you have?
1 Like
@CoinGame, I filed a report at https://bitbucket.org/JordanLeePeershares/nubit/issues/235/211-reports-different-total-parked-value
I’m sure that the devs are aware of issues and will find the comments. Maybe somebody else wants to provide you with additional information from his/her client with regard to “totalparked” NBT.
For convenience:
###2.0.3
nud -unit=B getinfo | grep -v ip
{
"version" : "v2.0.3-dirty-beta",
"protocolversion" : 2000000,
"walletversion" : 1,
"walletunit" : "B",
"balance" : 0.0,
"newmint" : 0.0,
"stake" : 0.0,
"parked" : 0.0,
"blocks" : 856825,
"moneysupply" : 1301113.0143,
"totalparked" : 85682.1854,
"connections" : 8,
"proxy" : "",
"difficulty" : 0.0001667,
"testnet" : false,
"keypoololdest" : 1453190192,
"keypoolsize" : 101,
"paytxfee" : 0.01,
"unlocked_until" : 1561864572,
"errors" : ""
}###2.1.1
nud -unit=B getinfo | grep -v ip
{
"version" : "v2.1.1-RC1-15-gcf6a10f-beta",
"protocolversion" : 2000000,
"walletversion" : 1,
"walletunit" : "B",
"balance" : 0.0,
"newmint" : 0.0,
"stake" : 0.0,
"parked" : 0.0,
"blocks" : 856825,
"moneysupply" : 1301113.0143,
"totalparked" : 27060.9599,
"timeoffset" : -1,
"connections" : 8,
"proxy" : "",
"difficulty" : 0.0001667,
"testnet" : false,
"keypoololdest" : 1460528227,
"keypoolsize" : 101,
"paytxfee" : 0.01,
"errors" : ""
}Yes we’re aware. I replied on bitbucket as well. There appears to be many visual glitches with 2.1.1. @woodstockmerkle is focusing on the performance elements at this time and we’'re nearing stability from the performance changes. Then we can go through and iron out these cosmetic issues.
4 Likes
Because 2.1.1 was pulled down for various issues which have not been resolved.