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:

Code:

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:

Code:

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:

Code:

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

Code:

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