Endless sync BTC Knots

I’d be happy to help! I’m not clear on the question, from the conversation though. But I’ll take shot.

If you’re going to load an 8+GB UTXO set into 4GB of RAM, you’re going to have severe performance issues. If your drive has very high I/O, you may be able to “get away” with this configuration for the time being. But if you’re setting up new Bitcoin node, the initial block verification and sync will take an unreasonable amount of time.

@Rexter Thanks!
If you can, please share your understanding why the BTC Core & Knows versions were pretty fast on the same HW in UmbrelOS 1.4.2?
It took 5 days to sync the all blocks up to 100%.
Now under Start9OS 351 it has been running already for 5 days reaching 31%.

1 Like

I don’t know anything about UmbrelOS 1.4.2. But I do know their base server comes with 16GB of RAM. If UmbrelOS works better on that DIY device, you may want to stick with that. I suspect it won’t. There’s an important distinction to be had between “did” and “will.”

@moreloub - I asked the same question and have not received a satisfactory answer. There is something unique to Start9 min requirements that is being shared as a min requirement for all bitcoin nodes which is incorrect…it is a min requirement for Start9 to run Bitcoin, specifically Bitcoin Knots syncing process. I gave up having this same conversation and let my old MacMini sync with Knots with repeated RPC errors, and it took over a month, but now it works great as a Knots node with zero issues. I am still convinced there is an issue here worth looking at that is being portrayed as a problem with min hardware specs for Start9 + Bitcoin + Knots specific to non-standard hardware set up…

On your mini-PC, did it have a wifi controller on it that you are not using (I saw you were also using a LAN cable)? I ask, because my MacMini also had a wifi controller and I do not see a way to disable it in the OS. I was wondering if StartOS was trying to use it despite it not being connected and that is why it kept ‘ramming into a wall’ with RPC errors…just a theory I had.

1 Like

I’m down to test this. Stand by. I’ll put together, and explain my test environment.

2 Likes

Hi Rexter and community!
May you and possibly others who aware of the issue, share experiences about configuring resources available for Knots to run faster?

The main practical (and theoretical) issue is:

Why BTC sync on Start9OS 3.5.1 DIY runs significantly slower than on Umbrel 1.4.2 on the same HW ?
There was practical experience of running both for several months, however I decided to stick to Start9OS as more clean, secure and protected solution.
HW: miniPC Liva Z2-4100 CPU 4 core / 4GB / 7TB fast SSD, LAN cable to router, internet 600/60.
After increasing RAM to 8 GB it became a bit faster but still progressing 2-3 % per day already the forth week with very frequent delays “Timed out. Retrying soon…”.
The actual use of RAM by Knots (the only running service beside Start9OS itself !) is about 1,6-1,8 GB statistically.
I guess that some resource tuning can improve the results.
Any experiences and ideas guys?

I am interested to know the difference, and still plan to test this. But I’ve had limited time. Here is where I am so far:

Three machines, as identical as I can, with available hardware. These are the HP Elitedesk 800 G2 Mini PC
They have an Intel Core i5-6000
4GB PC4 RAM
1TB NVMe SSD

My plan is to run Bitcoin Knots 28.1.0 on each
Ubuntu 24.04
Umbrel 1.4.2
StartOS 0.3.5~1

I’ll be doing the IBD with default settings, – Clearnet enabled.

4 Likes

Would be really interesting experiment!

Yes, wi-fi is enable by default! It can be switched only using Debian terminal and relevant commands. I can do it , have not done yet due to shortage of time & root access limitation in Start9OS.
However, I share your suspicion!
Hope Rexter will clarify the issues during his experiment. :ok_hand:

Incorrect and unvalidated statement.
It works on any HW with 4 GB/1TB SSD however runs slower compared to computing with more resources.
Tested and proved. :angry:

Okay, I ended up going with Bitcoin 29.1. I would have preferred to use 28.1 since that the version we were on then this conversation started. But Umbrel doesn’t provide an easy way to install a previous version.

I’m on a 1GB/s Internet connection, so I’m planning on just starting all three of these at the same time, and see how it goes. Fresh install on Bitcoin Knots 29.1, with default settings:



Ready to commence.

Any objections, or concerns about my setup before I start the IBDs?

I don’t know of any reason wifi would be an issue here. If the interface is not connected, I would expect it to simply be ignored, as it would on any Debian based system. Now if wifi is configured, and the server is plugged in via Ethernet, perhaps there might be a conflict of some sort, but I really don’t think so.

These three Mini PCs don’t have wifi, but I can add usb wifi adapters if you want me to. I think I have three identical adapters I could use.

I’m going to start the IBD for all three of them at 03:00 UTC. I can always delete, and start over if anyone wants me to make any changes to the test environment. But I’d prefer to know before I start.

We’re now a little over 9 hours into this test. As we would expect, we’re making rapid progress, all three of them around 10% complete. This gives us the false impression that the IBD should be complete in 2 - 3 days.



We’re about 33 hours into this. Ubuntu, seems to be taking the lead at 51%. StartOS is now about the 36% point. Bitcoin on Umbrel appears to have crashed, so it’s likely going to be behind.



Day 6:

Bitcoin Knots on Ubuntu completed, most likely, yesterday. I was out of the town for about 36 hours, and it completed some time while I was away

Bitcoin Knots on Umbrel stops unexpectedly every few hours, so it’s not making much progress. Sometimes I can just restart Bitcoin Knots, and it resumes. Other times if I restart Bitcoin the entire system stops responding, and I have to hard power cycle the server.

Bitcoin Knots on StartOS is at 65.67%, and progress is getting noticeably slower.

1 Like

This test did not go at all, as I expected. But I think we can draw some conclusions here, and close the experiment. Namely, that @Mammoth is correct, in that 4-8 GB of RAM not being enough for Bitcoin is not a general Bitcoin problem, or a UTXO set problem, but a Bitcoin on StartOS problem. Now, I did notice that the default Knots for Ubuntu setup has a setting to not verify previous to a certain block. I don’t know if that’s the case on the other implementations. This might explain one reason Knots on Ubuntu completed faster, but this does not explain why Bitcoin on StartOS comes to an absolute crawl in the last 20 - 30 percent.

I think @morelub is on to something here. Some optimization of Bitcoin on StartOS might be worth consideration. Or at least better understood, and better explained on our part. Simply assuming that the UTXO set vs the RAM, is causing an unreasonable IBD time, does not appear to be correct.

With regards to Bitcoin coming to a crawl, @ThatLinuxDude did an interesting analysis that might be related.

1 Like

Wow, thanks for that detailed experiment, and thanks for linking my thread. I will post my findins there (still ongoing).

I just happen to have also a HP Elitedesk G2 800 mini with 8GB RAM, 2TB SSD, no Wifi but ethernet. Which should make our tests very comparble, besides the RAM difference.

Do you happen to still have access to the machines filesystem? If so, the debug.log file in the bitcoin datadir would be very helpful to have (you could also see when the Ubuntu node finished syncing and get an exact timeframe for the entire sync).

Plus I’d be asking if you can remember the utilization stats of Start9 via the Webdashboard (see my thread). The kernelspace CPU utilization % is something that I found highly suspicious (70-75% of total utilization where in kernelspace while overall CPU utilization was less than 50% during IBD which points to issues with I/O or drivers).

1 Like

I’d love for StartOS give us the ability to disable network adapters that are not in use. It would help rule out all kinds of potential problems with certainty, and limiting root access means you have to give GUI methods for such basic functions IMO…