28 Aug
2018
28 Aug
'18
12:05 a.m.
Hi folks,
Back in 2012 I scripted some post-installation customization for when I
would build a new Linux machine. I suspect that all of what I did is no
longer needed for today's systems. I'm writing to see if someone can
confirm that.
What I did came from these links:
https://wiki.linuxaudio.org/wiki/system_configuration#the_kernel
https://wiki.linuxaudio.org/wiki/system_configuration#cpu_frequency_scaling
https://wiki.linuxaudio.org/wiki/system_configuration#hardware_timers
My new system runs the 4.17.17 kernel along with the rest of Fedora-27.
What do you think? Do I need to taylor the new machine in the above ways?
Thanks!
P.S.: My script is below, for the curious.
#!/bin/sh
# $Id: 36-linux_musicians,v 1.4 2012/11/16 05:56:14 kevinc Exp $
DATE=`date +%F-%T`
# http://wiki.linuxmusicians.com/doku.php?id=system_configuration#the_kernel
sudo cp /etc/default/grub /etc/default/grub-${DATE}
sudo cp /boot/grub2/grub.cfg /boot/grub2/grub.cfg-${DATE}
# cp /etc/default/grub grub
sudo perl -p -i -e 's/(^GRUB_CMDLINE_LINUX=\"nomodeset.*rhgb) quiet$\"/$1
quiet threadirqs\"/' /etc/default/grub
sudo /sbin/grub2-mkconfig -o /boot/grub2/grub.cfg
#
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#cpu_frequen…
# echo -n performance \
# | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
sudo touch /etc/rc.d/rc.local
cp /etc/rc.d/rc.local rc.local_cpufreq
cat << EOF >> rc.local_cpufreq
#!/bin/sh
for cpu in /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
do
echo -n performance > \$cpu
done
echo 3072 > /sys/class/rtc/rtc0/max_user_freq
EOF
sudo cp rc.local_cpufreq /etc/rc.d/rc.local
sudo chmod 755 /etc/rc.d/rc.local
#
http://wiki.linuxmusicians.com/doku.php?id=system_configuration#hardware_ti…
/bin/rm -f 40-timer-permissions.rules
cat << EOF > 40-timer-permissions.rules
KERNEL=="rtc0", GROUP="audio"
KERNEL=="hpet", GROUP="audio"
EOF
sudo cp 40-timer-permissions.rules /etc/udev/rules.d/
sudo chmod 644 /etc/udev/rules.d/40-timer-permissions.rules
cat << EOF > 60-max-user-freq.conf
# High Precision Event Timer for performance audio/MIDI
dev.hpet.max-user-freq=3072
EOF
sudo cp 60-max-user-freq.conf /etc/sysctl.d/
sudo chmod 644 /etc/sysctl.d/60-max-user-freq.conf
cat << EOF > 60-vm.swappiness.conf
# Delay start of use of swap partitions
vm.swappiness = 10
EOF
sudo cp 60-vm.swappiness.conf /etc/sysctl.d/
sudo chmod 644 /etc/sysctl.d/60-vm.swappiness.conf
cat << EOF > 93-audio_limits.conf
# Increase priority of audio applications
# # maximum realtime priority
@audio - rtprio 90
# maximum locked-in-memory address space (KB)
@audio - memlock 2000000
EOF
sudo cp 93-audio_limits.conf /etc/security/limits.d/
sudo chmod 644 /etc/security/limits.d/93-audio_limits.conf
exit
28 Aug
28 Aug
1 a.m.
On Mon, 27 Aug 2018 13:05:30 -0700, Kevin Cosgrove wrote:
What I did came from these links:
https://wiki.linuxaudio.org/wiki/system_configuration#the_kernel
Do you want to build a real-time kernel or do you want to stay with the
kernel that already is installed? If you want to build a kernel, you
might also want to care about the tickles config and the timers config.
$ zgrep -i no_hz /proc/config.gz
CONFIG_NO_HZ_COMMON=y
CONFIG_NO_HZ_IDLE=y
# CONFIG_NO_HZ_FULL is not set
CONFIG_NO_HZ=y
It doesn't harm to care about the governor, since it could improve
performance. I don't think you need a loop to set the governor for all
cores.
This most likely is outdated.
$ zgrep -i timer /proc/config.gz
# Timers subsystem
CONFIG_HIGH_RES_TIMERS=y
CONFIG_POSIX_TIMERS=y
CONFIG_TIMERFD=y
CONFIG_OPROFILE_NMI_TIMER=y
CONFIG_HPET_TIMER=y
CONFIG_X86_PM_TIMER=y
CONFIG_NETFILTER_XT_TARGET_IDLETIMER=m
CONFIG_HW_RANDOM_TIMERIOMEM=m
CONFIG_HANGCHECK_TIMER=m
CONFIG_PPS_CLIENT_KTIMER=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM_TIMER=y
CONFIG_SND_HRTIMER=m
CONFIG_SND_SEQ_HRTIMER_DEFAULT=y
CONFIG_LEDS_TRIGGER_TIMER=m
CONFIG_IIO_HRTIMER_TRIGGER=m
My new system runs the 4.17.17 kernel along with the
rest of Fedora-27.
/etc/rc.d/ most likely is an outdated location.
What kind of computer are you using, that you care about swappiness?
Maybe you distro migrated from the 'audio' group to a 'realtime'
group.
"@realtime - rtprio 99
@realtime - memlock unlimited" -
http://jackaudio.org/faq/linux_rt_config.html
'rtprio 99' sometimes is discussed, but 'memlock unlimited' usually
isn't discussed. YMMV!
--
pacman -Q linux{,-rt{-pussytoes,-cornflower,,-securityink}}|cut -d\ -f2
4.18.3.arch1-1
4.18_rc8_rt1-1
4.16.18_rt12-1
4.16.18_rt11-1
4.16.18_rt10-1
2:58 a.m.
On Mon, 27 Aug 2018, Kevin Cosgrove wrote:
# | sudo tee
/sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
sudo touch /etc/rc.d/rc.local
cp /etc/rc.d/rc.local rc.local_cpufreq
cat << EOF >> rc.local_cpufreq
#!/bin/sh
Some things have changed with cpufreq.
- in days of old there was /etc/rc.d/*ondemand that ran 60 seconds after
startup. This means no matter what you set for cpufreq it gets
down graded 60 sec later. disable ondemand if your os comes with
it.
- Now days there is kernel modules that need to be loaded and effective
before changing cpufreq stuff, otherwise it doesn't work... and
ondemand has been moved to systemd to ensure this. So it is best
if your os uses systemd to move you cpufreq setting script to
systemd to replace ondemand. BTW this ondemand also waits 60
seconds.
- newer intel cpus have a thing called "Boost" that can change your cpus
frequency up and down above what performance sets it to. There are
three choices here: Turn boost off in bios. Turn it off at run
time. Set performances minimum and max speed to compensate...
maybe higher than performance would. (yes I have more xruns at
low latencies with Boost on)
Setting performance is not about making sure your cpu runs as fast as
possible. It is about making sure the cpu speed does not change, It seems
at speed down changes I get xruns. However, I have set cpu governor to
USER and set it hard to 800Mhz (lowest possible) and still very good xrun
performance (like none in 8 hours running) while ondemand still gives
xruns. So choose your speed and monitor cpu temperature and run it at the
speed that gives you the highest temperature you are comfortable with.
IMO you should be monitoring temperature anyway to catch dust build up or
fan failure.
--
Len Ovens
www.ovenwerks.net
10:53 a.m.
Hi,
some things seems to be distro specific and other depend on the used
CPU.
On Mon, 2018-08-27 at 15:58 -0700, Len Ovens wrote:
Some things have changed with cpufreq.
- in days of old there was /etc/rc.d/*ondemand that ran 60 seconds after
startup. This means no matter what you set for cpufreq it gets
down graded 60 sec later. disable ondemand if your os comes with
it.
- Now days there is kernel modules that need to be loaded and effective
before changing cpufreq stuff, otherwise it doesn't work... and
ondemand has been moved to systemd to ensure this. So it is best
if your os uses systemd to move you cpufreq setting script to
systemd to replace ondemand. BTW this ondemand also waits 60
seconds.
Newer Intel CPUs might use 'powersave' instead of 'ondemand' and the
default could be the one chosen by the kernel's config. I still don't
understand this relatively new GOV_SCHEDUTIL thingy, but I didn't have
done any research to learn something about it ;).
Regarding Ubuntu (at least for Xenial) there indeed is 'ondemand' in
/etc/rc.d/, /etc/init.d/. However, I stay with 'powersave' or 'ondemand'
as default and change the governor to 'performance' if I run an audio
session on all of my Linux installs. Batterie charge OTOH might suffer
from 'ondemand'. Thanks to this thread I might understand this
GOV_SCHEDUTIL thingy, INTEL_PSTATE seems to affect the defaults.
"Note: The intel_pstate driver supports only the performance and
powersave governors, but they both provide dynamic scaling. The
performance governor should give better power saving functionality than
the old ondemand governor
[ https://www.phoronix.com/scan.php?page=news_item&px=MTM3NDQ ]."
- https://wiki.archlinux.org/index.php/CPU_frequency_scaling#Scaling_governors
I noticed that 'irqbalance' is there, too.
I don't have a link at hand, but IIRC it shouldn't be used with audio
real-time.
Just in case I run 'sudo apt purge irqbalance' right now, but usually
I'm using Arch where it never was installed.
Regards,
Ralf
11:07 a.m.
On Mon, 27 Aug 2018 13:05:30 -0700, Kevin Cosgrove wrote:
's/(^GRUB_CMDLINE_LINUX=\"nomodeset.*rhgb)
quiet$\"/$1 quiet
threadirqs\"/' /etc/default/grub sudo /sbin/grub2-mkconfig
-o /boot/grub2/grub.cfg
You might want to test if 'nopti' makes a difference.
$ grep readirqs /boot/syslinux/syslinux.cfg
LABEL Threadirqs
MENU LABEL Arch Linux ^threadirqs
APPEND root=LABEL=s3.archlinux ro threadirqs
LABEL Threadirqs_nopti
MENU LABEL Arch Linux threadirqs ^nopti
APPEND root=LABEL=s3.archlinux ro threadirqs nopti
I don't know, if it makes a difference.
11:32 a.m.
On Tue, 28 Aug 2018, Ralf Mardorf wrote:
Regarding Ubuntu (at least for Xenial) there indeed is
'ondemand' in
/etc/rc.d/, /etc/init.d/. However, I stay with 'powersave' or 'ondemand'
Not any more. It is there until 16.04 at least but vanishes at least by
18.04 to be replaced by /lib/systemd/system/ondemand.service which calls
/lib/systemd/set-cpufreq. The name ondemand is, as you say, misleading
and powersave even more so. where powersave used to be "run at lowest
speed" it is now what ondemand was supposed to be, but handled by the cpu
itself. ondemand, I have read, uses more power than performance, but
powersave works correctly. my cpu temp is higher at idle in performance
than powersave... I don't have anything old enough to test ondemand with.
In anycase, ondemand.service sets powersave in my case.
Installing cpufrequtils and setting it to set performance at boot no
longer works as I said due to kernel modules missing at the time it runs
at boot.
Using a utility to change cpu govering on the fly according to use does
make sense.
For many people using usb devices at 128/2 or higher, this probably
doesn't matter, but I like to make things work as well as possible at 16/2
so that at higher latency I don;t get surprised... but most usb devices
don't work that low. (USB clock is 1ms so probably 32/2 is lowest).
USB is not a gift for low latency audio, but a great boon for Linix
compatablility.
--
Len Ovens
www.ovenwerks.net
8:37 p.m.
Ralf Mardorf wrote:
On Mon, 27 Aug 2018 13:05:30 -0700, Kevin Cosgrove
wrote:
This most likely is outdated.
All these settings are for programs that access the timers directly
from user space. The ALSA sequencer was _never_ affected by them.
Regards,
Clemens
2094
days inactive
2095
days old
linux-audio-user@lists.linuxaudio.org
7 comments
4 participants
participants (4)
-
Clemens Ladisch -
Kevin Cosgrove -
Len Ovens -
Ralf Mardorf