J1900 eglfs vs Xorg/glamor

Title: Qt eglfs vs Xorg/glamor on Intel J1900 — 1 kHz EtherCAT jitter (not LinuxCNC, GPU/X data point)

Not a LinuxCNC install. Posting because this forum already tracks iGPU/X vs servo-thread latency, and we have before/after numbers on one box.

Hardware: Intel Celeron J1900 (Bay Trail HD 8086:0f31), Debian 13 PREEMPT_RT 6.12, IgH EtherCAT master, 1 kHz, two axes. HMI is a fullscreen Qt Quick app on the same machine. Isolated CPU3 for the RT loop.

Same load, same kernel.

Xorg + glamor + x11vnc:
- P99 |jitter| about 52 us (after removing a measurement bias)
- worst -171 / +58 us
- many outliers; 60-90 points >=80 us per 5 s capture

Qt eglfs / eglfs_kms (no LightDM, no X, no VNC), QT_QPA_EGLFS_NO_LIBINPUT=1:
- P99 |jitter| 14 us
- worst -38 / +45 us
- 0 points >=50 us in ~35k cycles

A separate bug was measuring jitter mid-axis instead of wake-to-wake; that only moved the mean onto 0 us. The spike cleanup is the display path: X/glamor/x11vnc fighting i915 while the RT thread is on the sibling core.

We are not recommending this on Elkhart Lake (J6412/J6413). There, glamor already gave 100-300 us spikes; eglfs would own the GPU even harder.

Happy to hear if anyone running a Qt or other GL HMI beside a 1 ms servo thread has compared eglfs/KMS to a compositing X session.

The Baytrail J1800-J1900's are a mess. Maybe its been fixed, but incorrect power management caused them to report they were overheating and shut down, I had a couple that went in the bin.

Is simply improving heat dissipation enough, or are there other solutions? The N100 is too expensive.

tietouwa wrote:

Is simply improving heat dissipation enough, or are there other solutions? The N100 is too expensive.

No it was a fault in the kernel. There is nothing wrong with a J1900, I used one for years, its just the baytrail chipset.