Low performance (fps) in perfect conditions

[ValdikSS]

There were several issues regarding xrdp performance (#1600, #386), but none of the recommendations and workarounds helped me. I'm testing xrdp in a perfect network conditions and can't get good performance.

• Xrdp session seems to be capped to 25 FPS, thus feels sluggish.
• Xvnc session provides 60 fps, but it is unstable, it has a frame drops (lags) every several seconds. This is especially visible when dragging windows. Also, Xvnc session has tearing.

Server configuration: Debian 11 with xrdp 0.9.15-1 (xorgxrdp 0.2.15-1) in a VM, openbox session. Client 1 configuration: Fedora 34 over virtual VM network (~localhost) with freerdp 2.3.2 (manually recompiled with h264 support) Client 2 configuration: Windows 10 with Wi-Fi connection

xrdp in xorgxrdp mode, freerdp as a client

Graphics output is capped to 25 fps. For some reason, it also introduces significant load to server's CPU (60-120%), even if just dragging window.
Enabling /gfx:avc420 reduces CPU load a bit but does not help fps.

https://user-images.githubusercontent.com/3054729/131251096-5cf3b880-fd42-47f1-8c84-2ca30288b0d3.mp4

xrdp in xvnc mode, tigervnc as a server, freerdp as a client

Noticeable tearing, especially in doom. Strange lags when dragging windows.

https://user-images.githubusercontent.com/3054729/131251176-46ec3810-e5a6-4958-a151-f92e2c3c4ebe.mp4

tigervnc

Steady 60 fps (this video is not very smooth due to screen recording), no lags, very light CPU load (10-20%).

https://user-images.githubusercontent.com/3054729/131251219-914d9438-d4aa-4c12-89d3-97f61f47365b.mp4

How to achieve better results with xorgxrdp in terms of fps? Is it possible to eliminate tearing with xvnc? Is it possible to reduce CPU load?

I've tried to change many options is xrdp.ini, neither helped the performance.

[metalefty]

Thanks for the detailed report. It helps a lot.

Client 1 configuration: Fedora 34 over virtual VM network (~localhost) with freerdp 2.3.2 (manually recompiled with h264 support) Enabling /gfx:avc420 reduces CPU load a bit but does not help fps.

BTW, xrdp doesn't support h264 yet. Same with GFX. RFX is the best codec supported by xrdp so far. So, enabling H264/GFX takes no effect.

[jsorg71]

HI @ValdikSS ,

For the improvements you need GFX I think. We have some GFX branches where h264 is working but not main xrdp develop branch yet. I think when you used /gfx:avc420, it was falling back to RLE compression which might reduce cpu. The 25 fps is a define in xorgxrdp. Frames have 40ms between them. Planning to move this to an environment variable in the future.

[mailinglists35]

The 25 fps is a define in xorgxrdp

is this in the context you were responding (GFX) or it does apply generally?

what can happen if we recompile after changing the hardcoded value from 40ms to 10ms? can we do this safely, is the program behaviour the same or something else will be affected?

what was the original reason for this value, was it chosen high enough to prevent high cpu usage?

[Seas0]

I tried to modify the hard-coded limitation a bit. Not sure if it would eventually work.

Anyway, here is the patch file for xorgxrdp:

diff --git a/module/rdpClientCon.c b/module/rdpClientCon.c
index e4e0317..4273a00 100644
--- a/module/rdpClientCon.c
+++ b/module/rdpClientCon.c
@@ -2603,8 +2603,8 @@ rdpDeferredUpdateCallback(OsTimerPtr timer, CARD32 now, pointer arg)
 
 
 /******************************************************************************/
-#define MIN_MS_BETWEEN_FRAMES 40
-#define MIN_MS_TO_WAIT_FOR_MORE_UPDATES 4
+#define MIN_MS_BETWEEN_FRAMES 16
+#define MIN_MS_TO_WAIT_FOR_MORE_UPDATES 1
 #define UPDATE_RETRY_TIMEOUT 200 // After this number of retries, give up and perform the capture anyway. This prevents an infinite loop.
 static void
 rdpScheduleDeferredUpdate(rdpClientCon *clientCon)

At least it didn't crash on my computer... But do watch out for CPU utilization, as xrdp's codec seems only rely on single core, forcing it run on 60fps would be a "little" too tense for some weaker processors

[issuefiler]

@Seas0 I've patched it and it still couldn't reach 60 FPS. testufo.com showed that the frame rate was 60 FPS, YouTube webpages got 60 FPS data, but on my Windows RDP client, it never looked like 60 FPS.

[Seas0]

@Seas0 I've patched it and it still couldn't reach 60 FPS. testufo.com showed that the frame rate was 60 FPS, YouTube webpages got 60 FPS data, but on my Windows RDP client, it never looked like 60 FPS.

There is definitely some issues like VSync and/or fresh blocking lurking around, but unfortunately I am NOT familiar enough with Linux/X11 graphic stack, so I can't pinpoint the problem right now, especially without any Log/extra info.

With this patch applied on my settings I suspect the real FPS is around 40~50 on my iPad with occasional frame-dropping.

Also notice that your connection quality shall contribute to actual performance.

[issuefiler]

It was performant enough (using GPU-accelerated xrdp) to render 60 FPS and they were in a local network under the same home router. It might be a limitation imposed by the protocol (RDP) itself.. Not sure though.

I've found this MSDN documentation:

Note

Additionally, not all remote display protocols support a frame rate that is greater than 30 FPS. For example, Remote Desktop Protocol (RDP) limits the frame rate to 30 FPS.

[Seas0]

It was performant enough (using GPU-accelerated xrdp) to render 60 FPS and they were in a local network under the same home router. It might be a limitation imposed by the protocol (RDP) itself.. Not sure though.

I've found this MSDN documentation:

Note

Additionally, not all remote display protocols support a frame rate that is greater than 30 FPS. For example, Remote Desktop Protocol (RDP) limits the frame rate to 30 FPS.

Hmm, seems a possible reason. Would investigate if I can spare some time.

[Seas0]

It was performant enough (using GPU-accelerated xrdp) to render 60 FPS and they were in a local network under the same home router. It might be a limitation imposed by the protocol (RDP) itself.. Not sure though.

I've found this MSDN documentation:

Note

Additionally, not all remote display protocols support a frame rate that is greater than 30 FPS. For example, Remote Desktop Protocol (RDP) limits the frame rate to 30 FPS.

Also could you try to lower the color depth to 16 or 15 bits?

[issuefiler]

When I tried max_bpp=15 and Color depth: 15 bit., it didn’t even show me the login screen. xrdp errored and refused the connection.

$ sudo systemctl status xrdp
* xrdp.service - xrdp daemon
     Loaded: loaded (/lib/systemd/system/xrdp.service; enabled; preset: enabled)
     Active: active (running) since Fri 2023-03-10 10:48:33 GMT; 39s ago
       Docs: man:xrdp(8)
             man:xrdp.ini(5)
    Process: 167712 ExecStart=/usr/local/sbin/xrdp $XRDP_OPTIONS (code=exited, status=0/SUCCESS)
   Main PID: 167713 (xrdp)
      Tasks: 1 (limit: 9183)
     Memory: 1.9M
        CPU: 821ms
     CGroup: /system.slice/xrdp.service
             `-167713 /usr/local/sbin/xrdp

Mar 10 10:49:07 myusername xrdp[167756]: [INFO ] xrdp_mm_egfx_send_planar_bitmap: xrdp_egfx_send_wire_to_surface1 error
Mar 10 10:49:07 myusername xrdp[167756]: [ERROR] xrdp_iso_send: trans_write_copy_s failed
Mar 10 10:49:07 myusername xrdp[167756]: [ERROR] xrdp_mcs_send: xrdp_iso_send failed
Mar 10 10:49:07 myusername xrdp[167756]: [ERROR] xrdp_sec_send: xrdp_mcs_send failed
Mar 10 10:49:07 myusername xrdp[167756]: [ERROR] xrdp_channel_send: xrdp_sec_send failed
Mar 10 10:49:07 myusername xrdp[167756]: [ERROR] xrdp_channel_drdynvc_data: xrdp_channel_send failed
Mar 10 10:49:07 myusername xrdp[167756]: [INFO ] xrdp_mm_egfx_send_planar_bitmap: xrdp_egfx_send_frame_end error
Mar 10 10:49:07 myusername xrdp[167756]: [ERROR] xrdp_iso_send: trans_write_copy_s failed
Mar 10 10:49:07 myusername xrdp[167756]: [ERROR] Sending [ITU T.125] DisconnectProviderUltimatum failed
Mar 10 10:49:07 myusername xrdp[167756]: [ERROR] Attempting to send data to a channel that is not open. channel id 1, channel status unknown

max_bpp=32 in /etc/xrdp/xrdp.ini (the server) and Color depth: 32 bit. in Windows Remote desktop connection (the client), which is the initial configuration, was the only one that worked for me.