Using current CPU: AMD Ryzen 7 5800X 8-Core Processor (3800.07-MHz K8-class CPU) When running X on 13-STABLE, everything has a micro delay. When playing videos, the video keeps stuttering and audio periodically skips. Dragging things are not smooth, screen keeps stalling. An exact description of the problem was reported on the mailing list https://lists.freebsd.org/pipermail/freebsd-current/2021-March/079235.html Setting kern.sched.steal_thresh=0 made the problem go away completely. Anything higher than 0 produces noticeable stuttering and delays in visuals and audio.
^Triage: I am not really sure how to assign this. But in the mean time, give it a little fuller Summary, and put the "performance" Keyword on.
I can confirm this observation on a R9 3950X with 32GB, booted from an NVMe SSD and a RTX 3090 even such "simple" things as scrolling in Chromium result in painful stuttering and glaring tearing with i3 as window manager.
This was recently discussed on freebsd-current. CCing some of the folks from that thread. https://docs.freebsd.org/cgi/getmsg.cgi?fetch=65134+0+archive/2021/freebsd-current/20210328.freebsd-current
On my setup, also with a Zen 3 CPU, machdep.idle=mwait seems to improve the situation.
(In reply to Jack from comment #0) I still require the same workaround on my Ryzen 3950X system as well.
I reported what seems to be a similar bug on 12.2-STABLE https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=260898 Workaround: sysctl kern.eventtimer.timer=HPET sysctl machdep.idle=mwait (if necessary disable powerd also) If this works, it's probably the same bug
(In reply to Andriy Gapon from comment #4) can you also try kern.eventtimer.timer=HPET ? (this seems to make the most difference, especially if you have LAPIC assigned which I think is the default, and my guess is that it's pointing at the root cause of the problem if changing the event timer helps as much as I think it will)
I can confirm that switching to HPET from LAPIC improves the lagging but there's still some scrolling lagginess when I'm trying to drag the scrollbars in windows.
(In reply to Bob Frazier from comment #6) This workaround works great. Thank you.
When I boot into a FreeBSD install USB stick, I am seeing extreme lags in typing. If I hit one key, it will not show up until 2 or 3 seconds later. This makes the whole installation almost impossible when you need to select or enter parameters during the process. I'm not sure if this is related to the same issue. I am on the following specs: Ryzen 9 6900hs Nvidia RTX 3050 Lenovo Slim 7 Pro X
If you're still stuck try breakout out into the loader prompt by pressing escape during the 10 second countdown in the bootloader menu. On the loader prompt type: set kern.sched.steal_thresh=0 boot To persist this you can put this line into /boot/loader.conf to apply as early as possible: kern.sched.steal_thresh="0" To apply it slightly later you can add the same line to /etc/sysctl.conf as initially reported in this thread. The stutter wasn't bad enough during installation on my personal workstation which als moonlights as a gaming rig (AMD Ryzen 9 3950X, 32GB DDR4-3600 RAM, RTX 3090 GPU). It just felt slightly off at the vt(4) console. I couldn't place it at the time. With Xorg and the Nvidia driver loaded the system was still fast when compiling etc., but felt very sluggish and lots of tearing in i3. Supposedly smooth scrolling in browsers etc. was nothing of the sort. To get a pleasant desktop experience without tearing I also had to force the Nvidia driver to use a less efficient form of composition which increased idle power consumption by ~10W, because it keeps the GPU from staying in the lowest power state even when just editing source code in urxvt and gvim.
Actually, sorry, I just discovered this might be a different bug altogether for the following reasons: 1. I tried setting kern.sched.steal_thresh=0 as per crest@rlwinm.de directions. There is no effect. 2. I tried the install of Release 12.4 instead and there is no more lag. However, I believe this bug affects both 13 and release 12. I will need to investigate this issue through other channels instead to avoid hijacking the thread.