Using Thin Client Wortmann Terra Rangee Thinclient 5210, Intel(R) Celeron(R) CPU N3160 @ 1.60GHz

Hello,
To run x86 software I found a well priced thin client (45 € used) with a Celeron N3160 processor. It runs the UEFI/SquashFS firmware (generic-squashfs-combined-efi.img.gz).

However, I was having stability issues and the device occasionally restarted itself. What I tried:

  • opkg install "intel-microcode", but still the device restarted
  • Found a test case that caused the device to freeze/hang-up/restart: while true; do stress --cpu 8 --io 4 --vm 2 --vm-bytes 1G --timeout 120s --hdd 2; sleep 120; done
  • disabled all C-states higher C1 in the BIOS, but it still restarts occasionally
  • Modified the grub commandline to disable all Intel P-states: sed -i "s/console=tty0 console=ttyS0,115200n8 noinitrd$/console=tty0 console=ttyS0,115200n8 noinitrd intel_pstate=disable/" /boot/grub/grub.cfg but it still restarts
  • Added the following to the /etc/rc.local:
#Stability improvement, loosing powersaving options
sed -i "s/console=tty0 console=ttyS0,115200n8 noinitrd$/console=tty0 console=ttyS0,115200n8 noinitrd intel_pstate=disable/" /boot/grub/grub.cfg

for CORE in 0 1 2 3; do
echo "echo performance > /sys/devices/system/cpu/cpu$CORE/cpufreq/scaling_governor"
echo performance > /sys/devices/system/cpu/cpu$CORE/cpufreq/scaling_governor
done

MAXFREQ="$(cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq)"
MAXFREQ="1600000"
MINFREQ="1600000"
for CORE in 0 1 2 3; do
echo "echo $MAXFREQ > /sys/devices/system/cpu/cpufreq/policy$CORE/scaling_max_freq"
echo $MAXFREQ > /sys/devices/system/cpu/cpufreq/policy$CORE/scaling_max_freq
echo "echo $MINFREQ > /sys/devices/system/cpu/cpufreq/policy$CORE/scaling_min_freq"
echo $MINFREQ > /sys/devices/system/cpu/cpufreq/policy$CORE/scaling_min_freq
done

#get all c-states: grep . /sys/devices/system/cpu/cpu*/cpuidle/state*/name
for CORE in 0 1 2 3; do
for STATE in 2 3 4 5; do
echo "echo 1 > /sys/devices/system/cpu/cpu$CORE/cpuidle/state$STATE/disable"
echo 1 > /sys/devices/system/cpu/cpu$CORE/cpuidle/state$STATE/disable
done
done

Now it seems to keep running, the test humms along quite reliably and without restarts/freezes.

But: I sacrificed most power saving options in exchange for stability. Perhaps you have suggestions what I might do instead.

Here a few graphs how it now performs with the test script:

This picture shows the CPU load of all cores over the past hour. Quite obvious is the stop and go of the test script:

The frequency remains at 1.6 GHz all the time. Before it switched frequencies and saved power, but it chrashed. With fixed settings it does not reboot anymore by itself:

The CPU temperature remains acceptable:

Edit 02.03.2022:
Experimenting with settings does not cause reboots with scaling_governor "ondemand" and frequencies not lower than 1.2 GHz. This is now the most recent /etc/rc.local:

#Stability improvement
sed -i "s/console=tty0 console=ttyS0,115200n8 noinitrd$/console=tty0 console=ttyS0,115200n8 noinitrd intel_pstate=disable/" /boot/grub/grub.cfg

for CORE in 0 1 2 3; do
echo "echo ondemand > /sys/devices/system/cpu/cpu$CORE/cpufreq/scaling_governor"
echo ondemand > /sys/devices/system/cpu/cpu$CORE/cpufreq/scaling_governor
done

MAXFREQ="$(cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_max_freq)"
#MAXFREQ="1600000"
#MINFREQ="1600000"
MINFREQ="1200000"
#MINFREQ="800000"
#MINFREQ="480000"
for CORE in 0 1 2 3; do
echo "echo $MAXFREQ > /sys/devices/system/cpu/cpufreq/policy$CORE/scaling_max_freq"
echo $MAXFREQ > /sys/devices/system/cpu/cpufreq/policy$CORE/scaling_max_freq
echo "echo $MINFREQ > /sys/devices/system/cpu/cpufreq/policy$CORE/scaling_min_freq"
echo $MINFREQ > /sys/devices/system/cpu/cpufreq/policy$CORE/scaling_min_freq
done

# get all c-states:
# bash -c "grep . /sys/devices/system/cpu/cpu*/cpuidle/state*/{name,disable} | sort"
# 0 -> POLL,
# 1 -> C1,
# 2 -> C6N,
# 3 -> C6S,
# 4 -> C7,
# 5 -> C7S

for CORE in 0 1 2 3; do
for STATE in 2 3 4 5; do
echo "echo 1 > /sys/devices/system/cpu/cpu$CORE/cpuidle/state$STATE/disable"
echo 1 > /sys/devices/system/cpu/cpu$CORE/cpuidle/state$STATE/disable
done
done

#opkg update
#opkg install fdisk block-mount lsblk htop collectd-mod-ping collectd-mod-wireless luci-app-statistics pingcheck collectd-mod-uptime \
#                     kmod-usb-storage e2fsprogs fdisk resize2fs \
#                     htop debootstrap debian-archive-keyring gpgv2 block-mount \
#                     qemu-img qemu-x86_64-softmmu kmod-kvm-x86 qemu-bridge-helper kmod-tun  \
#                     openssh-sftp-server bash screen

#run Paperless-NG or the successor Paperless-NGX, keep it in a screen session check how it is doing
screen -d -S paperless -m bash /etc/config/Paperless-NG/99\ run\ paperless.ng.sh

exit 0

Curious, what are you running to collect that data?

How often would it occasionally reboot?

(To me, it seems you got a broken CPU to run - I applaud you.)

looks like monitorix (rrd graphs) , but I haven't used it in a while, so I might be wrong.

Odd, I don't see it listed:

(I meant running on the OpenWrt.)

I didn't ,)

Might be manually installable though, doesn't require that many additional packages.
Problem is obviously the constant rrd writing, would kill a flash device in no time.

I think you still miss my point...and reason for my question.

I was wondering if something like snmpd, etc. was using CPUs on the OP's device... :wink:

It could be a BIOS bug. See if a newer BIOS has been released.

2 Likes

Yes, BIOS is the most recent available and the package intel-microcode should provide the most recent microcode for the CPU. Unfortunately that was not it.

That is luci-app-statistics which is collectd under the hood plus LuCi integration. To gather temperature values I also installed collectd-mod-sensors and to get the CPU frequencies collectd-mod-cpufreq.

So, all in all:
opkg install luci-app-statistics collectd-mod-sensors collectd collectd-mod-uptime collectd-mod-cpufreq

You need to logout and login to see the new menuitem statistics

Per default collectd on OpenWRT writes to RAM. You can specify a location for persistent storage. I use a µSD card now for quite a while to store RRD data and TV recordings without issues. I agree that writing to internal flash is not a good idea though.

the ups and downs in that graph is the actual test I use to put the CPU under stress. Before limiting the CPU to exclusively use 1.6 GHz without up/down clocking it rebooted within an hour, now it runs already a day.

This is my test script to put the system under heavy load for 120s, idle for 120s and repeat:

opkg update && opkg install stress
while true; do
  stress --cpu 8 --io 4 --vm 2 --vm-bytes 1G --timeout 120s --hdd 2
  sleep 120
done