Any chance nud 2.0 and bcexchanged could not get along on a Raspberry Pi2? My nud is minting blocks rather rarely now that I upgraded to nud 2.0 and also installed bcexchanged on the same system to be ran in parallel. I cannot debug it since I’m far away from the Pi but there have been some hiccups with the daemons. With the previous version of nud (lesser than 2.0) I once found it unresponsive and had to kill -KILL it. Right now I can see bcexchanged minting blocks successfully but nud hasn’t found a single block today. There’s a chance it has stopped working but the process didn’t terminate so it won’t be restarted by my script.
I have nud 2.0.0 and bcexchanged running on the same RPI2.
They run fine in parallel:
bcexchanged getinfo
{
"version" : "v3.0.0-unk-beta",
[...]
"blocks" : 71775,
"moneysupply" : 186284.0082,
[...]
nud getinfo
{
"version" : "v2.0.0-dirty-beta",
[...]
"blocks" : 498580,
"moneysupply" : 875857144.99880004,
[...]
But I can’t tell you about minting…
nud is memory intensive… something like twice as much as bcexchanged. Unless you have the R-pi 2, Nud itself could use up all physical memory and need swap space (it will still find blocks). If you run nud and bcexchanged on the same R-pi B or B+ (both are versions of R-pi 1) I can imagin nud getting bogged down.
Yes I suspected the same thing. At some point nud was unable to boot up, so it froze. I suspected it ran out of memory so after adding a swapfile it booted up normally. However, I removed the swapfile because later both instances were able to run together. I have Pi2 though, so it has 1 GiB of RAM.
Way more memory required for nud than for bcexchanged:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
25561 pi 20 0 650m 524m 41m S 12,2 53,9 856:57.84 nud
20943 pi 20 0 226m 111m 37m S 2,3 11,4 439:44.42 bcexchanged
the output is from a RPI2 which has 1 GB.
The 512 MB on a RPI1 wouldn’t be enough to run nud without using swap.
I suspect there should be done some memory optimizations and configurations to respect some memory limit at the cost of speed. I also wonder how big is the threat of memory fragmentation with bitcoin based cryptocurrency implementations. The OS might not be able to free the unused memory after heavy fragmentation. As a counter measure I would propose spawning a child process from nud that would do the memory intensive stuff and clone its state once in a while into another child process so that fragmentation would be taken care of automatically.
The percentage of blocks found by 2.0 minters is now 88.25%.
It is certainly true that the Nu client takes a lot of memory. It is something sigmike and I discussed and decided some time ago to fix in the 2.1 release. Block metadata for the entire blockchain gets held in memory. This hasn’t been a problem for Bitcoin or Peercoin because their blocks have very little metadata. Nu blocks have quite a bit of extra metadata, such as shareholder votes. Our blockchain is currently mostly metadata, which means most of the blockchain is held in memory. So we will only retain most types of metadata in memory for a period of 10,000 blocks. I expect Nu 2.1 will be released in a matter of weeks.
3 Likes
what about “cold wallet” minting? are you waiting PPC first?
Based on the recent rate of change, we can expect the 90% threshold will be passed at around 20:00 UTC, in about six hours. So that is when the protocol change will occur, approximately.
2 Likes
A flexible protocol change time should be seen as a feature that allows the protocol to migrate when the network is ready.
Maybe for some situations the protocol change happens at a predictable future moment is desireable (for example so servers can restart at a certain moment after giving users sufficient warning time). To accomodate this need the protocol change can set to happen e.g. 700 blocks (~12 hours) after the current criteria are met.
1 Like
I agree there is value in knowing the exact time of the protocol change. I’m inclined to think the optimal delay is more than 12 hours, however. What does everyone think about a week?
1 Like
Fine. There would be a bigger chance for node percentage to drop below 90% (for example key big shareholders get off line). The change decision has to be “final” once the criteria are met.
Indeed. The code already works that way. If the percent minting with the new protocol drops below 90% after exceeding it, the protocol version will not revert back.
1 Like
Then there’s only advantages of postponing the protocol switch for some days after criteria have been met, but no disadvantages, right?
The disadvantages are the cost of implementation and the increase in protocol complexity. However, I believe the benefits outweigh the disadvantages.
89.55% of blocks minted are on version 2.0 at this point. The switch should occur in about an hour.
1 Like
The switch occurred about 10 minutes ago. Everything is working as expected.
6 Likes