# Node-RED on Raspberry Pi OS x64 WORKS!

**URL:** <https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065>\
**Category:** Share Your Projects\
**Created:** [19 March 2022 04:49 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065 "2022-03-19T04:49:19Z")\
**Posts on this page:** 20\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ricardo1982](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/ricardo1982/32/14173_2.png) [@Ricardo1982](https://discourse.nodered.org/u/Ricardo1982)\
**Post date:** [19 March 2022 04:49 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/1 "2022-03-19T04:49:19Z")

</div>

So I just installed the new **Raspberry Pi OS x64** on my Raspberry Pi 3B+ and I'm surprised how good it's working already and how fast it is on my Pi 3B+, how cool is that? Okay you do have to install Node-RED manually but you can use the same installation bash script that you'd use when you install it on the 32-bit version.

It's this one to be exact:

```auto
bash <(curl -sL https://raw.githubusercontent.com/node-red/linux-installers/master/deb/update-nodejs-and-nodered)

```

The new Raspberry Pi OS x64 doesn't have Node-RED installed by default so just use the bash script to install Node-RED and everything just works, I had no warnings, nothing abnormal except that it's way faster to finish.

Another nice thing that I saw that's new is that you now get the recommendation to create the settings file immediately after the setup is done, I highly recommend to make use of it also.

It's super easy now to get Node-RED up and running within 10 minutes at most complete with settings file, starting up the service automatically at boot and all.

I just wanted to share this with everyone that it even works on my old Raspberry Pi 3B+ so I would like to encourage everyone to update the OS to the 64-bit version and get Node-RED running.

I'm very excited that it just works the first time and I can't wait to work on a new project and please share if you've got the x64 OS with Node-RED running already, I'm curious if someone else already tried it.

---

<div class="post-metadata">

**Author:** ![cymplecy](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/cymplecy/32/2773_2.png) [@cymplecy](https://discourse.nodered.org/u/cymplecy)\
**Post date:** [19 March 2022 07:38 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/2 "2022-03-19T07:38:37Z")

</div>

And how much faster is it would you say?

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [19 March 2022 08:04 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/3 "2022-03-19T08:04:23Z")

</div>

That is interesting, I would not have expected it to make any significant difference. Are you sure you are not using a faster SD card than you did previously?

---

<div class="post-metadata">

**Author:** ![gerry](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gerry/32/21604_2.png) [@gerry](https://discourse.nodered.org/u/gerry)\
**Post date:** [19 March 2022 12:41 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/4 "2022-03-19T12:41:24Z")

</div>

I find speed statements interesting about 64 bit OS. Everyone always points to all you get is better memory handling but that's not all by a long shot. Someone in another thread posted several links to explanations about it and it is a huge difference. Moving from 32 bit bus to 64 bit bus I would expect a doubling of speed and those articles pretty well confirmed that. Plus better caching, and all sorts of under the hood optimization. 64 bit should make a huge difference. About a year ago I tried 64 bit and nothing ran, too early in the OS development. I'm going to give it another go now though, can't wait to see for myself.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [19 March 2022 14:13 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/5 "2022-03-19T14:13:24Z")

</div>

> [@gerry](#):
>
> Moving from 32 bit bus to 64 bit bus I would expect a doubling of speed and those articles pretty well confirmed that.

Can you provide a link to that please? I can't seem to find a link that suggests that.

---

<div class="post-metadata">

**Author:** ![krambriw](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/krambriw/32/5429_2.png) [@krambriw](https://discourse.nodered.org/u/krambriw)\
**Post date:** [19 March 2022 14:38 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/6 "2022-03-19T14:38:39Z")

</div>

x64 also feels really nice on a RPi4. I cannot really say I can compare in a professional way but I migrated a solution running on RPi3 to a RPi4 with x64 and now it is really fast, especially noticed when loading the flow in the browser (mainly due to RPi3 to RPi4 of course). Anyway, no problems noticed when running Node-RED (2.2.2), installation using the script worked without problems

---

<div class="post-metadata">

**Author:** ![gerry](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gerry/32/21604_2.png) [@gerry](https://discourse.nodered.org/u/gerry)\
**Post date:** [19 March 2022 18:01 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/7 "2022-03-19T18:01:31Z")

</div>

> [@Rasperry PI OS 64bit with Node-Red?](https://discourse.nodered.org/t/rasperry-pi-os-64bit-with-node-red/59760):
>
> Rasperry PI 64bit OS is now officially launched. Is there any concerns or benefit for Node-Red?

Haven't tried this before hope link works, look at very bottom

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [19 March 2022 21:52 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/8 "2022-03-19T21:52:17Z")

</div>

I can't see anything in those links that suggest that there should be anything like a doubling in speed.

---

<div class="post-metadata">

**Author:** ![gerry](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gerry/32/21604_2.png) [@gerry](https://discourse.nodered.org/u/gerry)\
**Post date:** [20 March 2022 05:42 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/9 "2022-03-20T05:42:05Z")

</div>

> **[Raspberry Pi OS 32-bit vs. 64-bit Performance Review](https://www.phoronix.com/scan.php?page=article&item=raspberrypi-32bit-64bit&num=2)**
>
> .

Try this one, you have to scroll a few pages but 48% speed increase  
[Edit] this one specifically says 64 bit is the way to go

---

<div class="post-metadata">

**Author:** ![krambriw](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/krambriw/32/5429_2.png) [@krambriw](https://discourse.nodered.org/u/krambriw)\
**Post date:** [20 March 2022 06:42 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/10 "2022-03-20T06:42:10Z")

</div>

> [@gerry](#):
>
> 48% speed increase

Far from double speed

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [20 March 2022 08:38 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/11 "2022-03-20T08:38:13Z")

</div>

Also, that is related to processor limited benchmarks, which ties up with what is said in the original post, that the improvement is mainly seen in benchmarks. In practice, in the sort of real world applications we usually deal with here, it is rare for processes to be CPU bound. So there may well be only a very small improvement. The one application that comes to mind where it may make a significant difference might be in video or image processing. If, on a 32 bit system handling video, it is seen that the processor regularly runs close to 100% running such a task then certainly the 64 bit OS may make a useful difference. Even so, I would only expect up to about 30% improvement I think.

---

<div class="post-metadata">

**Author:** ![krambriw](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/krambriw/32/5429_2.png) [@krambriw](https://discourse.nodered.org/u/krambriw)\
**Post date:** [20 March 2022 10:59 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/12 "2022-03-20T10:59:57Z")

</div>

> [@Colin](#):
>
> The one application that comes to mind where it may make a significant difference might be in video or image processing

This is something I think I will be able to check. Running the YOLO video analyzer for object detection on a RPi4 (32 bit) is a very tough task. I will try to run the same on the other RPi4 (64 bit) and see what the difference is

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [20 March 2022 11:10 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/13 "2022-03-20T11:10:37Z")

</div>

If the files are coming from SD card make sure it is the same speed of card.

---

<div class="post-metadata">

**Author:** ![krambriw](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/krambriw/32/5429_2.png) [@krambriw](https://discourse.nodered.org/u/krambriw)\
**Post date:** [20 March 2022 11:31 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/14 "2022-03-20T11:31:03Z")

</div>

I will send the image data from a separate computer to the python YOLO processes running on the respective RPi4 via MQTT

---

<div class="post-metadata">

**Author:** ![gerry](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/gerry/32/21604_2.png) [@gerry](https://discourse.nodered.org/u/gerry)\
**Post date:** [20 March 2022 12:47 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/15 "2022-03-20T12:47:55Z")

</div>

Yes, far from double, I saw 50% and got all excited. Mea Culpa. However, 48% is still a very noticeable improvement. I'm sure 64 bit would bring real world improvements just like moving from 8 bit to 16 bit to 32 bit. If you don't want to use 64 bit it's up to each individual but I'm going to start moving all my stuff over.

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [20 March 2022 13:29 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/16 "2022-03-20T13:29:59Z")

</div>

> [@gerry](#):
>
> If you don't want to use 64 bit it's up to each individual

I was not in any way suggesting that going to 64 bit is a bad idea. I was just saying that we should not expect huge performance benefits. I won't be moving many of my existing stable systems across as they are working perfectly well so there is no point. There is one that streams video and using Motion and ffmpeg and at times shows heavy processor utilisation, so I may well have a go at that one (all the time keeping the old SD card in case I have problems). I will not be at all surprised to find that some stuff has problems, which may take some sorting out.

---

<div class="post-metadata">

**Author:** ![krambriw](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/krambriw/32/5429_2.png) [@krambriw](https://discourse.nodered.org/u/krambriw)\
**Post date:** [20 March 2022 15:58 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/17 "2022-03-20T15:58:20Z")

</div>

> [@krambriw](#):
>
> I will send the image data from a separate computer to the python YOLO processes running on the respective RPi4 via MQTT

So I have done some tests, and yes, a nice improvement for the x64! Analyze is some 30% faster in the x64!!. Using CPU's, no GPU's involved

Both RPi4 w 4BG versions,  
32 bit

```auto
[INFO] YOLO took 5.527635 seconds
2022-03-20 16:53:48 [INFO] Person: 33.90% 6424.00 22

```

64 bit

```auto
[INFO] YOLO took 3.926258 seconds
2022-03-20 16:53:47 [INFO] Person: 33.90% 6424.00 22

```

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [21 March 2022 08:51 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/18 "2022-03-21T08:51:11Z")

</div>

Thanks for testing that.  
So certainly worth changing over on any systems that do have significant heavy duty processing to do.

---

<div class="post-metadata">

**Author:** ![Ricardo1982](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/ricardo1982/32/14173_2.png) [@Ricardo1982](https://discourse.nodered.org/u/Ricardo1982)\
**Post date:** [24 May 2022 03:08 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/19 "2022-05-24T03:08:38Z")

</div>

Sorry for the late answer, I have been benchmarking my Raspberry Pi 3B+ with the 64-bit OS and I see an overall improvement of about 25% running a stock config, after overclocking I get even more performance out of it maybe up to about 50%, with exactly the same settings as I was using with the 32-bit OS since I know that my settings run stable and continuously and the temperature of the CPU never gets above 55 degree Celsius even during benchmarking for 30 minutes it will stay below 55 degrees.

I'm keeping my Raspberry Pi cool with custom made heatsinks on the bottom memory chip I have a copper plate mounted, I also have a tiny heatsink on the topside directly on the network controller chip and another one one the chip next to it and I have an as big as possible heatsink on top of the CPU which also covers the wireless connection part, I made sure that I didn't short anything with the oversized heatsink and I modified the plastic case, basically I cut a big hole out of the top part and mounted a 12V computer fan on top at half the power blowing directly on top of the pcb and that works like a charm.

No need for expensive cooling towers or water cooling, just a simple pc fan is enough with the custom heatsinks to keep it below 55 degrees.

---

<div class="post-metadata">

**Author:** ![Ricardo1982](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/ricardo1982/32/14173_2.png) [@Ricardo1982](https://discourse.nodered.org/u/Ricardo1982)\
**Post date:** [24 May 2022 03:55 UTC](https://discourse.nodered.org/t/node-red-on-raspberry-pi-os-x64-works/60065/20 "2022-05-24T03:55:12Z")

</div>

**This is a long post with benchmark results for those who are interested**

Benchmarks are done with the latest version of sysbench on my Raspberry Pi 3B+ overclocked to 1500MHz.

Just to show what's possible I copied the output of the benchmark tests that I did below, I also added the commands that I used to set up sysbench, it may be useful because it changed quite significantly.

The first benchmark test I did is testing threads and limited it to 10,000 events as you can see below:

```auto
sysbench --threads=4 --time=0 --events=10000 --debug=on --validate=on threads run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 4
Debug mode enabled.

Validation checks: on.

Initializing random number generator from current time

Doing thread subsystem performance test
Thread yields per test: 1000 Locks used: 8
Initializing worker threads...

DEBUG: Worker thread (#0) started
DEBUG: Worker thread (#0) initialized
DEBUG: Worker thread (#1) started
DEBUG: Worker thread (#1) initialized
DEBUG: Worker thread (#3) started
DEBUG: Worker thread (#3) initialized
DEBUG: Worker thread (#2) started
DEBUG: Worker thread (#2) initialized
Threads started!

Event limit exceeded, exiting...
(last message repeated 3 times)
Done.

General statistics:
    total time: 15.9623s
    total number of events: 10000

Latency (ms):
         min: 5.78
         avg: 6.38
         max: 68.81
         95th percentile: 7.70
         sum: 63807.90

Threads fairness:
    events (avg/stddev): 2500.0000/33.59
    execution time (avg/stddev): 15.9520/0.00

DEBUG: Verbose per-thread statistics:

DEBUG: thread # 0: min: 0.0058s avg: 0.0063s max: 0.0603s events: 2528
DEBUG: total time taken by event execution: 15.9572s
DEBUG: thread # 1: min: 0.0058s avg: 0.0064s max: 0.0537s events: 2504
DEBUG: total time taken by event execution: 15.9539s
DEBUG: thread # 2: min: 0.0058s avg: 0.0063s max: 0.0688s events: 2524
DEBUG: total time taken by event execution: 15.9514s
DEBUG: thread # 3: min: 0.0058s avg: 0.0065s max: 0.0509s events: 2444
DEBUG: total time taken by event execution: 15.9454s

```

Then I did a benchmark for the CPU with the limit at 100,000 events, results below:

```auto
sysbench --threads=4 --time=0 --events=100000 --debug=on --validate=on cpu run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 4
Debug mode enabled.

Validation checks: on.

Initializing random number generator from current time

Doing CPU performance benchmark

Prime numbers limit: 10000

Initializing worker threads...

DEBUG: Worker thread (#0) started
DEBUG: Worker thread (#0) initialized
DEBUG: Worker thread (#1) started
DEBUG: Worker thread (#1) initialized
DEBUG: Worker thread (#2) started
DEBUG: Worker thread (#2) initialized
DEBUG: Worker thread (#3) started
DEBUG: Worker thread (#3) initialized
Threads started!

Event limit exceeded, exiting...
(last message repeated 3 times)
Done.

CPU speed:
    events per second: 2761.26

General statistics:
    total time: 36.2100s
    total number of events: 100000

Latency (ms):
         min: 1.33
         avg: 1.45
         max: 31.55
         95th percentile: 1.52
         sum: 144739.97

Threads fairness:
    events (avg/stddev): 25000.0000/149.42
    execution time (avg/stddev): 36.1850/0.01

DEBUG: Verbose per-thread statistics:

DEBUG: thread # 0: min: 0.0013s avg: 0.0014s max: 0.0270s events: 25033
DEBUG: total time taken by event execution: 36.1891s
DEBUG: thread # 1: min: 0.0013s avg: 0.0014s max: 0.0316s events: 25111
DEBUG: total time taken by event execution: 36.1722s
DEBUG: thread # 2: min: 0.0013s avg: 0.0015s max: 0.0247s events: 24747
DEBUG: total time taken by event execution: 36.1901s
DEBUG: thread # 3: min: 0.0013s avg: 0.0014s max: 0.0254s events: 25109
DEBUG: total time taken by event execution: 36.1886s

```

Because the above test are done so fast I did run two more tests that ran a bit longer to get the temperature up to the highest point which is 47 degree Celsius when I run the threads test, when I run the normal CPU performance test I don't see the temperature go higher than 42 degrees.

2nd threads test with the limit set to 40,000 events, results below:

```auto
sysbench --threads=4 --time=0 --events=40000 --debug=on --validate=on threads run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 4
Debug mode enabled.

Validation checks: on.

Initializing random number generator from current time

Doing thread subsystem performance test
Thread yields per test: 1000 Locks used: 8
Initializing worker threads...

DEBUG: Worker thread (#0) started
DEBUG: Worker thread (#0) initialized
DEBUG: Worker thread (#1) started
DEBUG: Worker thread (#1) initialized
DEBUG: Worker thread (#2) started
DEBUG: Worker thread (#2) initialized
DEBUG: Worker thread (#3) started
DEBUG: Worker thread (#3) initialized
Threads started!

Event limit exceeded, exiting...
(last message repeated 3 times)
Done.

General statistics:
    total time: 63.8808s
    total number of events: 40000

Latency (ms):
         min: 5.72
         avg: 6.39
         max: 151.23
         95th percentile: 8.74
         sum: 255445.60

Threads fairness:
    events (avg/stddev): 10000.0000/68.94
    execution time (avg/stddev): 63.8614/0.00

DEBUG: Verbose per-thread statistics:

DEBUG: thread # 0: min: 0.0057s avg: 0.0063s max: 0.0567s events: 10096
DEBUG: total time taken by event execution: 63.8596s
DEBUG: thread # 1: min: 0.0057s avg: 0.0064s max: 0.0829s events: 9919
DEBUG: total time taken by event execution: 63.8650s
DEBUG: thread # 2: min: 0.0057s avg: 0.0064s max: 0.0694s events: 9953
DEBUG: total time taken by event execution: 63.8559s
DEBUG: thread # 3: min: 0.0057s avg: 0.0064s max: 0.1512s events: 10032
DEBUG: total time taken by event execution: 63.8650s

```

2nd CPU performance test with the time limit set at 300 seconds (5 minutes), results below:

```auto
sysbench --threads=4 --time=300 --debug=on --validate=on cpu run
sysbench 1.0.20 (using system LuaJIT 2.1.0-beta3)

Running the test with following options:
Number of threads: 4
Debug mode enabled.

Validation checks: on.

Initializing random number generator from current time

Doing CPU performance benchmark

Prime numbers limit: 10000

Initializing worker threads...

DEBUG: Worker thread (#0) started
DEBUG: Worker thread (#0) initialized
DEBUG: Worker thread (#1) started
DEBUG: Worker thread (#1) initialized
DEBUG: Worker thread (#2) started
DEBUG: Worker thread (#2) initialized
DEBUG: Worker thread (#3) started
DEBUG: Worker thread (#3) initialized
Threads started!

Time limit exceeded, exiting...
(last message repeated 3 times)
Done.

CPU speed:
    events per second: 2752.74

General statistics:
    total time: 300.0011s
    total number of events: 825837

Latency (ms):
         min: 1.33
         avg: 1.45
         max: 34.85
         95th percentile: 1.61
         sum: 1199254.28

Threads fairness:
    events (avg/stddev): 206459.2500/346.86
    execution time (avg/stddev): 299.8136/0.01

DEBUG: Verbose per-thread statistics:

DEBUG: thread # 0: min: 0.0013s avg: 0.0015s max: 0.0336s events: 205927
DEBUG: total time taken by event execution: 299.8217s
DEBUG: thread # 1: min: 0.0013s avg: 0.0015s max: 0.0296s events: 206476
DEBUG: total time taken by event execution: 299.8171s
DEBUG: thread # 2: min: 0.0013s avg: 0.0015s max: 0.0348s events: 206537
DEBUG: total time taken by event execution: 299.8139s
DEBUG: thread # 3: min: 0.0013s avg: 0.0014s max: 0.0307s events: 206897
DEBUG: total time taken by event execution: 299.8017s

```