# Apps running on Xorg stutter or hiccup (but running glxgears stops it!)



## willbprog127 (Jan 13, 2021)

Greetings everyone!

Here's an interesting one...  When I run any apps on Xorg, at seemingly random times they stutter or 'hiccup'.  This is both with the graphic display and sound (Caja, terminal, Firefox, mpv, etc).  Here's the interesting part -- if I run `glxgears` in a tiny window in the corner of my display, the stuttering or hiccuping vanishes. __ _ ( glxgears does not appear to be in Packages, so I had to hunt it down and compile it after some updating to the older build settings.)._  I tried this `glxgears` test because I saw a similar hiccup issue when running OpenIndiana on another machine (with different graphics card) and `glxgears` stopped it there, too.

I did a non-scientific comparison, playing a YouTube video in Firefox with, and without, `glxgears` running.  Every time I played the video without `glxgears` running, the video would stutter or hiccup, but when `glxgears` was running, there were zero issues.

Does anyone have a clue what could be causing this?  It almost sounds like some sort of power-savings or CPU frequency stepping, but I haven't enabled any of that explicitly.

Thanks! 

Here's my info:
- - -
* FreeBSD 12.2-p1 amd64
* AMD Ryzen 5 3600 6-Core Processor
* NVIDIA GeForce 1650 Super
* All binary packages -- nothing from Ports
* Stock kernel

Here's my /boot/loader.conf:

```
kern.geom.label.disk_ident.enable="0"
kern.geom.label.gptid.enable="0"
opensolaris_load="YES"
zfs_load="YES"
nvidia-modeset_load="YES"
vboxdrv_load="YES"
```

Here's the contents of my /etc/rc.conf:

```
syslogd_flags="-ss"
sendmail_enable="NONE"
hostname="freebsd"
...
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="NO"
zfs_enable="YES"
vboxnet_enable="YES"
devfs_system_ruleset="system"
dbus_enable="YES"
```


----------



## ljboiler (Jan 13, 2021)

Try the mesa-demos package - glxgears is part of that, as well as a bunch of other OpenGL demo programs.


----------



## trev (Jan 13, 2021)

You didn't mention what WM you're using. Does the stutter occur with x11-wm/twm as the WM ?


----------



## willbprog127 (Jan 13, 2021)

trev said:


> You didn't mention what WM you're using. Does the stutter occur with x11-wm/twm as the WM ?


Shoot, I meant to include that.  I'm using Fluxbox, but it happens in other WMs too.


----------



## Snurg (Jan 13, 2021)

just curious: about:config -> layers.acceleration.force-enabled set to true?


----------



## willbprog127 (Jan 13, 2021)

Snurg said:


> just curious: about:config -> layers.acceleration.force-enabled set to true?


Hi Snurg,

This is on Firefox, but also mpv, Caja, terminal, etc.  Anything that has a UI is affected by this.  To answer your question, though, layers.acceleration.force-enabled is set to false on Firefox.

Thanks!


----------



## Snurg (Jan 14, 2021)

My personal observation is, enabling+activating acceleration seems also to activate some vsync synchronization/buffer switching, as I observed similar things in the past.
So running 'accelerated graphics' programs seems to affect some other programs too, like Firefox I have no idea why.

Did setting the config value to 'true' (i.e. activating acceleration) improve things?


----------



## kpedersen (Jan 14, 2021)

It could potentially be the CPU freq scaling that is being bumped up so there is less of a delay for other programs. I actually seem to experience similar.

`# powerd -v`

Should tell you your current frequency and my guess is that glxgears increases it considerably. This could be because it is using LLVMpipe (software rendering) or even the fact that glxgears is still very CPU bound because it uses immediate mode OpenGL rather than retaining the data in vertex buffer objects.


----------



## willbprog127 (Jan 14, 2021)

kpedersen said:


> It could potentially be the CPU freq scaling that is being bumped up so there is less of a delay for other programs. I actually seem to experience similar.
> 
> `# powerd -v`
> 
> Should tell you your current frequency and my guess is that glxgears increases it considerably. This could be because it is using LLVMpipe (software rendering) or even the fact that glxgears is still very CPU bound because it uses immediate mode OpenGL rather than retaining the data in vertex buffer objects.


Thanks for that!  I will play around with this and maybe bump it up to hiadaptive or max.


----------



## cjm (Apr 7, 2021)

You might also want to check the NVIDIA card's frequency scaling settings (e.g. in the control panel, section "PowerMizer"). I have the same issue and running glxgears might keep the graphics card busy enough to not go down the to minimum graphics clock and/or some sleep state. I haven't really investigated any further since it doesn't affect me too much, and this doesn't explaim why sound has hiccups, too (I'm having those both on the mainboard's HDA and on the graphics card's HDA which feeds audio to the monitor via display port).


----------



## laufdi (Jun 15, 2021)

I have the same problem, except that glxgears also stutters every second just as all other moving things like scrolling, videos etc. powerd indicates a higher cpu usage every second. How can I find out which process runs that shortly every second?


----------



## laufdi (Oct 30, 2021)

By chance I found that `devd` was the main problem (not the only one). Can I somehow make `devd` run smoother?


----------



## shkhln (Oct 30, 2021)

I don't know how you concluded that, but I'm horrified in advance.


----------



## laufdi (Oct 30, 2021)

In advance? I found out by killing devd and running it with -d. The output is in sync with stutters of everything else.


----------



## shkhln (Oct 30, 2021)

Are you in the video group?


----------



## laufdi (Oct 30, 2021)

yes ... why?


----------



## shkhln (Oct 30, 2021)

What's your CPU?


----------



## laufdi (Oct 30, 2021)

i5-8250U


----------



## shkhln (Oct 30, 2021)

What is that suspicious devd output?


----------



## laufdi (Oct 30, 2021)

every 1-2 seconds:

```
Processing event '!system=CAM subsystem=periph type=error device=da1 serial="000000001538" cam_status="0xcc" scsi_status=2 scsi_sense="70 02 3a 00" CDB="00 00 00 00 00 00 " '
Pushing table
setting *=!system=CAM subsystem=periph type=error device=da1 serial="000000001538" cam_status="0xcc" scsi_status=2 scsi_sense="70 02 3a 00" CDB="00 00 00 00 00 00 "
setting _=system=CAM subsystem=periph type=error device=da1 serial="000000001538" cam_status="0xcc" scsi_status=2 scsi_sense="70 02 3a 00" CDB="00 00 00 00 00 00 "
setting timestamp=1635568911.028973
setting system=CAM
setting subsystem=periph
setting type=error
setting device=da1
setting serial=000000001538
setting cam_status=0xcc
setting scsi_status=2
setting scsi_sense=70 02 3a 00
setting CDB=00 00 00 00 00 00
Processing notify event
Testing system=CAM against ^DEVFS$, invert=0
Testing system=CAM against ^DEVFS$, invert=0
Testing system=CAM against ^DEVFS$, invert=0
Testing system=CAM against ^DEVFS$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^USB$, invert=0
Testing system=CAM against ^DEVFS$, invert=0
Testing system=CAM against ^DEVFS$, invert=0
Testing system=CAM against ^ACPI$, invert=0
Testing system=CAM against ^ACPI$, invert=0
Testing system=CAM against ^ACPI$, invert=0
Testing system=CAM against ^ACPI$, invert=0
Testing system=CAM against ^ZFS$, invert=0
Testing system=CAM against ^ZFS$, invert=0
Testing system=CAM against ^ZFS$, invert=0
Testing system=CAM against ^ZFS$, invert=0
Testing system=CAM against ^ZFS$, invert=0
Testing system=CAM against ^ZFS$, invert=0
Testing system=CAM against ^ZFS$, invert=0
Testing system=CAM against ^ZFS$, invert=0
Testing system=CAM against ^ZFS$, invert=0
Testing system=CAM against ^ZFS$, invert=0
Testing system=CAM against ^ZFS$, invert=0
Testing system=CAM against ^ZFS$, invert=0
Testing system=CAM against ^DEVFS$, invert=0
Testing system=CAM against ^DEVFS$, invert=0
Testing system=CAM against ^HYPERV_NIC_VF$, invert=0
Testing system=CAM against ^ETHERNET$, invert=0
Testing system=CAM against ^IFNET$, invert=0
Testing system=CAM against ^IFNET$, invert=0
Testing system=CAM against ^IFNET$, invert=0
Testing system=CAM against ^ACPI$, invert=0
Testing system=CAM against ^ACPI$, invert=0
Testing system=CAM against ^ACPI$, invert=0
Testing system=CAM against ^ACPI$, invert=0
Testing system=CAM against ^ACPI$, invert=0
Testing system=CAM against ^ACPI$, invert=0
Testing subsystem=periph against ^DEVICE$, invert=0
Popping table
```


----------



## laufdi (Oct 30, 2021)

da1 problem? ... why do I have a da1 device which is nvd1?
which is WDC PC SN520 SDAPMUW-128G-1001

```
camcontrol devl -v
scbus0 on umass-sim0 bus 0:
<Generic MassStorageClass 1538>    at scbus0 target 0 lun 0 (da0,pass0)
<Generic MassStorageClass 1538>    at scbus0 target 0 lun 1 (da1,pass1)
```


----------



## shkhln (Oct 30, 2021)

Did you check swap usage?


----------



## laufdi (Oct 30, 2021)

swap is unused. Removing swap doesn't change anything.


----------



## shkhln (Oct 30, 2021)

Just to be sure, when devd doesn't run you get no stutter? Right?


----------



## laufdi (Oct 30, 2021)

yes
I guess I have to change that disk to see whether it's the problem


----------



## Alexander88207 (Oct 30, 2021)

laufdi said:


> I have the same problem, except that glxgears also stutters every second just as all other moving things like scrolling, videos etc. powerd indicates a higher cpu usage every second. How can I find out which process runs that shortly every second?



Is it possible that you are using xf86-video-intel?

On my small cheap laptop with a cherry lake it works with modesetting but if I use xf86-video-intel then everything is very slow and jerky.


----------



## laufdi (Oct 30, 2021)

Alexander88207 said:


> Is it possible that you are using xf86-video-intel?


yes


Alexander88207 said:


> On my small cheap laptop with a cherry lake it works with modesetting


There I found:
"Stutter free video playback is not possible on Gemini Lake (and likely also not on Skylake and others) in both Wayland and Xorg sessions with modesetting driver."








						Sway, Weston & Xorg modesetting - mistimed frames in mpv due to vsync jitter spikes with Intel GPU (#928) · Issues · xorg / xserver · GitLab
					

Originally reported here: https://github.com/mpv-player/mpv/issues/7106 Stutter free video playback is not possible on Gemini Lake (and likely also not on Skylake and...




					gitlab.freedesktop.org
				




I removed the (old?) xorg.conf and now at least the devd problem is gone!  (Please don't ask ;{ )
Only small secondly stutters are left when firefox is running  ...


----------



## laufdi (Oct 31, 2021)

laufdi said:


> I removed the (old?) xorg.conf and now at least the devd problem is gone!


no, it's not. It comes back after a while.
With modesetting btw. 3d graphics doesn't really work.


----------



## grahamperrin@ (Oct 31, 2021)

To the opening poster: 



willbprog127 said:


> … I will play around with this …



Did you reach a conclusion?


----------



## priyadarshan (Jun 3, 2022)

I was experiencing exactly the same issue, on an AMD Ryzen 9 5900HX cpu, Matisse GPU, "green_sardine" firmware,


```
pciconf -lv | grep -i vga
vgapci0@pci0:4:0:0:     class=0x030000 rev=0xc4 hdr=0x00 vendor=0x1002 device=0x1638 subvendor=0x1002 subdevice=0x0123
    subclass   = VGA
```

This fixed it:

`sysctl kern.sched.steal_thresh=1`

I found it on this mailing list message, as linked from this reddit comment.


----------



## willbprog127 (Jun 3, 2022)

Wow, lots of activity on this post.  I have not received notifications about most of it so just revisiting today.  priyadarshan Thanks for the tip!  I'm not using FreeBSD at the moment, but I'll definitely have to revisit your post if I do.

Thanks everyone!


----------



## laufdi (Jun 16, 2022)

priyadarshan said:


> `sysctl kern.sched.steal_thresh=1`
> 
> I found it on this mailing list message, as linked from this reddit comment.


Thanks a lot, but it doesn't help at all


----------



## T-Daemon (Jun 17, 2022)

priyadarshan said:


> `sysctl kern.sched.steal_thresh=1`





laufdi said:


> Thanks a lot, but it doesn't help at all



Try `kern.sched.steal_thresh=0` .









						microfreezes - FreeBSD 13
					

Hi!  FreeBSD 13.1 (13.0)  FreeBSD wcsn 13.1-RELEASE FreeBSD 13.1-RELEASE releng/13.1-n250148-fc952ac2212 GENERIC amd64 CPU: AMD Ryzen 5 3600 6-Core Processor               (3600.10-MHz K8-class CPU)  vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'  device     = 'Lexa PRO [Radeon...




					forums.freebsd.org


----------

