The xfwm compositor absolutely doesn't work with the nvidia proprietary driver and though you already said you disabled it, your experience sounds like the typical issue when it's still enabled. So better check again that it's disabled or even change the WM.
A test for xfwm compositing still being enabled is playing a video with mpv, that will stutter, crash and burn.

denyasisThis might sound dumb, but since it works on an alternate OS, it might be worth a look:

Is this commuter "gaming only"or do you do other things with it? Perhaps you have program or deamon running in the background that is using a bunch of resources.

All the possible applications: multimedia station, photography post-processing, SSH server, office suite, accessing my Company WTS, etc.

denyasisOnly other thing that comes to mind are the CPU mitigations that have been coming through the kernel over the past year. Presumably, steamos might have them off to squeeze more performance out of the system?

It could be. I'm considering also this for the comparison.

gurvI'm glad to see you have at least found a way to game with a good framerate.
Good luck taming that monster cpu ^_^:)

lol, thank you. I definitely need it.

gurvEdit:
Oh just thought about something: you could get a pretty heavy framerate penalty if NVidia's driver thread is not on the same ccx. I think I've seen that happen when fiddling on my Ryzen.
So you may have to try all the ccx pinning possibilities:
taskset -c 8-11,40-43 %command%
taskset -c 12-15,44-47 %command%
(you should fix the ram slots assignment before trying the next two as currently numa node #0 doesn't have direct access to memory)
taskset -c 0-3,32-35 %command%
taskset -c 4-7,36-39 %command%

I will try the possible combinations as soon as I get back from my business trip. So far the one giving me the best throughput has been the selection of cores 8-15.

Cheers,
Dave

gurvI've had another idea though I doubt it's the problem since you're using Ubuntu 19.04 which should have systemd 240.

From the esync wiki (https://github.com/lutris/lutris/wiki/How-to:-Esync):
"run ulimit -Hn to see open files limit (it should report 524288)."

In my case the command above shows 1M instead of 512k.

GnomerickThe xfwm compositor absolutely doesn't work with the nvidia proprietary driver and though you already said you disabled it, your experience sounds like the typical issue when it's still enabled. So better check again that it's disabled or even change the WM.
A test for xfwm compositing still being enabled is playing a video with mpv, that will stutter, crash and burn.

Another test I could try would be to install and run a different DE (such as Mate or Gnome) on the same system. Thank you for the observation.

Cheers,
Dave

Thank you for your support on this thread.

After the news of the recent controversies between Valve and Canonical, and because a different distribution such as SteamOS actually gave the expected performance, I would probably spend the day testing and getting along with a new distribution which will replace my Ubuntu 1904.

I'll update the thread with the test results.

Cheers,
Dave

Thanks to all the people who contributed to this post.

After trying several solutions, I have been distro-hopping for the last week, in a way to check if it might be an issue with the software architecture. The only ones where the actual performances were exactly as desired have been the following:

• SteamOS


• Debian Stretch 9.9

Manjaro (which has quite a number of followers in the Linux Gaming Communities) gave me exactly the same performance as Ubuntu, and I ditched it immediately I found Debian was the best solution for the mentioned HW. Contextually, I'm not experiencing anymore any stuttering issue when moving the mouse in either the Debian or SteamOS environment.

The reason is still not 100% clear for me, though. The fact that Debian comes shipped with a Kernel which can better support my CPU (and provide a better scheduling for it) might be a hypothesis.

Please let me know if I can provide any other clarification for the matter. In the meantime, I'll put this thread as Solved, and of course try to gitgud, as I have no frame rate excuses now :)

All the best,
Dave

If you're going to use Debian, you may want to consider going to testing or sid for more recent drivers and libraries.

chris.echozIf you're going to use Debian, you may want to consider going to testing or sid for more recent drivers and libraries.

I might, but I'd rather stay on the Stable branch for a while, trying not to defy the first principle of IT (If something works, don't touch it). :D

Seriously, I'd probably prefer to keep the software environment on the stable branch, and check out any newer release of some specific software from the original source or repository, if and when required: for instance, I downloaded and compiled the GPU driver on the last release from the Nvidia .run archive. Other software such as Wine comes already with its own repository, then no need for moving from the Stable branch for now.

LordDaveTheKind

chris.echozIf you're going to use Debian, you may want to consider going to testing or sid for more recent drivers and libraries.

I might, but I'd rather stay on the Stable branch for a while, trying not to defy the first principle of IT (If something works, don't touch it). :D

Seriously, I'd probably prefer to keep the software environment on the stable branch, and check out any newer release of some specific software from the original source or repository, if and when required: for instance, I downloaded and compiled the GPU driver on the last release from the Nvidia .run archive. Other software such as Wine comes already with its own repository, then no need for moving from the Stable branch for now.

Stable works really well if you don't need the newest of some software (a lot you can still get by installing manually/building), and you're playing native games. I used it for years and have only now switched to Sid to try to keep up with everything that's happening in the realm of Vulkan, DXVK, Proton and such.