BTC initial blockchain download is only at 40 blocks/hr

Hello all,

I have been trying to do my initial blockchain download and it is taking longer than expected. Currently, it is at 76% at a block height of 827k. Calculating the number of blocks verified per hour, I get only 40 blocks per hour. It will take 84 more days to complete at this pace.

Most of the time the number of peers is at zero or one.

I am running a Raspberry pi 5 with 8GB of RAM. Connected over ethernet.

2TB SSD

Upload/Download speed test at over 100Mps

I previously enabled the ā€œMake All Outgoing Connections to Clearnet Peers Over Torā€ setting. It increased my number of peers but did not increase the speed of syncing. It is now disabled.

I have increased the dbcache to 4000 MiBs.

I have read that the RAM speed is a bottleneck area but the live usage of the CPU is always less than 10% and the RAM usage is only around 400Mb

I thought maybe the temperature of the SSD was causing it to slow down so I put several heatsinks on it and have a large fan blowing on it at all times.

Here’s the SSD I have.

Does anyone have any suggestions?

I would reset the app to the default and be patient.

I have same problem with 2000 MB cache ram and no other settings modified, but hardware is a PC with 16Gb Ram (same T7 samsung) and is working so slow (more or less always at 74%) there is a solution or only wait and be calm?

Thanks for the response.

I am willing to be patient. However, I would feel reassured that others are experiencing this timeframe of over three months for the IBD. A friend of mine was able to the IDB in three weeks on a Mac mini with a 16Gb RAM.

I’m also interested in whether or not the number of peers contributes to the speed of the download. I assume that as long as there is one peer connection, the node is able to find and verify the past blocks. But does having ten or more peers speed up the process? The node can only download and verify the blocks in sequential order. The process has to be linear, right?

I also understand that the blocks mined in the last year are much ā€œdenserā€ and require more time and power to verify. Does that mean the closer the IBD gets to the current block the slower the rate of verification becomes? Will the time line of my synchronization asymptotically increase?

I’m so excited to have my node, I can’t sleep!

I ran into this same issue with the T7, been running at 100% for about a week now. Basically after trying countless different things over a few weeks time, gpt pointed me to the iowait time through htop and it pointed to the T7 as the culprit slowing things down. I basically synced the blockchain onto a different ssd using my MacBook, then transferred the files from that ssd to the T7 via the raspberry pi and I was up and running in a few days time.

Thanks for sharing your experience. Can I ask what RAM speed your Raspberry Pi and MacBook are?

Downloading the block to another SSD from a friend’s node seemed like another solution I could try. What did you need to do to get the blockchain file transferred to your Raspberry Pi? When I try to attach any hard drive from a Mac to my Raspberry Pi it won’t work. I guess they are not formatted the same? And I think I read that the Umbrel OS does not support external HD unless you have the Umbrel hardware itself.

I’m new to all this, so please correct me if I’m wrong.

Thanks.

Looking at the source, first lets try to see setting the bus to pcie3 helps. go into /boot as root and edit config.txt ans uncomment:

 dtparam=pciex1_gen=3

Since raspberry pi5 should be running at pcie3 mode.

Other tweaks we can do in bitcoin configuration file but adjusting things on the hardware first, then address the configuration file next.

Hi,

Thanks for the suggestion. As I read a few more threads about this, it seems changing the pcie from 2 to 3 on a Rpi could cause it to have ā€œerrors.ā€ Do you know if these errors would affect the IBD? Or is it something that would be fine during the IBD and then I could switch the Rpi back to pcie2?

If there’s a danger that changing it to pcie3 will make the node crash, causing me to start over, I’d rather just wait for 80 more days.

Thanks again for any information.

The Pi 5 is a pcie3 device and the M.2 hat is pcie3. But even when I didn’t have the hat, I put mine in pcie3 mode and it helped with everything. But there are other things too I did which was adding a heat sink on top of the Ethernet IC because I find that that overheats even on the pi4B and slows things down too.

But I never heard about setting it and crashing a PI5 since they are a PCIe 3.0 chip. But if you ever did, the red screen comes up and you can revert the config.txt to the default settings.

Also try the wifi

I’ve tried to edit the /boot/config.txt file using the command

sudo nano /boot/config.txt

The terminal says that the file is unwritable.

[ File ā€˜/boot/config.txt’ is unwritable ]

From what I’ve read, even when using the ā€œsudoā€ command, this could mean the SD card might be corrupted.

Any advice?

Then your SD card went bad. They go into read only when they reached their lifespan. Its the reason why I will never use the SD card slot on a Pi5. SD cards are not a good media for an OS.

I recommend updating your hardware, and get a M.2 hat and a 2TB nvme PCIe ssd.

But you said you were using a SSD drive. Which you should use a powered usb hub since the usb port is not usb compliant and does not deliver proper current to larger storage. Even large thumb drives (larger than 32 GB) have issue with it.

That is why I got a m.2 hat and a PCIe nvme because I didn’t want all that usb clutter with a power hub.

Update:

My average block download is increasing to 60 blocks per hour. I’m thinking that the blocks it is currently downloading and verifying have fewer transactions in them, or is it the block size?

The current block it’s verifying is 841517, which was around April of 2024. In the Blockchain.com graph below I see a dip in average transaction per block and average block size but in April 2024 it was obviously higher than any previous year.

But in this Mempool.space graph, it looks like the weight of the blocks is pretty consistent.

Which line would be the one to look at?

At this point, I am resigned to waiting for the IBD to complete and am not looking for ways to speed it up. But this experience has got me much more interested in the minutiae of it all.

Any thoughts on which of these graphs/lines is the one that corresponds to the speed at which the IBD is verifying blocks?

Thanks!

same. this new update is terrible…and there is 0 ways to run the older version. terrible decision, will seek alternative OS, it is that bad

I had almost the exact same problem. Stuck on 78%, no peers connected, nothing really happening for days.
I decided to wipe my SSD, install Umbrel OS on the SSD rather than on the SD card and start again. I will see if this makes any difference. I am on block 454103 right now after 11 hours running.

Did your speed improve?

I am also starting to wonder if Umbrel is the problem and thinking to just run core or knots on a spare Mac Mini I have

1 Like

Hello After 1 month more or less i’m at 79% and at the block 838777 and I have the message ā€œ06:38:59@794/error - Tunnels: Can’t create inbound tunnel, no peers availableā€ in the troubleshooting window of Bictoin core node. I opened the 8333 door but nothing changed…i’m using a new PC well equiped always connected with fiber optic cable…and now I prefer to download by my self the entire blochchain in other way … 1 month is too long !!!

The speed of the download came back down from 60 blocks an hour to 40 blocks an hour, on average.

My friend put Knots on a Mac mini several weeks ago and downloaded the blockchain in less than a week. My Umbrel Raspberry Pi combo is not the ideal setup, I guess.

At this point do I buy an old mini pc/mac mini and start over to get done sooner? Will the Raspberry pi continue to underperform in the near future?

I feel like the new Bitcoin app (1.0.3) is broken in some way. It should only take 2-3 weeks max.
I notice nobody from Umbrel seems to post here anymore or reply to threads so I’m beginning to think this project might be declining.
I have been downloading for 2.5 days now and I am on block 680810. Will see what happens when I get up to 830000 number, I feel like it’s going to crash again.
I am looking at Start 9 but also starting to think I might just run on Mac OS, I have a spare mac Mini.

how much ram you have?

because you need to set dbcache properly in the.conf file

for 8Gb of ram
dbcache=7516

for 4Gb of ram
dbcache=3072

Hi,

Do you mean in settings, optimization, cache size?
Mine is set to default which is 450mb