Thin or Native VDI Client? Measuring OS Resource Intensity Levels Helps Decide
When connecting to a remote virtual desktop infrastructure (VDI) desktop, there are many different vendors and devices to choose from (you can use anything from a cell phone to a GPU-equipped workstation). However, determining which device is most ideal depends on the tasks you will be performing.
For most users, a traditional monitor setup is the best choice. But there are many variations on this. For a task worker, for example, an inexpensive (sub $100) Arm-based device may be adequate. On the other hand, an engineer or a doctor may require a client that supports four or more 4K displays as well as the ability to run local applications. Not only is performance a concern, but there are other factors to consider such as security and manageability.
In this article, I am going to explore one of the important factors that comes into play when making the decision of which device to use -- an OS's resource intensity level when running VMware's Horizon VDI client. I will measure the performance of the device to see if a dedicated thin-client OS uses less resources when connected to a virtual desktop than when the Horizon client runs on Linux or the Windows desktop system.
There are many different thin-client OSes available, with the most popular ones being IGEL, Stratodesk and 10Zig. These OSes were designed to do one thing: act as a client to connect to a virtual desktop. Many users choose or need to use their existing Windows or Linux system to connect to a remote desktop. To enable these users, all the major VDI vendors (for example, VMware, Citrix, Leostream and so on) have native clients that allow for this.
The question I wanted to investigate is what resources are required to run a VDI client on top of a generic OS vs. a thin client. Not only was I intellectually curious about this, but this information also dictates how powerful of a hardware platform you need to purchase to accommodate these two different methodologies.
To see the resource usage, I used a Maxtang NX6412-B11 as the computer. This is a low-cost ($300), small form-factor computer with a quad-core Intel Celeron J6412 processor with 8GB of RAM. For my testing, I connected it to a single monitor. You can read my full review on the device here.
I used Stratodesk for the bespoken thin-client OS and Ubuntu Linux and Windows 10 for native client testing. I completed a fresh install of all the OSes and did not customize the devices in any way; they ran straight as installed.
For the remote desktop, I connected to a GPU-enabled VMware Horizon desktop. I streamed a 1080p video for 30 minutes. To capture the data, I used ControlUp Edge DX as it is an OS-agnostic tool.
Linux with Horizon Native Client
To run the Horizon native client on Linux, I used Ubuntu 22.04, which has long-term support (LTS); as such, it is a likely candidate for deployment at companies. After installing the OS, I downloaded and installed the 2209 Horizon client following the official VMware instructions. After installing the client, I ran the Horizon system compatibly check, which came back clean.
I monitored the activity of the device while doing my testing using Edge DX, a physical endpoint monitoring and remediation platform from ControlUp, a company that I work for.
I downloaded the data and created a chart from it. Upon reviewing the chart, I could see that the CPU load hovered around 30 percent and it used about 1.6GB of RAM while the video was streaming to a Horizon desktop.
Windows Horizon Native Client
I then installed Windows 10 on the device. Although it is being replaced by Windows 11, many companies still run it. I then downloaded and installed the 2209 Horizon client following the VMware official VMware instructions.
I again monitored the activity using Edge DX while the testing was taking place.
I downloaded the data and created a chart from it. I could see from the chart that the CPU load hovered around 100 percent and it used about 2GB of RAM while a video was streaming to a Horizon desktop.
Stratodesk has been around for over a decade and is in use in many large international firms as well as smaller companies. It supports all major VDI protocols and runs on Arm- or Intel-compatible 64-bit CPUs. Stratodesk is very lightweight as it only requires a 500 MHz or greater CPU and 128 MB RAM.
I installed NoTouch OS (Stratodesk operating system). Horizon comes preinstalled with the OS. I again monitored the system using ControlUp Edge DX while the tests were running.
Using the chart that I created from the data, I could see that the CPU load hovered around 20 percent and it used about 1GB of RAM while a video was streaming to a Horizon desktop.
I was surprised to discover how high the CPU usage was when Windows was used as the OS for the thin client, and that the video playback was somewhat choppy on the Windows device. I believe that the choppiness was due in part to the CPU as it was at 100 percent most of the time. When using Ubuntu as the OS, on the other hand, the CPU usage was 30 percent and RAM usage was 1.6GB. And when using Stratodesk, the CPU usage was 20 percent and RAM usage was 1GB. I did not notice any choppiness when running on these two OSes.
Below is a side-by-side comparison of the tests. Please notice that the range scale is different for each of the tests.
Stratodesk: CPU load 15-25 percent; RAM 1GB
Ubuntu with native client: CPU load 25-35 percent; RAM 1.6GB
Windows 10 with native client: CPU load ~100; RAM 2GB
Performance and resource utilization are just one of the many factors you should take into consideration when deciding which OS to use on a thin client. However, based on the tests that I conducted, it may prove to be a key factor, especially if you are budget constrained on your hardware choice.
About the Author
Tom Fenton has a wealth of hands-on IT experience gained over the past 25 years in a variety of technologies, with the past 15 years focusing on virtualization and storage. He currently works as a Technical Marketing Manager for ControlUp. He previously worked at VMware as a Senior Course Developer, Solutions Engineer, and in the Competitive Marketing group. He has also worked as a Senior Validation Engineer with The Taneja Group, where he headed the Validation Service Lab and was instrumental in starting up its vSphere Virtual Volumes practice. He's on Twitter @vDoppler.