1

I have two RPi 4's running Bitcoin Core v25.0. One is 32-bit RPiOS and the other is 64-bit. 32-bit / 64-bit ARM versions of Bitcoin Core are installed respectively. Both computers are fitted with the same make/model of USB SSD drive for Bitcoin data. What could be causing this huge performance discrepancy?

Here's the specs of the two systems:

32 bit

$ uname -a
Linux zippi 5.10.103-v8+ #1529 SMP PREEMPT Tue Mar 8 12:26:46 GMT 2022 aarch64 GNU/Linux

$ getconf LONG_BIT
32

$ file `which bitcoind`
/usr/local/bin/bitcoind: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, stripped

64 bit

$ uname -a
Linux blockclock 6.1.21-v8+ #1642 SMP PREEMPT Mon Apr  3 17:24:16 BST 2023 aarch64 GNU/Linux

$ getconf LONG_BIT
64

$ file `which bitcoind`
/usr/local/bin/bitcoind: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, stripped

However, I am very surprised to see the performance on the 64-bit setup is much worse than the 32-bit system, by a factor of at least 10x. The following is the bench output from Bitcoin Core's debug log on each system as they process the same block.

32 bit

2023-10-15T11:30:51Z [bench]   - Using cached block
2023-10-15T11:30:51Z [bench]   - Load block from disk: 0.10ms [0.61s (0.56ms/blk)]
2023-10-15T11:30:51Z [bench]     - Sanity checks: 0.01ms [0.12s (0.11ms/blk)]
2023-10-15T11:30:51Z [bench]     - Fork checks: 0.07ms [0.03s (0.03ms/blk)]
2023-10-15T11:30:51Z [bench]       - Connect 2252 transactions: 93.99ms (0.042ms/tx, 0.010ms/txin) [769.89s (704.38ms/blk)]
2023-10-15T11:30:51Z [bench]     - Verify 9470 txins: 94.15ms (0.010ms/txin) [775.95s (709.93ms/blk)]
2023-10-15T11:30:51Z [bench]     - Write undo data: 33.30ms [31.67s (28.98ms/blk)]
2023-10-15T11:30:51Z [bench]     - Index writing: 0.12ms [0.02s (0.02ms/blk)]
2023-10-15T11:30:51Z [bench]   - Connect total: 129.61ms [809.13s (740.28ms/blk)]
2023-10-15T11:30:51Z [bench]   - Flush: 37.03ms [37.14s (33.98ms/blk)]
2023-10-15T11:30:51Z [bench]   - Writing chainstate: 0.18ms [0.04s (0.04ms/blk)]

64 bit

2023-10-15T11:30:52Z [bench]   - Using cached block
2023-10-15T11:30:52Z [bench]   - Load block from disk: 1.16ms [87.55s (237.27ms/blk)]
2023-10-15T11:30:52Z [bench]     - Sanity checks: 1.74ms [6.19s (16.72ms/blk)]
2023-10-15T11:30:52Z [bench]     - Fork checks: 19.49ms [6.00s (16.20ms/blk)]
2023-10-15T11:30:53Z [bench]       - Connect 2252 transactions: 1096.46ms (0.487ms/tx, 0.116ms/txin) [9787.89s (26453.75ms/blk)]
2023-10-15T11:30:53Z [bench]     - Verify 9470 txins: 1099.27ms (0.116ms/txin) [9794.32s (26471.12ms/blk)]
2023-10-15T11:30:53Z [bench]     - Write undo data: 22.48ms [33.33s (90.09ms/blk)]
2023-10-15T11:30:53Z [bench]     - Index writing: 0.50ms [0.55s (1.48ms/blk)]
2023-10-15T11:30:53Z [bench]   - Connect total: 1146.92ms [9860.73s (26650.62ms/blk)]
2023-10-15T11:30:54Z [bench]   - Flush: 737.86ms [440.64s (1190.91ms/blk)]
2023-10-15T11:30:54Z [bench]   - Writing chainstate: 0.18ms [0.59s (1.59ms/blk)]

for @jaromanda-x the lsusb outputs:

32 bit

$ lsusb
Bus 002 Device 002: ID 04e8:4001 Samsung Electronics Co., Ltd
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 1997:2433
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 4: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 4: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M

64 bit

$ lsusb
Bus 002 Device 002: ID 04e8:4001 Samsung Electronics Co., Ltd PSSD T7
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 3151:3000 YICHIP Wireless Device
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 1: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M
2
  • are there any messages in dmesg regarding the drive? I found this regarding the same device. Don't know what kernel version they were running, but they hoped to fix it by upgrading to 6.1 ... so ... there may well be some issue in the driver after kernel 5.10 Oct 16, 2023 at 22:47
  • not sure if it's possible for you to do this ... have you tried swapping the drives? it may be that the one on the 64bit system is "faulty" in some way! Oct 16, 2023 at 22:49

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.