Intel N100
28 Sep 2024 18:24 - 29 Sep 2024 06:24 #310991
by rebelx
Replied by rebelx on topic Intel N100
Intel N100 works great with Debian 13 (Trixie pre-release) and LinuxCNC 2.9.3-1+b2
I have achieved good results with a cheap and super small N100 mini PC, with 16GB of DDR5 memory, a 256GB NVMe drive, dual LAN and Wifi/BT. It is available on AliExpress and other channels as a T8 Plus and it is sold under different brand names. The price varies between 120.- and 200.- USD depending on the configuration. I attached some images below.
It came with Windows 11 Pro pre-installed and activated. I decided to go for a dual boot system, keeping Windows and installing Debian in a separate partition, so I could use Windows for my servo motor tuning software.
In order to try something new, which is usually more fun, I decided to install Debian Trixie (yes, pre-release Debian 13), via the text based installer, which went flawlessly. I chose Cinnamon for the GUI, which often gave me somewhat unstable lacencies under Debian 12, probably due to some graphics driver issues, and I was curious if Cinnamon would perform better under Trixie. After booting my new Debian 13 system, I opened Synaptic and installed linux-image-6.10.9-rt-amd64. Then I rebooted and confirmed that Debian was running with the RT kernel:
which showed: Linux <pc-name> 6.10.9-rt-amd64 #1 SMP PREEMPT_RT Debian 6.10.9-1 (2024-09-08) x86_64 GNU/Linux
Next I installed LinuxCNC version 2.9.3-1+b2 from the Trixie repository, including the optional dev package, via:
Nice to see that the latest stable release is automatically installed from the Debian Trixie repository
I did some latency tests without any BIOS changes or using isolcpus, and as to be expected the results were quite terrible with values for both the servo threat Max Jitter and base thread Max Jitter above 600000ns. (yes, six hundred thousand; it is not a typo). During the latency test I had 8 instances of glxgears running, internet connection via the build-in Wifi, Firefox had two tabs open with YouTube videos running and I was browsing the internet.
I then went into the BIOS settings and ONLY disabled Virtualization. After rebooting and doing another latency test, the results were much better, but still quite high. Before making any additional BIOS changes I decided to first play around with isolcpus to figure out which core(s) should be isolated from the general scheduler in order to get the best performance. I tested all possible combinations under the same test scenario as mentioned above, which took me several hours, and I found that isolcpus=1,2,3 resulted in the most optimal latency values. The Max Jitter values for both threads stayed below 20000ns, which is totally acceptable.
Next step was going back into the BIOS in order to disable things like C State and other power saving features, which is usually recommended to reduce latency, but strange enough disabling those only resulted in HIGHER latency instead of lower, so I stayed with only disabling virtualization and left the rest in their default settings. While I am typing this, the computer has been running for a few hours with the latency test and all those background programs running, and the Servo thread Max Jitter is 17646ns and the Base thread Max Jitter is 18711ns. Perhaps in the next few days I will take another look at the BIOS settings, trying to further reduce the latency, although I realize that is really not needed. All in all I am more than happy with this N100 mini PC. I will also test with some different desktop environments, especially lightweight environments like XFCE and LXQt. I may follow-up with another post about my findings.
As a PS: for those who want to use a Qt based GUI, like QtDragon, a Python file needs to be modified. Debian 13 comes with Python 3.12.6 installed. As from Python 3.12 locale.format is deprecated and needs to be replaced with locale.format_string in three places (lines 270, 277, 281) in the following file:
This fix is already implemented in the upcoming LinuxCNC 2.10 release, available on the LinuxCNC github page as a work in progress.
I hope this may be helpful for those looking for a modern cheap PC for LinuxCNC. N100 is definitely a suitable solution.
I have achieved good results with a cheap and super small N100 mini PC, with 16GB of DDR5 memory, a 256GB NVMe drive, dual LAN and Wifi/BT. It is available on AliExpress and other channels as a T8 Plus and it is sold under different brand names. The price varies between 120.- and 200.- USD depending on the configuration. I attached some images below.
It came with Windows 11 Pro pre-installed and activated. I decided to go for a dual boot system, keeping Windows and installing Debian in a separate partition, so I could use Windows for my servo motor tuning software.
In order to try something new, which is usually more fun, I decided to install Debian Trixie (yes, pre-release Debian 13), via the text based installer, which went flawlessly. I chose Cinnamon for the GUI, which often gave me somewhat unstable lacencies under Debian 12, probably due to some graphics driver issues, and I was curious if Cinnamon would perform better under Trixie. After booting my new Debian 13 system, I opened Synaptic and installed linux-image-6.10.9-rt-amd64. Then I rebooted and confirmed that Debian was running with the RT kernel:
$ uname -awhich showed: Linux <pc-name> 6.10.9-rt-amd64 #1 SMP PREEMPT_RT Debian 6.10.9-1 (2024-09-08) x86_64 GNU/Linux
Next I installed LinuxCNC version 2.9.3-1+b2 from the Trixie repository, including the optional dev package, via:
sudo apt install linuxcnc-uspace linuxcnc-uspace-devNice to see that the latest stable release is automatically installed from the Debian Trixie repository
I did some latency tests without any BIOS changes or using isolcpus, and as to be expected the results were quite terrible with values for both the servo threat Max Jitter and base thread Max Jitter above 600000ns. (yes, six hundred thousand; it is not a typo). During the latency test I had 8 instances of glxgears running, internet connection via the build-in Wifi, Firefox had two tabs open with YouTube videos running and I was browsing the internet.
I then went into the BIOS settings and ONLY disabled Virtualization. After rebooting and doing another latency test, the results were much better, but still quite high. Before making any additional BIOS changes I decided to first play around with isolcpus to figure out which core(s) should be isolated from the general scheduler in order to get the best performance. I tested all possible combinations under the same test scenario as mentioned above, which took me several hours, and I found that isolcpus=1,2,3 resulted in the most optimal latency values. The Max Jitter values for both threads stayed below 20000ns, which is totally acceptable.
Next step was going back into the BIOS in order to disable things like C State and other power saving features, which is usually recommended to reduce latency, but strange enough disabling those only resulted in HIGHER latency instead of lower, so I stayed with only disabling virtualization and left the rest in their default settings. While I am typing this, the computer has been running for a few hours with the latency test and all those background programs running, and the Servo thread Max Jitter is 17646ns and the Base thread Max Jitter is 18711ns. Perhaps in the next few days I will take another look at the BIOS settings, trying to further reduce the latency, although I realize that is really not needed. All in all I am more than happy with this N100 mini PC. I will also test with some different desktop environments, especially lightweight environments like XFCE and LXQt. I may follow-up with another post about my findings.
As a PS: for those who want to use a Qt based GUI, like QtDragon, a Python file needs to be modified. Debian 13 comes with Python 3.12.6 installed. As from Python 3.12 locale.format is deprecated and needs to be replaced with locale.format_string in three places (lines 270, 277, 281) in the following file:
$ sudo gedit /usr/lib/python3/dist-packages/qtvcp/widgets/origin_offsetview.pyThis fix is already implemented in the upcoming LinuxCNC 2.10 release, available on the LinuxCNC github page as a work in progress.
I hope this may be helpful for those looking for a modern cheap PC for LinuxCNC. N100 is definitely a suitable solution.
Please Log in or Create an account to join the conversation.
29 Sep 2024 05:19 - 29 Sep 2024 06:54 #311014
by rebelx
Yes, that is what I actually meant, but you found a more correct way to say it I updated the text. Thank you for correcting me!
Isolating cores from the general scheduler and how that impacts latency always feels a bit like black magic to me, and results can vary quite a lot between different processor architectures. I remember using a J1900 board, where isolplus=1,2 gave the best results, which I guess may be related to how the cores are internally arranged on the die in two pairs, cores 0 and 1 being on one half of the die and sharing resources, and cores 2 and 3 sharing the other half. I guess limiting the general scheduler to only use one core per pair has an impact on interrupts and latency. I am not sure how the N100 is internally organized and how that may be impacting latency.
Do you know if there are any articles that explain how exactly LinuxCNC tasks are assigned to isolated cores? I would be interested in learning more about it. The main reason being that I am looking at some Arm based solutions that combine both application processors (e.g. Cortex-A53/55 capable of running Linux) and microcontrollers (e.g. CortexM7/33) in one chip. Some even have a dedicated DSP, which can be an efficient way to handle PIDs and so forth. Although my primary interest in this area is something else than CNC machine control, I think it would be very interesting to see if we could port LinuxCNC to such a platform, where the general Linux part of LinuxCNC can run on a Cortex-A, and where the real-time tasks can be performed on a Cortex-M, independently from the application processor. This separation could free us from Intel and AMD and how their platforms are more geared towards gamers than industrial low latency applications.
Replied by rebelx on topic Intel N100
isolcpus does not disable cores
isolcpus isolates designated cores from the general scheduler
So routine tasks won't be assigned to those cores. E.g. web browser running in the background won't take CPU time on isolated cores
Yes, that is what I actually meant, but you found a more correct way to say it
I updated the text. Thank you for correcting me!Isolating cores from the general scheduler and how that impacts latency always feels a bit like black magic to me, and results can vary quite a lot between different processor architectures. I remember using a J1900 board, where isolplus=1,2 gave the best results, which I guess may be related to how the cores are internally arranged on the die in two pairs, cores 0 and 1 being on one half of the die and sharing resources, and cores 2 and 3 sharing the other half. I guess limiting the general scheduler to only use one core per pair has an impact on interrupts and latency. I am not sure how the N100 is internally organized and how that may be impacting latency.
Do you know if there are any articles that explain how exactly LinuxCNC tasks are assigned to isolated cores? I would be interested in learning more about it. The main reason being that I am looking at some Arm based solutions that combine both application processors (e.g. Cortex-A53/55 capable of running Linux) and microcontrollers (e.g. CortexM7/33) in one chip. Some even have a dedicated DSP, which can be an efficient way to handle PIDs and so forth. Although my primary interest in this area is something else than CNC machine control, I think it would be very interesting to see if we could port LinuxCNC to such a platform, where the general Linux part of LinuxCNC can run on a Cortex-A, and where the real-time tasks can be performed on a Cortex-M, independently from the application processor. This separation could free us from Intel and AMD and how their platforms are more geared towards gamers than industrial low latency applications.
Please Log in or Create an account to join the conversation.
Time to create page: 0.143 seconds