Why Not Use 64-bit OS on RPi Model 3 and 4?

FlightAware ADS-B Flight Tracking
1

Why not switch to 64-bit OS on RPi 3 & 4?

The 64-bit is future of computing. Raspberry Pi has started 64-bit capable processor armv8l since RPi model 3. They have made available 64-bit version (beta) of Raspberry Pi OS since May 2020. DietPi and Ubuntu have also followed the suite and have released 64-bit versions for RPi.

I strongly recommend to use a SPARE microSD card to write the 64-bit image, and preserve existing microSD card with 32-bit OS and feeders as backup. This way if something goes wrong during ibstallation/operation of 64-bit system, or you dont like it, you can easily revert by slipping out 64-bit microSD card and slipping in preserved 32-bit microsd card.

 
……………………………………………………………………………
……………………………………………………………………………

STEP-1: Download and write one of the following 64-bit images to microSD card.

1. The 64-bit Raspberry Pi OS image can be downloaded from following pages:

Lite:
Index of /raspios_lite_arm64/images

Full:
https://downloads.raspberrypi.org/raspios_arm64/images/

2. The 64-bit DietPi OS image can be downloaded from following page:

https://dietpi.com/#downloadinfo

3. The 64-bit Ubuntu image for RPi can be downloaded from following page:

Install Ubuntu on a Raspberry Pi | Ubuntu

 
……………………………………………………………………………
……………………………………………………………………………

STEP-2: Install 64-bit version of dump1090-fa, piaware, piaware-web, and dump978-fa.

OPTION-1: Install 64-bit Pre-Built Packages of piaware, dump1090-fa, dump978-fa. This is a very easy option.

On 64-bit Raspberry Pi OS / 64-bit DietPi OS: CLICK HERE

On 64-bit Ubuntu 20 for RPi: CLICK HERE

OPTION-2: Build 64-bit Packages of piaware, dump1090-fa, dump978-fa from source-code right on your RPi CLICK HERE.

 
……………………………………………………………………………
……………………………………………………………………………

STEP-3: Install feeders of other sites on 64-bit OS on RPi 3 / 4 with (1) 64-bit Raspberry Pi OS Bullseye OR (2) 64-bit DietPi Bullseye OR (3) 64-bit Ubuntu 20 server Focal Fossa for RPi

(1) PREPRATION:

As most of other feeder sites have not yet released their 64-bit feeders, and currently only 32-bit feeders are available, we will install these on 64-bit OS by first adding architecture armhf to the 64-bit (arm64/aarch64) OS as follows:

sudo dpkg --add-architecture armhf   

sudo apt update

IMPORTANT: You must run “sudo apt update” to implement addition of armhf

Now check to confirm armhf has been added as “foreign-architecture”

sudo dpkg --print-architecture    

sudo dpkg --print-foreign-architectures

if the output of 2nd command is armhf, then it is confirmed that armhf has been added.

(2) INSTALLATION

(2.1) Flightradar24 feeder:

Install by following command:

sudo bash -c "$(wget -O - https://repo-feed.flightradar24.com/install_fr24_rpi.sh)"

When installation is completed, the installer will automatically take you to configuration stage. Enter your email, latitude, longitude elevation, and fr24key (if you already have the key, or leave it blank if you dont have).

IMPORTANT:
The process will take you to following question. Type yes to accept “autoconfig” and press Enter Key.

Would you like to use autoconfig (*yes*/no)$: yes

Complete rest of configuration process (enable/disable log), then restart fr24feed

sudo systemctl restart fr24feed

Wait for few minutes, then check status

sudo fr24feed-status

 

(2.2) Planefinder feeder:

Install by following commands:

wget -O pfclient_5.0.161_armhf.deb "http://client.planefinder.net/pfclient_5.0.161_armhf.deb"       

sudo dpkg -i pfclient_5.0.161_armhf.deb

 

To configure Planefinder feeder, in your browser go to following page and complete configuration:

  • Using Browser of same computer on which you have installed Planefider data feeder:
    localhost:30053
  • Using Browser of another computer on same Network:
    192.168.0.23:30053 (Repalce 192.168.0.23 by Local IP of computer on which you have installed Planefinder feeder)

 

(2.3) RadarBox24 feeder:

Install by following command

sudo bash -c "$(wget -O - wget http://apt.rb24.com/inst_rbfeeder.sh)"

(2.4) mlat-client for RB24 feeder:

To install mlat-client for RadarBox24 feeder, try following:

sudo apt install mlat-client

If it fails, use one of following two options:

Option A: Pre-built package from my Github site:

(2) Package for Raspi OS BULLSEYE (64-bit)

 

Option B: Build it on your RPi from source code

## Install required packages (dependencies and build tools)
sudo apt update  
sudo apt install -y git curl build-essential debhelper python-dev python3-dev   

## Download source code
git clone https://github.com/mutability/mlat-client.git   

## Build mlat-client's installation package
cd mlat-client   
sudo apt install -y dh-python   
sudo dpkg-buildpackage -b -uc   

## Above command will take some time to build package. 
## After the package is built, install it by following command
cd ../
sudo dpkg -i mlat-client_*.deb

 

(2.5) Adsbexchange feeder:

Install by following command:

wget -O /tmp/axfeed.sh https://adsbexchange.com/feed.sh   

sudo bash /tmp/axfeed.sh

 

(2.6) Performance Graphs:

Install by following command

sudo bash -c "$(wget -q -O - https://raw.githubusercontent.com/wiedehopf/graphs1090/master/install.sh)"

 

NOTE for 64-bit Ubuntu 20 server for RPi:
When I was installing graphs on 64-bit Ubuntu 20 server for RPi, the installation of package collectd-core failed and the script repeatedly tried to fix it but failed.

It seems the collectd-core package from Ubuntu repositories either has some bug or is outdated. Its version is 5.9.2.g-1ubuntu5.

I solved this problem by installing collectd-core from Debian package archives, instead of Ubuntu Repository. The version of package from Debian archives is 5.12.0-7 which seems newer.

Please see below the detailed procedure:

wget -O collectd-core_5.12.0-7_arm64.deb "http://ftp.us.debian.org/debian/pool/main/c/collectd/collectd-core_5.12.0-7_arm64.deb"    

sudo dpkg -i collectd-core_5.12.0-7_arm64.deb 

sudo apt-mark hold collectd-core
collectd-core set on hold.

apt-cache policy collectd-core
collectd-core:
  Installed: 5.12.0-7
  Candidate: 5.12.0-7
  Version table:
 *** 5.12.0-7 100
        100 /var/lib/dpkg/status
     5.9.2.g-1ubuntu5 500
        500 http://ports.ubuntu.com/ubuntu-ports focal/universe arm64 Packages

 

Restart graphs:

sudo /usr/share/graphs1090/boot.sh

Wait for 10 minutes, then update:

sudo /usr/share/graphs1090/graphs1090.sh 24h

 

 

 

 

5 Likes
2

I accept that a 32bit OS can only address 4Gb RAM, but unless you are using the 8Gb version, is there any benefit in going to a 64bit OS?

3

It’s one of those “how long is a piece of string” questions. You really need to benchmark the thing you care about to see if it actually benefits.

For aarch64 specifically, the 64-bit instruction set is a somewhat cleaner ISA (less legacy cruft) which might make for a nicer/faster microarchitecture, and you have wider registers to play with for arithmetic. Wider pointers mean you have a larger address space, but it also means you need more memory to actually store them (+ more memory bandwidth since your working set is a little larger). Both have similar NEON/SIMD capabilities; IIRC the 64-bit version of NEON has a few more instruction variants there which might be useful if hand-optimizing.

You won’t see the same sort of performance boost that x86-32 → x86-64 got, because much of that boost was from the larger register set available in x86-64 (x86-32 was really register-starved); ARM doesn’t have the same problem.

(trivia: if you didn’t need the extra address space, the 64-bit SPARC ISA tended to run slower than 32-bit SPARC, at least on older ultrasparcs)

From a FlightAware/Piaware point of view the extra maintenance cost of maintaining two architectures and two images (+ having to avoid problems with users trying to use a 64-bit image on a 32-bit-only Pi) is pretty high, and I haven’t seen a measurable performance difference in my (limited) benchmarks, so I don’t anticipate a change in the “official” images any time soon. We may start building aarch64 packages for the FA repository once Raspbian 64-bit is out of beta.

4 Likes
4

Developing and maintaining just one version of the software, drivers.
We saw that happen in Android.

5

Some benchmarking tests ended up in a small performance improvement using 64bit. But the more question is if you can really benefit in the daily operations from it.

In terms of flight feeding i would give this question a “no”

6

Raspberry PI foundation officially announced the 64-bit version:

Raspberry Pi OS (64-bit) - Raspberry Pi

2 Likes
7

 

 

Download Page

https://www.raspberrypi.com/software/operating-systems/#raspberry-pi-os-64-bit

 

 

1 Like
8

Index of /raspios_arm64/images (raspberrypi.org)

1 Like
9

@prog
@wiedehopf

For AirSpy, is 64-bit OS better than 32-bit OS?

10

Raspberry Pi OS Lite

Release date: January 28th 2022
System: 64-bit
Kernel version: 5.10
Debian version: 11 (bullseye)

CLICK ON SCREENSHOT TO SEE FULL SIZE

image
image793×598 50.1 KB

11

I was operating my Airspy initially on Buster 32 bit and have it currently running as test bed on Bullseye 64-bit. But i used the installer provided by wiedehopf to get the Airspy installed. Currently i don’t know if a 64-bit version is even installed.

I can’t say that there is an obvious difference, but the two technical guys can answer this surely a lot better :slight_smile:

12

Don’t remember numbers, but pretty sure it was single digits percent faster on 64bit.
Not necessarily due to the architecture, my guess is that compilers for arm64 are better optimized.

You’ll be on a 64bit binary, you need to jump through some hoops for armhf binaries on arm64.

4 Likes
13

I don’t think I ever run airpsy as a 32 bit application.
If Windows is 64 bit, the 32 bit application needs to be “translated”, so it’s slightly slower.
On 64 bit Ubuntu, you need to force load the 32 bit dependencies. All Ubuntu packages are multiarch capable and you can install different architecture packages in your system, but I don’t know what that does for speed. Are they running like in a local virtual machine?

14

Not in the usual sense of a VM. Typically processors have a number of different execution modes they can switch between which e.g. changes the set of available instructions (e.g. the kernel is running in a more privileged mode which allows full access, while userspace is more limited in what instructions it may execute and which resources it can touch). 32-bit vs 64-bit is often just a different processor mode, so the kernel will just keep track of the mode that each process expects to run in and switch to that when handing control back to userspace, it’s not fundamentally different to what it has to do when everything was 64-bit.

Trying to manage a mix of 32-bit and 64-bit userspace processes and a 64-bit kernel that want to exchange and share data gets a little more complicated (the 32-bit and 64-bit ABIs usually look different) but that’s mostly a matter of bookkeeping & data translation at the kernel/userspace boundary.

1 Like
15

Thanks for the reply. I should have been more specific with my question.
I’m all for keeping the number of supported versions to a minimum, which is of course why FA doesn’t offer images for Pi-like boards.
IIRC, when windows started to go 64bit, most software was the same code recompiled offering no performance improvement at all.

After reading the instructions of how to install / configure a 64bit OS, I was wondering if ABC~ sees a benefit of doing it at this stage?

  • CPU load, memory use, temp, …
    or it’s just one of those ‘coz you can’ things.
16

Quote from https://www.raspberrypi.com/news/raspberry-pi-os-64-bit/

"But we’ve come to realise that there are reasons to choose a 64-bit operating system over a 32-bit one. Compatibility is a key concern: many closed-source applications are only available for arm64, and open-source ones aren’t fully optimised for the armhf port. Beyond that there are some performance benefits intrinsic to the A64 instruction set: today, these are most visible in benchmarks, but the assumption is that these will feed through into real-world application performance in the future.

A more theoretical concern is that 32-bit pointers only allow you to address 4GB of memory. On Raspberry Pi 4, we use the ARM Large Physical Address Extension (LPAE) to access up to 8GB of memory, subject to the constraint that any process is limited to accessing 3GB (we reserve the top 1GB of the virtual address space for the kernel). Very few processes require more memory than this: happily Chromium, which is probably the most memory-intensive application in Raspberry Pi OS, spawns a process per tab. But some use cases will benefit from being able to allocate the entire memory of an 8GB Raspberry Pi 4 from a single process."

1 Like
17

With the old decoder the 64 bit version was definitely faster and resulted in lower cpu usage. With the revised decoder, the single core version allowed a higher pre-amble filter but the difference wasn’t huge. With the current multi-threaded version I doubt there’s going to be much difference if any noticeable since the cpu doesn’t really limit it now.

That’s why I switched back to using 32 bit when I needed to rebuild my pi a while back. At the moment most things relevant for adsb are expecting a 32 bit OS and it’s not worth the hassle to make it work properly on 64 bit. Switching over was also annoying as for some reason the data format used by collectd changes depending on the architecture, so I had to export it and re-import it. :man_shrugging:

1 Like
18

Who could possibly need more than 640k

Apparently I still haven’t adequately described my question.

  • the 4Gb limitation is self evident
  • 64bit closed source apps is fair enough (if it is relevant)

but night now, is there any tangible benefit installing a 64bit OS?

19

At present running 64-bit would be more a personal choice than necessity. The hard fork in the road would seem to be when Debian drops 32-bit support. I run 32-bit unstable/Sid on an old laptop, but I can’t say that means they are committed to a 32-bit stable/Bookworm release in a few years time. We’ll see.

20

Not sure if he was ever asked again about that statement :wink:

At least for Microsoft Windows the answer is yes. Reason: More and more software developers moved their applications to 64bit only.

But who is running Windows on a 4GB device? This must be a very patient person.

Just read that also Ubuntu is not available any longer as x86 (Intel/AMD) version since 2019