How-to: Gentoo Linux

@reC suggested I put together a guide for setting up Gentoo Linux with a configuration suitable for use with Purism hardware. As I plan to write one for putting gentoo on the L5-E when it ships, I figure writing one for x86_64 should save some time later. As the Arch install guide by @dc3p is excellent, I’m largely following their layout.


  • Gentoo Linux 17.1, desktop/plasma non-systemd
  • Grub bootloader
  • BIOS mode
  • BTRFS compressed root
  • fat32 /boot
  • ZRam swap
  • Jack audio with pulseaudio bridge

All the usual warning apply. If you have important data, back it up and test the backup before you start. If you can’t afford to have the laptop offline, don’t start. Gentoo is impressively stable, but it does require some care, the willingness to actually read error messages, and on low-end and mobile hardware, time. Expect to set the install up and let it run overnight, then spend a bit more time finishing up.

If you want to experiment with Gentoo, without risking leaving your computer unbootable, a chroot, VM, or prefix install is a good idea.

Things to know about Gentoo

  • Rolling Source-based release
  • All flavors (kde, gnome, et cetera) share the same repositories, and use different profiles for setting the default software.
  • If you get stuck, the wiki is a good place to start. The #gentoo channel on freenode IRC is also reasonably friendly.
  • Gentoo doesn’t have a conventional installer, like other distros. Instead, it requires any live system capable of using chroot for the initial setup.


Before we can start the actual install, some basic setup is required. Now is also a good time to figure out things like what filesystem you want, what you want encrypted, and so on.

For use with a VM, you can use losetup to get yourself a loop block device. For a chroot install, you can skip this step and go to the install section.

General notes on partition layout and live system setup

  • If you are running BTRFS as your main partition, you can install gentoo into a new subvolume, using the existing install as the live system.
  • You cannot generally resize a partition while it is in use, so if you aren’t using a filesystem that supports subvolumes, you’ll need to at least use a portable live system if you need to shrink a partition to make space for Gentoo.
  • If you want a portable install, putting Gentoo itself on an external USB stick works quite well, and it can then be used for installing other systems.
  • If you’re bootstrapping without an existing system, I find the Linux Mint Debian liveCD works quite well for having a usable environment from which to install.

1. Partitioning the disk

I’m assuming /dev/sda is the hard drive, and it’s only used for Gentoo. Adjust accordingly.

  • GParted works well for disk partitioning
  • Leave a 32 mb free at the start of the drive so we can be sure grub has enough space
  • Create a partition for boot. Each kernel takes 15 MB or so. I usually devote 128MB to /boot. Format it to fat16. This gives you the best chance of rescue booting the system in the event of a hardware failure (and you move the drive to another computer).
    • make sure to flag it bootable
  • Create a partition for root out of the remaining space, format it BTRFS.
    • If you want encryption, see the arch how-to for setting up luks and lvm.

2. Mount the new root partition

mkdir /tmp/mnt
mount /dev/sda2 /tmp/mnt -o subvol=/,noatime,compress=zlib:9,ssd 

Obviously, if you’re using spinning rust, omit the ssd option.

3. Setup the subvolumes

cd /tmp/mnt
btrfs subvolume create home
btrfs subvolume create root
btrfs subvolume create local

You may want etc in its own subvolume, if you edit lots of config files yourself. You may want opt as well, if you use proprietary software.

4. Remount the root partition with the correct subvolume

cd /tmp
umount mnt
mount -o subvol=root,noatime,compress=zlib:9,ssd /dev/sda2 /tmp/mnt
cd /tmp/mnt
mkdir -p home usr/local
mount /dev/sda2 home -o subvol=/home,noatime,compress=zlib:9,ssd
mount /dev/sda2 usr/local -o subvol=/local,noatime,compress=zlib:9,ssd
mount /dev/sda1 /boot

If you want better and faster compression, zstd works better than zlib, but requires a relatively recent kernel.


1. Download the stage3 tarball.

  • This can be done in advance, but I like to get a copy of it sitting in the new root.
  • You can get stage3 from here.
  • The standard version is at the top, if you want systemd, or some other preset profile, grab it from the list at the bottom. You can download it through your browser, or just right-click and copy-link-location
wget "link-from-above"
tar -xaf stage3-*

2. Mount everything needed in the chroot

mount --bind /dev dev
mount --bind /proc proc
mount --bind /sys sys
mount --bind /dev/pts dev/pts
cp /etc/resolv.conf etc

3. Chroot

chroot .
. /etc/profile

4. Get the latest repository snapshot


5. Install minimal distcc

This lets you network computers together to speed up the install process. Skip if you only have one computer, or don’t want to install distcc on your other computer(s). Ideally, you want gigabit ethernet between the computers involved, but 100mb does ok.

USE="-gtk -ipv6 -zeroconf" emerge -av sys-devel/distcc

It will tell you what packages will be installed and prompt for confirmation.
On the helping computers, install the distcc server package (might be called distccd), then start distccd

user@helping-computer $ distccd --allow $specific_ip_or_safe_subnet --jobs $number_of_cpu_cores --log-stderr --no-detach

If you aren’t on a trusted network, you can use ssh port forwarding, but that is outside the scope of this guide.

Add each server to the list of distcc servers

echo $ip_address_of_helping_computer/$number_of_jobs >> /etc/distcc/hosts

Once done, you can run distcc -j to calculate how many distcc jobs to use

6. Customize make.conf

nano /etc/portage/make.conf

Add or change the following lines, you can skip the comments
$lowercase_variables should get customized to your set up.

To find your $arch value, run
gcc -march=native -Q --help=target | grep march

# Enable distcc and downloading multiple packages at once
FEATURES="distcc parallel-fetch"

# Enable parallel builds by default
MAKEOPTS="-l $number_of_cpus -j $number_of_distcc_jobs"

# Build for a specific CPU, leave it out if you want a portable install
COMMON_FLAGS="-O2 -pipe -march=$arch"

# If you want only free software, add the following

# A slightly less restrictive setting, which allows open source, free to use, including non FSF approved licenses.


# At the next line if you want 32bit multiarch support
ABI_X86="64 32"

# Global use flags for when you want something always or never used
USE="-systemd -bindist jack -gnome openssl wayland elogind -consolekit"

7. Setup locale

eselect locale list

Pick a number from the list, which matches your preferred language (the utf8 version). You can pipe the output to grep if you know what you want

eselect locale list | grep en_US

Then set it.

eselect locale set 256

8. Setup timezone

emerge -av app-eselect/eselect-timezone
eselect timezone list | grep America/Los_Angeles
eselect timezone set 147

9. Install basic tools

emerge -avj gentoolkit eix genkernel btrfs-progs rsyslog unp lzop


10. Get the kernel sources

If you want maximum efficiency, you need to set march=native for the kernel build. This requires a set of patches still considered experimental, but which are reasonably stable, at least on x86_64.

echo sys-kernel/gentoo-sources experimental >> /etc/portage/package.use/gentoo-sources

Then it’s time to pick your kernel version,

eix gentoo-sources

will list the available version. The green ones are stable. If you want the latest features, grab the latest yellow one, it’s usually fine, and if it isn’t, changing later isn’t too hard. Note that you’ll need to run dispatch-conf again if you want to run a version not marked stable.

emerge -av --autounmask gentoo-sources:5.4.7

Will grab the latest version (at the moment). Note that this is a slotted package, which means you can install multiple versions in parallel.
If it’s the first one installed, it will get automatically selected, but it’s good to manually check

eselect kernel list

You can pick whichever version you want as active. Once that’s done, get the .config from the PureOS kernel, and copy it to /usr/src/linux (in the chroot). apt-get source linux-kernel from within PureOS should get the .config, or you can get the source package manually through a web browser and unpack it. If you’re running PureOS, you may also be able to get it from /proc/config.gz, but I don’t know if that is enabled or not.

11. Apply the configuration changes

We changed some global use flags back in step 6, so we want to rebuild the affected packages before we go asking for lots of installs.
Note that we’ll later need sdl2, with gles support, so let’s mark that now

echo media-libs/libsdl2 gles >> /etc/portage/package.use/libsdl2
emerge -avj --autounmask --newuse --deep @system

This may require some USE changes, if it does, hit y to accept them, then review them via dispatch-conf and merge them (use-new).

12. Pick a profile

We want desktop/plasma 17.1, find it in the list, it’s currently 23

eselect profile list
eselect profile set 23

13. Time to install the desktop meta package

emerge --autounmask -avj kde-meta

Note that this will propose some USE flag changes, and requires accepting the MPEG-4 license, which is open source, but not GPL compatible.

If you want to not accept the MPEG-4 license, you can disable CD support in kdemultimedia-meta by running

echo kde-apps/kdemultimedia-meta -cdrom >> /etc/portage/package.use/nompeg4

Regardless, accept the proposed USE changes, then review and merge them via


Note that if you want to revert the proposed changes, z will ‘zap’ the changes, leaving you with the old version. u is what you usually want, as it uses the proposed new version.

If you want a lighter weight install, plasma-meta instead of kde-meta doesn’t grab the whole suit of kde apps.
If you want something other than kde, grab the matching profile (for gnome), or the generic desktop profile.
Then install the related meta packages, which are usually obvious with a bit of looking (e.g. eix xfce4-meta)

With the proposed changes committed, it’s time to kick off the main install. This is going to take a while.

emerge -avj --keep-going kde-meta

Assuming it looks right, tell it to start, then go to bed. Seriously, on a low power laptop like the librem, it’ll take hours.

Note that it might fail to build everything. There are a few packages which don’t like building in parallel, and tracking down why can be incredibly difficult. If it didn’t manage to build everything, first thing to do is to try again, usually it’ll just work.

14. Build the kernel

genkernel --makeopts="-l $num_cpus -j $num_distcc_jobs" --oldconfig --menuconfig --loglevel=5 --kernel-cc=distcc --utils-cc=distcc all

That will bring up the ncurses menu configuration for the kernel. Make sure /proc/config.gz support is enabled, and set the local version string to include where you got the config (PureOS.VERSION) or similar. Also if you enabled the experimental use flag, under processor type and features->processor family, set the CPU to the one matching your computer. If you aren’t using distcc, you can just set it to autodetected. If you aren’t sure what kind of CPU you have, cat /proc/cpuinfo will tell you.

If you want zram support, enable all the related flags.

Device Drivers->Block Devices-> Compressed RAM block device
+Track zRam block satus
+ Write back incompressible or idle page

Once you are done, save it back to .config, and exit.

It will start the build all on its own, and put the results in /boot

15. fstab

Get the uuid of the root and boot partitions via
blkid /dev/sda1 -o value | head -n 1
blkid /dev/sda2 -o value | head -n 1
Edit /etc/fstab and add the following, using the UUIDs from the preceeding

UUID=$ROOTUUID       /                       btrfs           noatime,ssd,compress=zstd:9,subvol=/root                 0 1
UUID=$ROOTUUID       /home                       btrfs           noatime,ssd,compress=zstd:9,subvol=/home                 0 1
UUID=$ROOTUUID       /usr/local                       btrfs           noatime,ssd,compress=zstd:9,subvol=/local                 0 1

UUID=$BOOTUUID       /boot                       vfat           noatime                 0 1

16. Grubbing

Install the grub-2 package,

emerge -av sys-boot/grub

Once that is done, install grub to the MBR of the hard disk.

grub-install /dev/sda

Generate the grub2 config file

grub-mkconfig > /boot/grub/grub.cfg

Verify the generated file is sane, there should be an entry for Gentoo at the very least. If it doesn’t detect the right subvolume, add


to the end of the linux /kernel... line for the Gentoo entry.

17. Don’t forget to set a passwd


18. Add a user account

emerge -av superadduser

Follo the prompts, for additional groups, at least provide

19. Setup auto-login

We’ll secure this later

nano /etc/inittab

Find the line starting with c1:12345 under # Terminals
Change it to

c1:12345:respawn:/sbin/agetty --skip-login --login-options "-f $your_user_name STARTW=true" 38400 tty1 linux

20. Make tty1 go straight to a graphical shell

Add the following to /home/$USER/.bashrc

if [ "$STARTW" != "" ]; then
        unset STARTW
        exit `~/startw`

If you want X11 instead of wayland, change startw to startx, and configure ~/.xinitrc accordingly.

Create /home/$USER/startw with the following

XDG_SESSION_TYPE=wayland dbus-run-session startplasma-wayland

Set it executable

chmod +x /home/$USER/startw`

21. Reboot

Exit the chroot, unmount /dev/pts, /dev, /proc, /sys, then reboot.

22. Setup auto lock on login

echo '#!/bin/bash > ~/autolock`
echo loginctl lock-session >> ~/autolock
chmod +x ~/autolock

Add ~/autolock to the list of startup applications in kde.

23. Setup zram

emerge -av zram-init

Then edit /etc/conf.d/zram-init
Set the number of devices to one, then find the section for device zero, and use something like the following settings

flag0= # The default "16383" is fine for us
size0=81920 # 80 GB of compressed data, more than this and it chokes
mlim0=2G # only 2 GB of physical memory
back0=/dev/loop0 # requries a whole block device, we'll set this up next
notr0= # keep the default on linux-3.15 or newer
maxs0=2 # maximum number of parallel processes for this device
algo0=zstd # zstd (since linux-4.18), lz4 (since linux-3.15), or lzo.
           # Size: zstd (best) > lzo > lz4. Speed: lz4 (best) > zstd > lzo
labl0=zram_swap # the label name
uuid0= # Do not force UUID

Time to set up the backing device, if you want to get fancy, you can use anything for this, including network mounts or OpenCL vram devices. For simplicity, we’ll use a non-compressed file in /zram

mkdir /zram
cd /zram
touch loop0.img
btrfs property set loop0.img compression ""
dd if=/dev/zero of=loop0.img bs=1M count=10000

Now we just need to make loop0 start on startup, and make zram-init start on startup.

Edit /etc/init.d/loop0

depend() {
        need localmount

start() {
        ebegin "Starting loop0"
        /sbin/losetup /dev/loop0 /zram/loop0.img
        eend $? "Failed to start loop0"

stop() {
        ebegin "Stopping loop0"
        /sbin/losetup -d /dev/loop0
        eend $? "Failed to stop loop0"

Then add loop0 to the need line in /etc/init.d/zram-init


rc-update add zram-init default

to enable zram on startup.
Note that it would be best to create a new memory cgroup, and add all userspace programs to it on startup, with a memory limit 2GB less than the system memory.

That requires write access to /sys/fs/cgroup/memory, so we’ll add a setuid helper.
Make a file called limitmem.c with the following

#define _GNU_SOURCE
#include <string.h>
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char** argv) {
        if (argc > 1) {

                size_t l = strlen(argv[1]);
                if (l > 5) { return 0; }
                for (char idx=0; idx<l; idx++) {
                        if (argv[1][idx] < '0' || argv[1][idx] > '9') {
                                return 1;

                setresuid(0, 0, 0);
                system("mkdir -p /sys/fs/cgroup/memory/plasma");
                system("echo 2147483648 > /sys/fs/cgroup/memory/plasma/memory.limit_in_bytes");
                char tmp[] = "echo       > /sys/fs/cgroup/memory/plasma/tasks";

                strncpy(&tmp[5], argv[1], l);

        return 0;

Then compile it with

gcc limitmem.c -o limitmem

Then switch to root, own it as root, and mark it suid

chown root.root limitmem
chmod +s limitmem

Exit root, and add the following to the startw script, at the top

./limitmem $$

Final thoughts

That pretty much covers the basic setup. You’ll probably want to add standard programs, like libreoffice and what not.
I’ll add a second post to describe how I have Jack set up for easy use.


did you write it from muscle-memory or had “help” :stuck_out_tongue:

do you do this every-time you clean install or do you restore every time from where you were comfortable enough to call it “my-personal-distro” ? :star_struck:

Mostly from meatspace memory, with a couple references to /root/.bash_history.

Because of how amazingly stable gentoo is, I pretty much never need to do a clean install. If I had a bunch of very similar computers, I’d probably clone that basic install to each of them, rather than doing a clean reinstall. As it is, all the computers I have are very different, different video cards, different CPUs, so a system build for one doesn’t work on the others. Hence I pretty much go through this entire process when I need to set one up.
That said, the actual user time required is pretty minimal, it’s just the CPU time and wall time that’s long.


Setting up Jack

I’m told pulseaudio has improved recently, but I wouldn’t know. I quit using it due to audio routing issues with a laptop about 4 years ago. If your use-case matches the usual pulseaudio use case, you’ll probably be reasonably happy with it. If you want to do anything non-standard (listen to music out the integrated speakers while listening to a game in your headphones, support audio from multiple users, and so on), read on.

Which Jack?

There are 2 implementations of the Jack audio connection kit.
Jack1 is written in C, the package is jack-audio-connection-kit
Jack2 is written in C++, the package is jack2
For most things, both work fine, clients can’t really tell the difference. For fancier, multi-sound card setups, you want jack2.
The install process above will have pulled in jack1, but switching is simple. We want to make sure to build with libsamplerate support.

echo media-sound/jack2 libsamplerate >> /etc/portage/package.use/jack2
emerge -av jack2

Other packages

For graphically managing connections, you’ll also want to grab a frontend. There’s a couple floating around, but I find qjackctl to be the simplest.
You also want the alsa-jack bridge, from alsa-plugins

emerge -avj qjackctl alsa-plugins

If you want the fancy setup, you’ll also need to grab the jack python client from here. I recommend installing it from github. You also need dev-python/pyudev and my manager library from here.

Gut pulseaudio

Some programs will only talk through pulseaudio, so we want it installed, and we want it to start when needed (I actually start it manually when I want it, but set it to start automatically when I set it up for other people).

We want pulseaudio to accept mic input from jack, and route all output to jack.

Add or uncomment the following lines in /etc/pulse/

load-module module-jack-sink
load-module module-jack-source
set-default-sink jack_out
set-default-source jack_in

Find and make sure the following lines are commented out

#load-module module-alsa-sink
#load-module module-alsa-source device=hw:1,0
#load-module module-null-sink
#load-module module-pipe-sink

### Automatically load driver modules depending on the hardware available
#load-module module-udev-detect
### Use the static hardware detection module (for systems that lack udev support)
#load-module module-detect

If you don’t want pulseaudio to start automatically, set

autospawn = no

in /etc/pulse/client.conf. This will cause some programs which support both pulseaudio and jack, but which prefer pulseaudio, to correctly connect to jack.

Common setup

However you start your actual jack server, you need to tell applications to prefer it. Media players and the like will usually let you select jack explicitly in their audio setup menus. SDL applications can be told to use jack by setting SDL_AUDIODRIVER=jack as an environment variable. OpenAL can be told to use jack by creating ~/.config/alsoft.conf with the following


Alsa applications can be told to use the alsa-jack bridge by creating ~/.asoundrc with the following

pcm.!default {
    @func refer
    name { @func concat 
           strings [ "pcm."
                     { @func getenv
                       vars [ ALSA_DEFAULT_PCM ]
                       default "jack"

pcm.pulse { type pulse }

pcm.jack {
    type jack
    playback_ports {
        0 system:playback_1
        1 system:playback_2
    capture_ports {
        0 system:capture_1

Note that you can set ALSA_DEFAULT_PCM=pulse on a per-application basis to tell programs which don’t behave properly to use pulseaudio instead.

Basic setup

For the simplest setup, just launch qjackctl. Go into setup->settings, and select the alsa driver. For the interface, pick your hardware interface you want audio to use. If you know what your actual hardware is, you can probably look up optimal settings for sample rate, frames, and periods/buffer, otherwise it’ll take a bit of trial and error. More frames/period and more periods/buffer increases audio latency, while decreasing CPU load and makes underruns and dropouts less likely. Sample rate is best set to something the sound card natively supports. I don’t usually run with real-time enabled, but you can. If you do, you need to give the audio group real-time permissions, or add the user to a different group and give it real-time permissions

Add the following to /etc/security/limits.conf

@audio          -       rtprio          99
@audio          -       memlock         unlimited

There are some advanced options, under the advanced tab. This would let you use an external mic and an internal speaker or similar, set the number of channels to use, and so on. If you added the memlock permission for the audio group, leave the “no memory lock” unticked, and it will ensure the buffers used for audio don’t get swapped out.

Finally, if you want to use the old connections view instead of the new graph view, that is at the bottom of the the misc top level tab.

With all that done, close the options, and hit start. The start button should fade and the stop button should unfade. If not, click the messages button to see what went wrong.

You can then open the connections (or graph) window, and route audio as you like.

Advanced setup

This setup watches via udev for audio devices to be added or removed, and watches via the python-jack client for audio clients to be added. It supports multiseat setups, using udev seat tagging (only devices on the same seat as the watchdog uses will be added). The first time you run it, it will create a default config in ~/.config/jack/, a default rule file in ~/.config/jack/ All cards are added, and all clients get routed to all hardware outputs by default. Note that if you want to capture a mic with a program, you have to manually connect that each time. I consider that a feature, as it means web pages and the like don’t get to auto-reconnect even if you accidentally tell your browser to allow it.

Anyway, here’s how to get it running

git clone
mkdir -p ~/.local/lib64/python3.6/site-packages
cp -r jackcontrol/jackcontrol ~/.local/lib64/python3.6/site-packages
rm -r jackcontrol
python3.6 -m jackcontrol --verbose --print-cards --print-config

That will generate the default configs in ~/.config/jack, as well as show the audio devices and their properties detected on the system.
Like with qjackctl, you can set buffer size, sample rates, and so on. Note that the quality parameter determines how good a job is done with resampling if the audio rates don’t match up, 4 is best/most expensive, 0 is worse/cheapest.

Anyway, if you want to customize what gets sent where, edit ~/.config/jack/

The example rule takes any output port (client wanting to play audio) that doesn’t start with Auto (the auto-added cards) , and attaches it to each auto-added card. Note that only the first rule which triggers an action applies, so you probably want to leave that one as a catch-all at the end.

Also note that it doesn’t re-route existing audio when a new card is plugged in. Adding a rule to do that is pretty easy, invert the values on input and output, change the match rule to match the added device, and set the target to what you want it to redirect (also a regex).

If you want to get really fancy, you can define a custom function called find_rule, whose signature is in the header of, which can order arbitrary changes to the connection graph.


that so much reminds me my setup I used in my youth :slight_smile: But nowadays I retreated to Arch and PA, as I don’t have access to server farm to do distcc and after measuring how much power it burns at home I’ve reconsidered it a bit. Same for jack, I’ve even ported netjack to ipv6 (as my home network is on ipv6) but then realised for home audio it’s just an overkill


If I need netjack, I run it over ssh port forwarding, so it’s encrypted (and network agnostic). As for being overkill, I run a multiseat desktop, so having a way to isolate audio devices is an absolute must. I don’t think I’d have gone to the effort of developing it otherwise.

As for power consumption, I live in a place with very cheap electricity ($0.10/kwh peak rate), and have to run a heater 9 months out of the year. I do tend to only install security patches in the summer though.

If you have a decently spec’d desktop (Ryzen 5 first gen or better), distcc over the network can’t really keep up with just building everything locally.

1 Like

how fast will it be (average) on a ryzen 8c-16t ?

1 Like

you cannot do multicast over ssh tunnel :slight_smile: and it is (was) needed for home audio to avoid manually patching dynamic clients (such as laptops).
Also I gave up having desktop for more than 10 years already and on laptop it’s really just a useless burn of the battery (even though my laptops are usually high-spec, except ultraportables).
But I do agree if you have a desktop - the listed above approach/configuration is what I’d do, high five for that.


For a 16t machine, you’ll want to change emerge -avj to emerge -av -j 16 --load-average=16, or it won’t saturate the CPU. You’ll also probably want to run chrt --idle -p 0 $$, so that the rest of the system will stay responsive during the emerge. That said, there will still be significant times when it can’t saturate the CPU, especially if you only have a sata hard drive. On an nvme drive, with an x370 and 3800x, it takes 2-3 hours for the major install step (kde-meta), and about 15 minutes for the kernel. It would likely be a bit faster if I had memory that could run at 3600Mt, as the crap kits from when ryzen first launched (2866Mt) mean I have a significant penalty for decoupling the infinity fabric clock from the memory clock.

1 Like

Yeah, lack of multicast is a good point. And yeah, I wouldn’t recommend gentoo on a laptop without the desktop’s help. Even if it’s a desktop-replacement laptop, they still generally don’t like running full-tilt for several hours, and often damage their batteries if you do that on a regular basis. Ultrabooks are especially bad on cooling performance.

1 Like

did you include the audio part in the guide specifically for the L5 or just because it’s something you personally have an interest in at the desktop level ?

Not specifically for the L5, but the L5’s problems with audio routing in pulseaudio is exactly the kind of crap that lead me to make the switch years ago. It sounds nice to have the computer automatically figure out what you want routed where, but if you have to choose between: (A) letting it auto-configure, and getting it right 90% of the time, but being unable to trivially correct that 10%; and (B) having to manually configure it in all but the simplest cases, but that manual configuration is trivial; I’ll choose B every time. Simple put, I need audio to just work every time.

1 Like

hmm … are you referring to the mhz/cas-latency here ? or something else ? you wrote “Mt” …

my understanding is that the higher the number is when dividing Mhz/Cas-Latency the better ryzen will perform … but higher than 300 (freq/latency) is quite expensive to buy and even more so with higher memory density (reduced overclock potential too)

DDR means dual-data-rate. The memory ticks on both the rising and falling edge of the clock signal, hence calling it 3600MHz is not quite accurate, the actual unit is mega-transfers, or 2x the memory bus speed.

Zen2 (most Ryzen3k, Threadripper3k and so on) gives access to several internal clock speeds that normally you can’t tweak, which is why the distinction actually matters, and even there, you only want to tweak the values if you are mixing odd components.

Anyway, to solve the Windows scheduler problems (and to save on manufacturing cost), Zen2 uses an I/O die, which removes the NUMA (non-uniform memory access) problems for the compute units, but they are still NUCA (non-uniform cache access). The communication between compute chiplets and the memory controller is governed by the Infinity Fabric clock (FCLK), the communication between the memory controller and the memory banks is governed by the memory clock (MCLK). As mentioned above, DDR memory ticks at twice the MCLK. By default, FCLK is auto-managed, to pin it equal to MCLK, as that lets the chiplets talk straight through the I/O die without any latency. The FCLK is rated to 1800MHz, but usually is stable to 1833 or 1866MHz, making 3600MT/s the sweet spot for memory speed. If you go above 3600MT/s, the FCLK drops into 2:1 mode, setting its clock at half the MCLK, which almost always results in higher latency for no meaningful throughput increase (have to hit like 4500MT/s+ to overcome the latency hit).

In my case, I have crap memory kits, so the MCLK is at 1483MHz, at that point, manually decoupling the FCLK and maxing it (1866MHz on my chip) lets the chiplets talk to each other enough faster to overcome the slight latency increase for not running in 1:1 mode. (IIRC, the magic number is FCLK > MCLK by at least 300MHz).

Bottom line is you want to hit at minimum 3200MT/s, and ideally 3600MT/s, whatever timings you can justify on price. As for what kits to buy, tighter timing 3200MT/s kits (like 14-14… or 14-16…) often will overclock happily to 3600MT/s if you loosen the timings. The actual performance improvement for 3600/14-16-16 vs 3600/16-19-19 isn’t that much, especially compared to going from 3000 to 3600 MT/s.

1 Like

in my case it’s 2x8gb @ 2666Mhz DDR4 desktop RAM modules. in your speech would that be 2666MT/s ? or rather 1333 in single-rate-mode :stuck_out_tongue: … from what you are saying i would need to invest practically two or three times as much money just to get to that sweet spot of FCLK symbiosis (is that correct ? made up meaning in different context again lol … ) my timings are 13-something-something from Kingston. HyperX-Predators really nice black design heat-spreader (no RGB bling-bling here thank-you-very-much)

At 13 timings, you can almost certainly push the clocks and loosen the timings (just avoid doing anything mission critical until you are certain the system stays stable even when the memory warms up). You almost certainly won’t get to 3600MT/s, but you might hit 3k. What CPU are you running? If it’s a 3rd gen ryzen, you could also go set the FCLK as high as you can. First gen ryzen had a significant performance jump getting to 2800, and plateaued at 3000. For second gen, 3000/3200 was the goal. In that respect, 3rd gen is actually more forgiving about low speeds, since you can boost the infinity fabric speed anyway.

Also, if it’s a 2 chiplet CPU (3700/3800x or similar), see if your bios has NUMA settings, and set it to the number of chiplets in your system. By default it hides the topography, since windows chokes, but the Linux scheduler is NUMA/NUCA aware, so you’ll get slightly improved scheduling with the topography exposed.

Also, before investing money in new RAM, ask yourself if the increased performance would actually help… You’re talking somewhere around 10% performance uplift for most tasks, probably.

1 Like

indeed … i was aware that it would be only a small increase in performance but i would have imagined that for such an amount of money it would give something to 20-25% (heh :P) … meh ! not going to bother with upping that memory until the next DDR5 probably … i’m not rendering movies so that isn’t such a big deal … but for a 2000+ frames animation every bit of performance squeezed counts …

i was looking at an x570 + 3950x r9(ryzen CPU 16-32t) with a 3600Mhz @ 16 cl but that’s too much …

Heh, I maybe would have bought a 3950x, if they’d been in stock. Probably just as well that they weren’t, as 8c/16t is honestly enough for what I do. Still would have been interesting to see if my x370 could successfully drive the 3950x, and maybe someday it would be useful.

As for performance impact, for some workloads, and with the 3950x, you could see 20-25% impact (comparing 2600 vs 3600), especially for I/O heavy tasks. The 10% figure is what you’re actually likely to see in everyday use, where there’s only one task using much CPU power at a time, and it’s only using 2-3 threads (games, video playback, web browsing).

would Chess experience be any FASTER for me :joy: ?

i wouldn’t DARE watch h265 on software alone … need hardware-playback-acceleration for that … an APU usually handles that quite well even through open-source-drivers … but not free-software :sweat:

that’s doable from pretty much any machine … as long as it doesn’t melt from heat like the L5 :cold_sweat:

is my friend :wink:

Chess, if it’s a multi-threaded AI opponent, actually probably would be considerably faster. But yes, I only need the octa-core system because it’s a multi-seat system, plus has remote users. Load average usually is ~3/3.5.