Category: PC Tweakage

Depending on a solid model’s complexity, OpenSCAD will sometimes chew through system memory, consume the entire swap file, and then fall over dead. In an attempt to work around that situation, I recently jammed a 32 GB USB drive into the back of the box, turned it into a swap device, and then told the kernel to back off its enthusiasm for swapping.

Format the USB drive as a swap device:

sudo mkswap /dev/sd??   #--- unmount it before you do this!
Setting up swapspace version 1, size = 31265292 KiB
no label, UUID=0f559a8c-67b7-4fa3-a709-17aeec3104c4

Add it to /etc/fstab and set swap priorities:

# swap was on /dev/sdb3 during installation
UUID=e8532714-ad80-4aae-bee7-a9b37af63c8c none  swap sw,pri=1	0 0
UUID=0f559a8c-67b7-4fa3-a709-17aeec3104c4 none	swap sw,pri=5	0 0

Turn it on:

sudo swapon -a

Following those directions, dial back the kernel’s swappiness and limit the file cache growth:

sudo sysctl -w vm.swappiness=1
sudo sysctl -w vm.vfs_cache_pressure=50

Those commands now live in /etc/sysctl.d/99-swappiness.conf:

cat /etc/sysctl.d/99-swappiness.conf
# Improve responsiveness by reducing cache swapping
vm.swappiness=1
vm.vfs_cache_pressure=50

For whatever reason, WordPress turns underscores into blanks, so those obvious typos aren’t, really.

And then it should Just Work.

The box has 4 GB of RAM and, under normal circumstances, doesn’t swap at all, so I expect the USB drive should kick in only for extreme OpenSCAD models. The swappiness tuning should help during ordinary operation with large file operations.

I have no results to report, but if something blows up, I know what changed…

It turns out that the audio-over-HDMI/DisplayPort channel which, for whatever reason, is the only way to get audio out of the Optiplex 980 with the big Dell U2711 monitor starts up AT MAXIMUM VOLUME! regardless of the GUI’s Pulseaudio mixer setting that’s diligently saved-and-restored across sessions. That makes a certain perverse sense, as the digital-to-analog converter & power amp live inside the monitor.

Manually adjusting the GUI mixer by one click, either up or down, forces the new setting out over the digital link to the monitor, after which the audio output corresponds to the mixer; I never remember that until just after some dipshit auto-play video lights up with a fanfare.

Setting the mixer to the same value doesn’t force an update, so the obvious solution (at least to me) of sending a fixed initial value doesn’t work; it’s optimized away. I think that’s why the initial update doesn’t happen: the stored volume is the same as the, ah, stored volume, so there’s no need to tell the monitor.

The automatic solution involves putting two more commands in my ever-growing ~/.config/startup.sh:

amixer -D pulse sset Master 26%
amixer -D pulse sset Master 1%-

That sets a rational level (which might be the same as the existing one from the previous session), then changing it by one tiny click to force the new value out to the monitor.

And then It Just Works…