Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 25 Mar 2021 03:04:54 -0700
From:      Alastair Hogge <agh@riseup.net>
To:        myfreeweb <greg@unrelenting.technology>
Cc:        freebsd-current@freebsd.org, Michael Gmelin <freebsd@grem.de>, monochrome <monochrome@twcny.rr.com>
Subject:   Re: freebsd 13 ryzen micro stutter
Message-ID:  <677da81d7af9781be6b46c7cba4efd05@riseup.net>
In-Reply-To: <ED533759-D326-45D5-8AE2-51CB10763A1E@unrelenting.technology>
References:  <d793c8b7-e0e2-e0d9-3ecd-923134d15bf3@twcny.rr.com> <20210323101146.18c9a969@bsd64.grem.de> <ED533759-D326-45D5-8AE2-51CB10763A1E@unrelenting.technology>

next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-03-23 17:34, myfreeweb wrote:
> On March 23, 2021 9:11:46 AM UTC, Michael Gmelin <freebsd@grem.de> wrote:
>>
>>
>>On Mon, 22 Mar 2021 23:50:52 -0400
>>monochrome <monochrome@twcny.rr.com> wrote:
>>
>>> After about 8 months of struggling to narrow this down I did another
>>> search and saw this:
>>>
>>> https://www.reddit.com/r/freebsd/comments/lc8fwo/freebsd_13_vega_64_micro_stutter_in_x/
>>>
>>> I haven't seen this come up here so I thought I would bring it up.
>>>
>>> My story started sometime before around August last year when synergy
>>> started getting really annoying with stuttering. Pretty sure it
>>> wasn't like that when I first started tracking 13-current in around
>>> May 2020 (I was on 12 with scfb for a long time before that with no
>>> issues), but since then I have tried to eliminate as many variables
>>> as possible. First I switched to barrier instead of synergy. Shortly
>>> after that I realized it was happening all the time and not just a
>>> network problem, I started using foobillard to verify during tests. I
>>> tried different RAM combinations, different network cards, a variety
>>> of RAM timings, stripping rc.conf etc, powerd settings, also scfb,
>>> with no effect. It is observable with ping -f, a dot or two appears
>>> every time it glitches. It seemed much better with RC2, but now with
>>> RC3 it seems to be back with a vengeance, and since its my main
>>> workstation and barrier/synergy server host for several machines, it
>>> is unbearable to use. Both Win10 and devuan3 on the same machine are
>>> smooth with no issues. Any feedback or info would be appreciated.
>>>
>>> Hardware:
>>> ASRock B450M Pro4
>>> Ryzen 2400G, no OC
>>> 32M DDR4-2933
>>> Onboard Vega GPU, drm-fbsd13-kmod
>>> _______________________________________________
>>
>>Without knowing much about the issue at hand, just a few ideas:
>>
>>Sysctls I would look at:
>>- raising *.cx_lowest
>>- different kern.eventtimer.timer
> 
> None of these should be an issue, but:
> 
> sysctl kern.sched.steal_thresh=1
> 
> For some reason with the default value of 2, I'm seeing weird
> stuttering in youtube videos, games, etc. on a 5950X system. 1 (or 0,
> IIRC) works fine.

I have noticed this too, firefox exhibits the issue frequently, however
I have
found it most noticeable in games/dhewm3[0] or Yamagi Quake 2[1]. There
is a distinct pause every 3 or 4 seconds where the simulation advances
significantly. Thanks for the kern.sched.steal_thresh pointer that has
sorted
the issue out for now.

$ dmesg | egrep '(CPU:|avail memory)'
CPU: AMD Ryzen 9 3950X 16-Core Processor             (3500.02-MHz
K8-class CPU)
avail memory = 66779394048 (63685 MB)
With an AMD NAVI 8GiB GPU, the host should be able to play either game
well enuf,
Quake 2 came out in 1997 and Doom 3 2004. I am sure Quake 2 used to play
without issues on my old AMD bulldozer.


0: https://www.freshports.org/games/dhewm3/
1: https://github.com/yquake2/yquake2



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?677da81d7af9781be6b46c7cba4efd05>