# RPI 4 and Ignition

**URL:** <https://forum.inductiveautomation.com/t/rpi-4-and-ignition/37072>\
**Category:** Maker\
**Created:** [July 24, 2020, 9:24pm UTC](https://forum.inductiveautomation.com/t/rpi-4-and-ignition/37072 "2020-07-24T21:24:50Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![tordvd](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tordvd/32/11525_2.png) [@tordvd](https://forum.inductiveautomation.com/u/tordvd)\
**Post date:** [July 24, 2020, 9:24pm UTC](https://forum.inductiveautomation.com/t/rpi-4-and-ignition/37072/1 "2020-07-24T21:24:50Z")

</div>

Just a FYI for those wondering if Ignition can run on a RPI 4.

I have been running stable for some weeks now, and my experience is that it works great!

I was a bit worried for a while. But I saw that the mobile phone actually demanded a good wifi connection. Previously i was on 2.4Ghz, but when i swapped (on my phone) to 5Ghz everything went smooth.

Not only am i running Ignition, but im also running the following images (through Docker):

- 2x Nodered images ( one for dev)
- mySQL (mariaDB not supported by docker)
- Home assistant (for z-wave devices)
- Mosquitto (not actually needed as MQTT Distributor is available in Maker
- portainer

I only run those modules I need for the moment, so I dont know if adding more modules will increase the load on the RPI:

- perspective
- opc-ua
- tag-historian
- MQTT Engine
- Twilio Integration and Alarm Notification

Tag count:  
 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/a/e/ae33001643c1dd528bcba6863d8ea5a32d49d610.png)

Here is the CPU and memory utilization reported from Ignition:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/f/3/f3ea94a32ff8ab3c721e37c491127a8b23560003.png)

Below is the CPU and memory reported from Raspberry Lite OS

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/e/c/ec95a4ee29d89afd1712bdf0f2255ada5eecf2e3.png)

Free memory kind of steadily fell down to zero, I guess its freeing itself when needed. The figure below is from htop:

 ![image](https://us1.discourse-cdn.com/inductiveautomation/original/3X/1/2/12b9e405d51b56b8a9feb77331e51c79a026e414.png)

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [July 25, 2020, 12:40am UTC](https://forum.inductiveautomation.com/t/rpi-4-and-ignition/37072/2 "2020-07-25T00:40:01Z")

</div>

> [@tordvd](#):
>
> I guess its freeing itself when needed

That's normal for Linux. It uses all memory that would otherwise be free to extend the disk cache. Oldest clean disk page can be turned over to an app in an eyeblink.

---

<div class="post-metadata">

**Author:** ![tordvd](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tordvd/32/11525_2.png) [@tordvd](https://forum.inductiveautomation.com/u/tordvd)\
**Post date:** [July 25, 2020, 9:05am UTC](https://forum.inductiveautomation.com/t/rpi-4-and-ignition/37072/3 "2020-07-25T09:05:30Z")

</div>

Good to know:)

---

<div class="post-metadata">

**Author:** ![Kevin.Collins](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.collins/32/13497_2.png) [@Kevin.Collins](https://forum.inductiveautomation.com/u/Kevin.Collins)\
**Post date:** [July 26, 2020, 2:53am UTC](https://forum.inductiveautomation.com/t/rpi-4-and-ignition/37072/4 "2020-07-26T02:53:19Z")

</div>

A relevant update to mention here is that the latest 8.0.15 release introduces AARCH64 (64-bit ARM) support. I just recently spun up the latest release on Raspberry Pi OS 64-bit Beta under Docker with success! So things are looking pretty good on the RaspPi/Ignition front lately! It will be nice once Raspberry Pi OS (which is apparently now the name of it vs Raspbian) is _officially_ 64-bit. 🙂

---

<div class="post-metadata">

**Author:** ![tordvd](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tordvd/32/11525_2.png) [@tordvd](https://forum.inductiveautomation.com/u/tordvd)\
**Post date:** [July 26, 2020, 7:27am UTC](https://forum.inductiveautomation.com/t/rpi-4-and-ignition/37072/5 "2020-07-26T07:27:45Z")

</div>

Good to know! Im going to switch image as soon as 64bit Rasperry pi OS is officially stable with a Lite version.

Someone know how much performance increase Ignition will get in a 64bit ARM contra 32bit?

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [July 26, 2020, 1:35pm UTC](https://forum.inductiveautomation.com/t/rpi-4-and-ignition/37072/6 "2020-07-26T13:35:15Z")

</div>

Probably a performance loss, not a gain. Native code gets bigger by a small % with 64-bit instructions and constants, so instruction cache misses go up. Using 64-bit is an _ **enabling** _ technology, not a performance boost. That is, it _ **enables** _ applications/algorithms that need (or benefit from) more than 2GB of RAM.

---

<div class="post-metadata">

**Author:** ![tordvd](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tordvd/32/11525_2.png) [@tordvd](https://forum.inductiveautomation.com/u/tordvd)\
**Post date:** [July 26, 2020, 6:00pm UTC](https://forum.inductiveautomation.com/t/rpi-4-and-ignition/37072/7 "2020-07-26T18:00:46Z")

</div>

I get what you are saying, but overall I think its more than just RAM advantages.

I thought that architecture programmers always optimized for 64bit architecture these days. And was hoping that maybe we would get a boost from that. (and maybe Inductive programmers has some affinity for 64 bit architecture.)

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [July 26, 2020, 8:42pm UTC](https://forum.inductiveautomation.com/t/rpi-4-and-ignition/37072/8 "2020-07-26T20:42:23Z")

</div>

I think Inductive Automation, as a whole, has an affinity for reduced support effort… not that I blame them. (:

---

<div class="post-metadata">

**Author:** ![tordvd](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tordvd/32/11525_2.png) [@tordvd](https://forum.inductiveautomation.com/u/tordvd)\
**Post date:** [July 27, 2020, 6:20am UTC](https://forum.inductiveautomation.com/t/rpi-4-and-ignition/37072/9 "2020-07-27T06:20:27Z")

</div>

Not sure I get you there. Would you mind elaborating? 🤔

---

<div class="post-metadata">

**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\
**Post date:** [July 27, 2020, 12:27pm UTC](https://forum.inductiveautomation.com/t/rpi-4-and-ignition/37072/10 "2020-07-27T12:27:08Z")

</div>

Fewer platform combinations ==\> less development effort and less QA up front, and then less training effort for support reps and less complexity for bug fixes.

---

<div class="post-metadata">

**Author:** ![tordvd](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/tordvd/32/11525_2.png) [@tordvd](https://forum.inductiveautomation.com/u/tordvd)\
**Post date:** [July 27, 2020, 8:18pm UTC](https://forum.inductiveautomation.com/t/rpi-4-and-ignition/37072/11 "2020-07-27T20:18:26Z")

</div>

Aha. Yes that seems like a ton of overhead 😵

One ring to rule them all!
