DietPi & ARMbian (lightweight & optimization comparison)

Have some feedback, questions, suggestions, or just fancy a chat? Pop it in here.
Post Reply
User avatar
Site Admin
Posts: 2788
Joined: Tue Feb 06, 2007 1:36 pm

DietPi & ARMbian (lightweight & optimization comparison)

Post by Fourdee »

DietPi & ARMbian (lightweight & optimization comparison)
We have the highest respect for ARMbian, their project, and, the people who make it happen (Igor, zador-blood-stained).
Even to the extent that we choose to use their build tools, to create excellent baseline Debian images for some our boards, before we optimize them for DietPi.

Both DietPi and ARMbian, have their advantages, which is subject to end user requirements.
However, for these test, we are only focusing on exactly how lightweight the default image is, optimizations, and, how they can benefit the end user to ensure the highest performance potential from their SBC, and, the software you actually need to run on them.

Testing criteria
For this test, the following devices and images were used:
- RPi 3 + DietPi (Raspbian) Stretch
- OPi PC + ARMbian Debian Server Stretch
- Both default image installations
- Both with NetData installed for some tests, aside from passwords, this being the only changes that were made.
- Both running Idle

We were planning to use RPi for both tests, however, ARMbian do not currently support this device, or the user base.
Due to this, kernel may be a factor, however, we believe this is marginal and should not effect results.

Test 1 - SD write count:
Lower is better
SD cards have a limited write count and life expectancy. Simply put, the more the system writes to the SD card, the lower the expected life span. Ideally, you want to reduce SD writes to maximize expected lifespan.
The other core benefit of reduced SD card IO, is the reduction in disk read/write wait times, all of which can delay system operation and reduce performance.
- DietPi = 0 disk read/write
- ARMbian = various disk read/write
The below image shows wait times, before the requested memory data can be written to disk. This generally means bottle-necking has occurred and the overall system performance will be effected until the data is written.

Test 2 - Memory usage / CPU process count:
Lower is better
These results remove NetData from results (fresh installations of both images, after NetData samples were taken)
- DietPi = 27MB RAM used, 11 processes
- ARMbian = 51MB RAM used, 18 processes
In short, the less memory used, the less chance for read/write to DISK via swapfile or swap partition.
DISK swapping will slow down the system and overall response times, as the system needs to wait for DISK IO, which is much slower than typical RAM.
A lower memory footprint gives you more room to install additional software, have it run at peak performance longer, without the risk of disk swap.

Each process on a system uses resources (threads, handles), the lower the amount of processes, the more efficient the CPU will run by reducing potential CPU overheads from background processes, which use up CPU time and resources.
A lower process count is achieved on DietPi, by reducing the need for additional programs to achieve a task, which can be done more efficiently (eg: Network manager vs DietPi-Config).

Test 3 - RootFS Size:
Lower is better
- DietPi = 555MB (504MB after apt-get clean)
- ARMbian = 1100MB (999MB after apt-get clean)
This is a simple case of how much disk space the default installation will use, and, how long the initial image write to SD card will take. A lower value, means more free disk space for additional software and tasks that you require.

Test 4 -RAMlog:
Lower is better
- DietPi = 0 additional processes/threads, log memory cleared every 1 hour.
- ARMbian = 1 additional process, 4 threads, log memory cleared every 24 hours.
Both distributions offer RAMlog installed by default.

DietPi-RAMlog: Coded from the ground up, DietPi-RAMlog achieves a lower footprint by moving all logging over to tmpfs. This mounts /var/log to RAM.
By default, DietPi then clears the logs automatically on an hourly basis, to free up the memory used in RAM.
DietPi-RAMlog supports additional modes, in which logs can be saved on an hourly basis, before being cleared from RAM. A full logging system is also available, for end users where log files are critical to system maintenance.

ARMbian Log2RAM:
Is a similar method, however, by default, it writes the logs to disk's once every 24 hours. As this is a longer duration before clearing the logs in RAM, increased memory consumption can be expected over that period of time.
ARMbian logging also induces an additional process, which uses 4 threads and uses up potential CPU resources.

Test End:
Regardless of the above:
ARMbian and DietPi are two great projects with unique goals.
Both projects benefit from the many thousands of opensource coders involved with Debian and Linux Kernel, who put their free time, dedication and combined effort, into improving our world for the better.
You (the end user) are the only factor of importance. We will always respect you and ability to choose whats best for your needs (even if you choose Ubuntu :) )
Last edited by k-plan on Tue Feb 20, 2018 3:47 pm, edited 1 time in total.
Reason: Change to "Standard Topic"
If you find our project or support useful, then we’d really appreciate it if you’d consider contributing to the project however you can.
Donating is the easiest – you can use PayPal or become a DietPi patron.
User avatar
Posts: 608
Joined: Thu Jul 20, 2017 8:55 am

Re: DietPi & ARMbian (lightweight & optimization comparison)

Post by WarHawk »

Posts: 12
Joined: Fri Nov 17, 2017 7:50 am

Re: DietPi & ARMbian (lightweight & optimization comparison)

Post by Pauduan »

I didn't really have to choose, I use both! :)

I have an Asus Tinker running Armbian Stretch as a home server with Samba, LMS and Torrents, and a Rpi Zero running DietPi for a Squeezelite endpoint (the eventual plan is to migrate it into a clock radio of some kind).

The last time I downloaded DietPi for the Tinker (to do the same job that Armbian is doing now) it caused me a few issues but I was able to get the headless install done and running in about an hour, with the config examples from the forum.

Must say it seems to be quite effortless even for for a rank noob, and with no display or keyboard attached to the SBC. That's got to be a first. My kudos to you guys!
Post Reply