[LAU] performance problems after kernel/microcode update ?

[Niklas Reppel]

Hi,

i recently updated my Arch linux system, to to the following version:

Linux 4.18.6-arch1-1-ARCH #1 SMP PREEMPT

Afterwards, i noticed that something has changed regarding the realtime
permissions
and that i had to install a new package called 'realtime-priviliges',
which i never needed before,
and subsequently add my main user to the 'realtime' group.

In that wake, i updated the processor microcode, which i didn't use at
all before (there always was some
error message during bootup, but nothing else).

After being able to start JACK in realtime again, i felt that there was
a significant loss of performance.
Things that didn't cause any dropouts before now start to crackle and
gristle (as a sidenote, i mostly
use SuperCollider to make sound).

Also, and this puzzled me especially, there were dropouts, but no XRuns
... normally, when i push the
system to the limits, i get XRuns, that'd be expected. But now, it's
dropouts without, and they start way
earlier.

My machine has an Intel(R) Core(TM) i7-4600U CPU @ 2.10GHz Processor if
that info is of user for anyone ...

Anybody else noticed something like that recently ?

Best,
nik

[Michael Jarosch]

Post by Niklas Reppel
After being able to start JACK in realtime again, i felt that there was
a significant loss of performance.

Maybe it has nothing to do with a/the new realtime management, but with
spectre mitigation and stuff.

Phoronix listed all the kernel parameters to get rid of these
workarounds. I don't find the exact side anymore, but these are mainly
the parameters you have to add to your /etc/default/grub - only use
them, if you don't care about your system's security :D :

pti=off spectre_v2=off l1tf=off nospec_store_bypass_disable
no_stf_barrier


Greets!
Mitsch

[Tim]

Post by Niklas Reppel
Hi,
Linux 4.18.6-arch1-1-ARCH #1 SMP PREEMPT
Afterwards, i noticed that something has changed regarding the realtime
permissions
and that i had to install a new package called 'realtime-priviliges',
which i never needed before,
and subsequently add my main user to the 'realtime' group.
In that wake, i updated the processor microcode, which i didn't use at
all before (there always was some
error message during bootup, but nothing else).
After being able to start JACK in realtime again, i felt that there was
a significant loss of performance.
Things that didn't cause any dropouts before now start to crackle and
gristle (as a sidenote, i mostly
use SuperCollider to make sound).
Also, and this puzzled me especially, there were dropouts, but no XRuns
... normally, when i push the
system to the limits, i get XRuns, that'd be expected. But now, it's
dropouts without, and they start way
earlier.
that info is of user for anyone ...
Anybody else noticed something like that recently ?
Best,
nik

Hello, I always reply when I hear of crackles, pops, and dropouts
because it took me several months to figure out my problem with that.
Maybe it will help.

Here is the latest time I replied, a month ago, please scroll down:

http://linux-audio.4202.n7.nabble.com/M-Audio-Fast-Track-Pro-unreliable-distorted-recording-td89125i20.html#a106829

Long story short: Try running with only one processor core active.

It completely cured my problem, and another user's as well.
In my case the device is a PCI M-Audio delta1010, and in the
other user's case it was a similar ice1712-based card.
However in the above Fast-Track-Pro case, that's USB and we
don't yet know if the trick solved that user's problem...

Be patient: If the number of CPU cores is the cause it may take
several minutes for the crackling to appear since I believe what
happens is that some low-level 'counters/pointers' which should
always be in sync slowly approach and 'pass' each other, and that's
when the noise occurs.

In my case the very same symptom occurred in Windows.
That proved beyond doubt that it was a hardware issue.

Hope that helps.
Tim.

[David W. Jones]

Post by Niklas Reppel

Post by Niklas Reppel
Hi,
i recently updated my Arch linux system, to to the following
Linux 4.18.6-arch1-1-ARCH #1 SMP PREEMPT
Afterwards, i noticed that something has changed regarding the

realtime

Post by Niklas Reppel
permissions
and that i had to install a new package called

'realtime-priviliges',

Post by Niklas Reppel
which i never needed before,
and subsequently add my main user to the 'realtime' group.
In that wake, i updated the processor microcode, which i didn't use

at

Post by Niklas Reppel
all before (there always was some
error message during bootup, but nothing else).
After being able to start JACK in realtime again, i felt that there

was

Post by Niklas Reppel
a significant loss of performance.
Things that didn't cause any dropouts before now start to crackle

and

Post by Niklas Reppel
gristle (as a sidenote, i mostly
use SuperCollider to make sound).
Also, and this puzzled me especially, there were dropouts, but no

XRuns

Post by Niklas Reppel
... normally, when i push the
system to the limits, i get XRuns, that'd be expected. But now, it's
dropouts without, and they start way
earlier.

if

Post by Niklas Reppel
that info is of user for anyone ...
Anybody else noticed something like that recently ?
Best,
nik

Hello, I always reply when I hear of crackles, pops, and dropouts
because it took me several months to figure out my problem with that.
Maybe it will help.
http://linux-audio.4202.n7.nabble.com/M-Audio-Fast-Track-Pro-unreliable-distorted-recording-td89125i20.html#a106829
Long story short: Try running with only one processor core active.
It completely cured my problem, and another user's as well.
In my case the device is a PCI M-Audio delta1010, and in the
other user's case it was a similar ice1712-based card.
However in the above Fast-Track-Pro case, that's USB and we
don't yet know if the trick solved that user's problem...
Be patient: If the number of CPU cores is the cause it may take
several minutes for the crackling to appear since I believe what
happens is that some low-level 'counters/pointers' which should
always be in sync slowly approach and 'pass' each other, and that's
when the noise occurs.
In my case the very same symptom occurred in Windows.
That proved beyond doubt that it was a hardware issue.
Hope that helps.
Tim.

While I, on the other hand, use all cores (real and hyperthread) on my i7 with no crackles or distorted recordings and such at all. Same for the 4 real cores on my AMD desktop system.

In my opinion, most PC motherboards weren't designed with any audio thought beyond including an on-board audio chip.

--
David W. Jones
***@hawaii.rr.com
authenticity, honesty, community
http://dancingtreefrog.com

Sent from my Android device with F/LOSS K-9 Mail.

[Will Godfrey]

On Thu, 13 Sep 2018 15:48:11 -1000

Post by David W. Jones

Post by Niklas Reppel

Post by Niklas Reppel
Hi,
i recently updated my Arch linux system, to to the following
Linux 4.18.6-arch1-1-ARCH #1 SMP PREEMPT
Afterwards, i noticed that something has changed regarding the

realtime

Post by Niklas Reppel
permissions
and that i had to install a new package called

'realtime-priviliges',

Post by Niklas Reppel
which i never needed before,
and subsequently add my main user to the 'realtime' group.
In that wake, i updated the processor microcode, which i didn't use

at

Post by Niklas Reppel
all before (there always was some
error message during bootup, but nothing else).
After being able to start JACK in realtime again, i felt that there

was

Post by Niklas Reppel
a significant loss of performance.
Things that didn't cause any dropouts before now start to crackle

and

Post by Niklas Reppel
gristle (as a sidenote, i mostly
use SuperCollider to make sound).
Also, and this puzzled me especially, there were dropouts, but no

XRuns

Post by Niklas Reppel
... normally, when i push the
system to the limits, i get XRuns, that'd be expected. But now, it's
dropouts without, and they start way
earlier.

if

Post by Niklas Reppel
that info is of user for anyone ...
Anybody else noticed something like that recently ?
Best,
nik

Hello, I always reply when I hear of crackles, pops, and dropouts
because it took me several months to figure out my problem with that.
Maybe it will help.
http://linux-audio.4202.n7.nabble.com/M-Audio-Fast-Track-Pro-unreliable-distorted-recording-td89125i20.html#a106829
Long story short: Try running with only one processor core active.
It completely cured my problem, and another user's as well.
In my case the device is a PCI M-Audio delta1010, and in the
other user's case it was a similar ice1712-based card.
However in the above Fast-Track-Pro case, that's USB and we
don't yet know if the trick solved that user's problem...
Be patient: If the number of CPU cores is the cause it may take
several minutes for the crackling to appear since I believe what
happens is that some low-level 'counters/pointers' which should
always be in sync slowly approach and 'pass' each other, and that's
when the noise occurs.
In my case the very same symptom occurred in Windows.
That proved beyond doubt that it was a hardware issue.
Hope that helps.
Tim.

While I, on the other hand, use all cores (real and hyperthread) on my i7 with no crackles or distorted recordings and such at all. Same for the 4 real cores on my AMD desktop system.
In my opinion, most PC motherboards weren't designed with any audio thought beyond including an on-board audio chip.
--
David W. Jones
authenticity, honesty, community
http://dancingtreefrog.com
Sent from my Android device with F/LOSS K-9 Mail.

Is this only Intel processors that are doing this? I've been running an AMD
Ryzen since March and had no problems at all.

[david]

Post by Will Godfrey
On Thu, 13 Sep 2018 15:48:11 -1000

Post by David W. Jones

Post by Niklas Reppel

Post by Niklas Reppel
Hi,
i recently updated my Arch linux system, to to the following
Linux 4.18.6-arch1-1-ARCH #1 SMP PREEMPT
Afterwards, i noticed that something has changed regarding the

realtime

Post by Niklas Reppel
permissions
and that i had to install a new package called

'realtime-priviliges',

Post by Niklas Reppel
which i never needed before,
and subsequently add my main user to the 'realtime' group.
In that wake, i updated the processor microcode, which i didn't use

at

Post by Niklas Reppel
all before (there always was some
error message during bootup, but nothing else).
After being able to start JACK in realtime again, i felt that there

was

Post by Niklas Reppel
a significant loss of performance.
Things that didn't cause any dropouts before now start to crackle

and

Post by Niklas Reppel
gristle (as a sidenote, i mostly
use SuperCollider to make sound).
Also, and this puzzled me especially, there were dropouts, but no

XRuns

Post by Niklas Reppel
... normally, when i push the
system to the limits, i get XRuns, that'd be expected. But now, it's
dropouts without, and they start way
earlier.

if

Post by Niklas Reppel
that info is of user for anyone ...
Anybody else noticed something like that recently ?
Best,
nik

Hello, I always reply when I hear of crackles, pops, and dropouts
because it took me several months to figure out my problem with that.
Maybe it will help.
http://linux-audio.4202.n7.nabble.com/M-Audio-Fast-Track-Pro-unreliable-distorted-recording-td89125i20.html#a106829
Long story short: Try running with only one processor core active.
It completely cured my problem, and another user's as well.
In my case the device is a PCI M-Audio delta1010, and in the
other user's case it was a similar ice1712-based card.
However in the above Fast-Track-Pro case, that's USB and we
don't yet know if the trick solved that user's problem...
Be patient: If the number of CPU cores is the cause it may take
several minutes for the crackling to appear since I believe what
happens is that some low-level 'counters/pointers' which should
always be in sync slowly approach and 'pass' each other, and that's
when the noise occurs.
In my case the very same symptom occurred in Windows.
That proved beyond doubt that it was a hardware issue.
Hope that helps.
Tim.

While I, on the other hand, use all cores (real and hyperthread) on my i7 with no crackles or distorted recordings and such at all. Same for the 4 real cores on my AMD desktop system.
In my opinion, most PC motherboards weren't designed with any audio thought beyond including an on-board audio chip.

Is this only Intel processors that are doing this? I've been running an AMD
Ryzen since March and had no problems at all.

You mean for the original poster, or me? I have no such problems on
either of my systems. But my AMD isn't a Ryzen, it's a Phenom II.

[Will Godfrey]

On Thu, 13 Sep 2018 20:49:31 -1000

Post by david

Post by Will Godfrey
On Thu, 13 Sep 2018 15:48:11 -1000

<snip>

Post by david

Post by Will Godfrey
Is this only Intel processors that are doing this? I've been running an AMD
Ryzen since March and had no problems at all.

You mean for the original poster, or me? I have no such problems on
either of my systems. But my AMD isn't a Ryzen, it's a Phenom II.

I was referring to the O/P

[David Runge]

Hi Niklas,

Post by Niklas Reppel
Hi,
Linux 4.18.6-arch1-1-ARCH #1 SMP PREEMPT
Afterwards, i noticed that something has changed regarding the realtime
permissions
and that i had to install a new package called 'realtime-priviliges', which
i never needed before,
and subsequently add my main user to the 'realtime' group.

Please subscribe to the arch-proaudio mailing list. The change was
announced there [1].

Post by Niklas Reppel
In that wake, i updated the processor microcode, which i didn't use at all
before (there always was some
error message during bootup, but nothing else).
After being able to start JACK in realtime again, i felt that there was a
significant loss of performance.
Things that didn't cause any dropouts before now start to crackle and
gristle (as a sidenote, i mostly
use SuperCollider to make sound).
Also, and this puzzled me especially, there were dropouts, but no XRuns ...
normally, when i push the
system to the limits, i get XRuns, that'd be expected. But now, it's
dropouts without, and they start way
earlier.
info is of user for anyone ...
Anybody else noticed something like that recently ?

It is very likely that the changes introduced to the Linux Kernel in
response to the spectre and meltdown security issues are causing this
in combination with (known to be) performance degrading Intel ucode.

However, I would not advice you to disable mitigations such as page
table isolation (PTI), unless you know about the implied risks!

Best,
David

[1] https://lists.archlinux.org/pipermail/arch-proaudio/2018-August/000191.html

[Ralf Mardorf]

Post by David Runge
However, I would not advice you to disable mitigations such as page
table isolation (PTI), unless you know about the implied risks!

Regarding Meltdown, loosely speaking, if the audio workstation is
connected to the Internet, we could boot without disabling PTI. If the
audio workstation is used for audio productions, we could boot with
disabling PTI and without connecting to the Internet. IIRC the
microcode for my CPU not only is required for Spectre mitigation, but
also to make TSC available and perhaps to fix other CPU issues, too, so
there might be no option to boot without the microcode at all.

The '/sys/devices/system/cpu/vulnerabilities/*' "list" is increasing ;).

[***@archlinux ~]$ uname -a
Linux archlinux 4.18.7-rt5-1-rt-securityink #1 SMP PREEMPT RT Thu Sep 13 08:01:15 CEST 2018 x86_64 GNU/Linux
[***@archlinux ~]$ dmesg | grep micro
[ 0.000000] microcode: microcode updated early to revision 0x25, date = 2018-04-02
[ 0.457030] microcode: sig=0x306c3, pf=0x2, revision=0x25
[ 0.457083] microcode: Microcode Update Driver: v2.2.
[***@archlinux ~]$ ls -l /sys/devices/system/cpu/vulnerabilities/*
-r--r--r-- 1 root root 4096 Sep 15 01:12 /sys/devices/system/cpu/vulnerabilities/l1tf
-r--r--r-- 1 root root 4096 Sep 15 01:12 /sys/devices/system/cpu/vulnerabilities/meltdown
-r--r--r-- 1 root root 4096 Sep 15 01:12 /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
-r--r--r-- 1 root root 4096 Sep 15 01:12 /sys/devices/system/cpu/vulnerabilities/spectre_v1
-r--r--r-- 1 root root 4096 Sep 15 01:12 /sys/devices/system/cpu/vulnerabilities/spectre_v2
[***@archlinux ~]$ cat /sys/devices/system/cpu/vulnerabilities/*
Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
Mitigation: PTI
Mitigation: Speculative Store Bypass disabled via prctl and seccomp
Mitigation: __user pointer sanitization
Mitigation: Full generic retpoline, IBPB, IBRS_FW

[Ralf Mardorf]

PS:

The microcode has not that much impact regarding Spectre mitigation, as I thought.

[***@archlinux ~]$ grep 'no micro' /boot/syslinux/syslinux.cfg -A4
MENU LABEL Arch Linux Rt Securityink no micro
LINUX ../vmlinuz-linux-rt-securityink
APPEND root=LABEL=s3.archlinux ro
INITRD ../initramfs-linux-rt-securityink.img

[***@archlinux ~]$ ls -l /sys/devices/system/cpu/vulnerabilities/*
-r--r--r-- 1 root root 4096 Sep 15 02:28 /sys/devices/system/cpu/vulnerabilities/l1tf
-r--r--r-- 1 root root 4096 Sep 15 02:28 /sys/devices/system/cpu/vulnerabilities/meltdown
-r--r--r-- 1 root root 4096 Sep 15 02:28 /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
-r--r--r-- 1 root root 4096 Sep 15 02:28 /sys/devices/system/cpu/vulnerabilities/spectre_v1
-r--r--r-- 1 root root 4096 Sep 15 02:28 /sys/devices/system/cpu/vulnerabilities/spectre_v2
[***@archlinux ~]$ cat /sys/devices/system/cpu/vulnerabilities/*
Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
Mitigation: PTI
Vulnerable
Mitigation: __user pointer sanitization
Mitigation: Full generic retpoline

##################################################################################################

[***@archlinux ~]$ grep 'Securityink nopt^i' /boot/syslinux/syslinux.cfg -A4
MENU LABEL Arch Linux Rt Securityink nopt^i
LINUX ../vmlinuz-linux-rt-securityink
APPEND root=LABEL=s3.archlinux ro nopti
INITRD ../intel-ucode.img,../initramfs-linux-rt-securityink.img

[***@archlinux ~]$ ls -l /sys/devices/system/cpu/vulnerabilities/*
-r--r--r-- 1 root root 4096 Sep 15 02:33 /sys/devices/system/cpu/vulnerabilities/l1tf
-r--r--r-- 1 root root 4096 Sep 15 02:33 /sys/devices/system/cpu/vulnerabilities/meltdown
-r--r--r-- 1 root root 4096 Sep 15 02:33 /sys/devices/system/cpu/vulnerabilities/spec_store_bypass
-r--r--r-- 1 root root 4096 Sep 15 02:33 /sys/devices/system/cpu/vulnerabilities/spectre_v1
-r--r--r-- 1 root root 4096 Sep 15 02:33 /sys/devices/system/cpu/vulnerabilities/spectre_v2
[***@archlinux ~]$ cat /sys/devices/system/cpu/vulnerabilities/*
Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT disabled
Vulnerable
Mitigation: Speculative Store Bypass disabled via prctl and seccomp
Mitigation: __user pointer sanitization
Mitigation: Full generic retpoline, IBPB, IBRS_FW