# Cardano node 1.30.1 ARM64 (aarch64) compiled binaries

**URL:** <https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112>\
**Category:** Operate a Stake Pool\
**Created:** [5 October 2021 03:30 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112 "2021-10-05T03:30:31Z")\
**Posts on this page:** 19\
**Page:** 1

<div class="post-metadata">

**Author:** ![kaverne](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/kaverne/32/46048_2.png) [@kaverne](https://forum.cardano.org/u/kaverne)\
**Post date:** [5 October 2021 03:30 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112/1 "2021-10-05T03:30:32Z")

</div>

As for every release please find here the free to download binaries for 1.30.1 on ARM architecture (aarch64).  
GHC used is version 8.10.7 from last august.

[1.30.1 cardano-cli](https://s3.ap-southeast-2.amazonaws.com/www.myadanode.com/cardano-node/1.30.1/aarch64/cardano-cli)  
[1.30.1 cardano-node](https://s3.ap-southeast-2.amazonaws.com/www.myadanode.com/cardano-node/1.30.1/aarch64/cardano-node)

As usual it still needs libsodium, unchanged if you were already using it, but available here if you are new to this. (check my other posts for more details).

[Libsodium aarch64](https://s3.ap-southeast-2.amazonaws.com/www.myadanode.com/cardano-node/libsodium/libsodium.tar.gz)

Enjoy, and if you feel like thanking us you can delegate few ADA to [MADA1]

PS: I know some people will insist you need more than 8G memory, but with proper tuning of Haskel you can run perfectly fine under 8G. Haskel version 9 should bring improvements on that matter. Check the forum for this, there is a fantastic post by @_2072

---

<div class="post-metadata">

**Author:** ![Stone\_Curator](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/stone_curator/32/43542_2.png) [@Stone\_Curator](https://forum.cardano.org/u/Stone_Curator)\
**Post date:** [6 October 2021 19:24 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112/2 "2021-10-06T19:24:58Z")

</div>

Very interesting to see support for ARM64 architecture. I can’t wait to try this out on my Raspberry Pi 😁

---

<div class="post-metadata">

**Author:** ![kaverne](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/kaverne/32/46048_2.png) [@kaverne](https://forum.cardano.org/u/kaverne)\
**Post date:** [6 October 2021 22:56 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112/3 "2021-10-06T22:56:54Z")

</div>

Happy to help. We have been running on the binaries we distribute free to all pool owners since the start of the pool.  
We are not running on raspberry Pi though 😉

---

<div class="post-metadata">

**Author:** ![tomdx](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/tomdx/32/44498_2.png) [@tomdx](https://forum.cardano.org/u/tomdx)\
**Post date:** [7 October 2021 07:09 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112/4 "2021-10-07T07:09:28Z")

</div>

You could have a [look at this](https://tdiesler.gitbook.io/cardano/v/iohk/plain-docker/raspberrypi-4). Running cardano-node on a Pi4 is a easy as this …

 ![image](https://us1.discourse-cdn.com/flex023/uploads/cardano/original/3X/6/4/64348211a52013e2c0fde33c65a584db9f5aa9fe.png)

---

<div class="post-metadata">

**Author:** ![TerrenceHenry](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/terrencehenry/32/28191_2.png) [@TerrenceHenry](https://forum.cardano.org/u/TerrenceHenry)\
**Post date:** [7 October 2021 12:28 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112/5 "2021-10-07T12:28:01Z")

</div>

> [@Cardano Stake Pool on Raspberry Pi - Need Help with ARM Binaries](https://forum.cardano.org/t/cardano-stake-pool-on-raspberry-pi-need-help-with-arm-binaries/51928/25):
>
> Version 1.30.1 binaries for Raspberry Pi4, 8GB now available here:

---

<div class="post-metadata">

**Author:** ![Stone\_Curator](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/stone_curator/32/43542_2.png) [@Stone\_Curator](https://forum.cardano.org/u/Stone_Curator)\
**Post date:** [7 October 2021 15:05 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112/6 "2021-10-07T15:05:48Z")

</div>

Thanks, Tom!

---

<div class="post-metadata">

**Author:** ![lakcv](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/lakcv/32/26561_2.png) [@lakcv](https://forum.cardano.org/u/lakcv)\
**Post date:** [29 October 2021 05:23 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112/7 "2021-10-29T05:23:36Z")

</div>

Thank you [kaverne](https://forum.cardano.org/u/kaverne)  
I have successfully tested the [1.30.1 cardano-cli](https://s3.ap-southeast-2.amazonaws.com/www.myadanode.com/cardano-node/1.30.1/aarch64/cardano-cli) on RasPi3  
Ubuntu 20.04.3 LTS GLIBC 2.31-Oubuntu9.2

---

<div class="post-metadata">

**Author:** ![tomdx](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/tomdx/32/44498_2.png) [@tomdx](https://forum.cardano.org/u/tomdx)\
**Post date:** [29 October 2021 05:34 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112/8 "2021-10-29T05:34:46Z")

</div>

> I have successfully tested the [1.30.1 cardano-cli](https://s3.ap-southeast-2.amazonaws.com/www.myadanode.com/cardano-node/1.30.1/aarch64/cardano-cli) on RasPi3  
> Ubuntu 20.04.3 LTS GLIBC 2.31-Oubuntu9.2

You need a [64bit OS and at least 8G RAM](https://tdiesler.gitbook.io/cardano/plain-docker/raspberrypi-4)

---

<div class="post-metadata">

**Author:** ![kaverne](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/kaverne/32/46048_2.png) [@kaverne](https://forum.cardano.org/u/kaverne)\
**Post date:** [1 November 2021 22:56 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112/9 "2021-11-01T22:56:06Z")

</div>

Our pleasure @lakcv ! Enjoy mate.

---

<div class="post-metadata">

**Author:** ![kaverne](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/kaverne/32/46048_2.png) [@kaverne](https://forum.cardano.org/u/kaverne)\
**Post date:** [1 November 2021 22:57 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112/10 "2021-11-01T22:57:02Z")

</div>

Well I guess @lakcv knows that since he mentioned “successfully”. That a massive hint that everything went well 😉

---

<div class="post-metadata">

**Author:** ![tomdx](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/tomdx/32/44498_2.png) [@tomdx](https://forum.cardano.org/u/tomdx)\
**Post date:** [2 November 2021 06:41 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112/11 "2021-11-02T06:41:07Z")

</div>

Surely, that depends on the meaning of “everything”. Can we see memory utilisation, GC behaviour, missed slots for the block producer?

---

<div class="post-metadata">

**Author:** ![kaverne](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/kaverne/32/46048_2.png) [@kaverne](https://forum.cardano.org/u/kaverne)\
**Post date:** [2 November 2021 22:58 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112/12 "2021-11-02T22:58:57Z")

</div>

Always getting the last word hey ? lollll  
Whatever, someone came here to thank us for distributing the compiled arm64 binaries.  
I appreciate the pat in the back, it stops there.

---

<div class="post-metadata">

**Author:** ![robbyja7](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/robbyja7/32/55004_2.png) [@robbyja7](https://forum.cardano.org/u/robbyja7)\
**Post date:** [3 November 2021 22:47 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112/13 "2021-11-03T22:47:54Z")

</div>

Relax Tom,

He said he tested the cli on a rpi3, noone said he running a pool on it.  
A rpi3 is an ideal air gapped offline machine to RUN THE CLI on. Exactly as he said he did.  
Anyway, thanks for supplying the binaries guys!

---

<div class="post-metadata">

**Author:** ![kaverne](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/kaverne/32/46048_2.png) [@kaverne](https://forum.cardano.org/u/kaverne)\
**Post date:** [4 November 2021 00:12 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112/14 "2021-11-04T00:12:16Z")

</div>

All good, no worries.

I’m not running our pool on RasPi (I’m just using those for my fermenter fridge and brewing beer 😃 )  
So just for my knowledge, even if @lakcv was running a pool on RasPi, you seem to imply that would be an issue ? Why ?

---

<div class="post-metadata">

**Author:** ![robbyja7](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/robbyja7/32/55004_2.png) [@robbyja7](https://forum.cardano.org/u/robbyja7)\
**Post date:** [4 November 2021 07:22 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112/15 "2021-11-04T07:22:45Z")

</div>

Hey,

I was implying that a rpi 3 would not work for use in a pool.  
The rpi4 8gb RAM is no problem for using in a pool. There are several dozens of pools that I know of that run on these pis exclusively. They have millions of stake, are minting blocks and running relays just fine.  
It just needs the right hardware settings, and pool parameters and they run just fine.  
People build their pools with standard parameters, and then see they need to switch to 16 gb and tyen complain. However they don’t bother looking around to see if they can optimize their setup…

---

<div class="post-metadata">

**Author:** ![kaverne](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/kaverne/32/46048_2.png) [@kaverne](https://forum.cardano.org/u/kaverne)\
**Post date:** [4 November 2021 08:09 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112/16 "2021-11-04T08:09:29Z")

</div>

Oh yeah yeah sure.  
I didn’t know the RasPi 3 wasn’t strong enough to hold the load. Yep you are right I know quite some pools and some “big” ones on that.  
Will it be viable in the long run, time will tell. But plutus and smart contracts might generate more (not huge) cpu/memory needs. Wait and see 😃  
Good chat !

---

<div class="post-metadata">

**Author:** ![tomdx](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/tomdx/32/44498_2.png) [@tomdx](https://forum.cardano.org/u/tomdx)\
**Post date:** [4 November 2021 08:51 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112/17 "2021-11-04T08:51:36Z")

</div>

I’m currently [researching into optimized Haskell GC settings for the Pi4](https://twitter.com/AstorPool/status/1449732546867179523). So far, I found that running a relay is no problem even without ZRam. Running block producer is a different story because it needs to run the lottery in real time once every second. The Haskell copying GC (i.e. the default) will halt the world for stretches of multiple seconds, which leads to “missed slots”. The newer non-moving GC still holds the world, but less. It generally keeps the mutator running (i.e. the node process) but has 20% higher memory consumption - also no good for a block producer.

In case I find a good combination of ZRam and GC settings for the block producer, it’ll find its way into the nessusio docker image. You can monitor this work [over here](https://github.com/tdiesler/nessus-cardano/issues/83).

[Astor](https://astorpool.net/) also has scripts that can [restart the block producer](https://github.com/tdiesler/nessus-cardano/blob/main/scripts/control/astor-ctrl.tcl#L21) in time for the next block. Haskell GC deteriorates over time - it may hence not be necessary to find the silver bullet for long term sustained performance. Doing a restart a few hours before the next block is not ideal, but also leads to no missed slots for a couple of hours. This might be good enough for now (until Haskell improves its GC)

---

<div class="post-metadata">

**Author:** ![kaverne](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/kaverne/32/46048_2.png) [@kaverne](https://forum.cardano.org/u/kaverne)\
**Post date:** [4 November 2021 22:41 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112/18 "2021-11-04T22:41:54Z")

</div>

> [@tomdx](#):
>
> Doing a restart a few hours before the next block is not ideal

What do you mean by that ? Did you mean epoch instead of block ?

---

<div class="post-metadata">

**Author:** ![tomdx](https://sea1.discourse-cdn.com/flex023/user_avatar/forum.cardano.org/tomdx/32/44498_2.png) [@tomdx](https://forum.cardano.org/u/tomdx)\
**Post date:** [5 November 2021 06:13 UTC](https://forum.cardano.org/t/cardano-node-1-30-1-arm64-aarch64-compiled-binaries/78112/19 "2021-11-05T06:13:44Z")

</div>

I mean your next block. With a [simple script](https://github.com/tdiesler/nessus-cardano/blob/main/scripts/control/astor-ctrl.tcl#L21) you can determine reasonable restart points depending on the leaderlog.

 ![image](https://us1.discourse-cdn.com/flex023/uploads/cardano/original/3X/8/b/8b981c91e8ba1f5d010e83561a901cae9b08900d.png)

The above shows epoch/no slot, restart time, block time. You’ll notice that the restart happens 2h before the next block, unless this would interfere with a previous block. Two hours should give the node plenty of time to restart even with a dirty block store. I observed that major GCs happen a lot less frequently (if at all) during the first few hours of uptime - for me it turns bad after 8h or so. Unfortunately, I don’t yet have good and conclusive results worth publishing - each of my tests runs for 24h.

The Haskell GC reminds me of the early days in Java. Over time that got much better. Halting the world does generally not work so well for non-trivial processes - especially not, if there is a real time aspect to it. Nonmoving GC can keep the mutator (MUT) alive, but should not result in a drastic memory increase. GC should not increase memory over time for it’s own bookkeeping - that would be a memory leak. Not sure, if that is the case here - the node might cause the increase of memory that we see over time. In that case, we might be seeing a mem leak in the node, which would be low hanging fruit for improvement.
