xpra icon
Bug tracker and wiki

Opened 10 days ago

Last modified 23 minutes ago

#2029 new defect

xpra shadow dying due to lack of bandwidth

Reported by: stdedos Owned by: stdedos
Priority: minor Milestone: 2.5
Component: server Version: 2.4.x
Keywords: Cc:

Description

Is it possible somehow to get statistics on how much bandwidth a xpra shadow would require?

I am trying to do a shadow over the internet (both ends on Ethernet); however, I am given a bunch of:

2018-11-05 21:12:56,142 client @16.500 server is not responding, drawing spinners over the windows
2018-11-05 21:12:59,770 client @20.125 server is OK again
2018-11-05 21:13:01,108 client @21.467 server is not responding, drawing spinners over the windows
2018-11-05 21:13:02,960 client @23.295 server is OK again
2018-11-05 21:13:06,143 client @26.500 server is not responding, drawing spinners over the windows
2018-11-05 21:13:08,247 client @28.608 server is OK again
2018-11-05 21:13:10,812 Warning: delayed region timeout
2018-11-05 21:13:10,812  region is 15 seconds old, will retry - bad connection?
2018-11-05 21:13:10,813  2 late responses:
2018-11-05 21:13:10,813      14 png  :  16s
2018-11-05 21:13:10,813      15 png  :  15s
2018-11-05 21:13:11,153 client @31.515 server is not responding, drawing spinners over the windows
2018-11-05 21:13:14,025 client @34.390 server is OK again
2018-11-05 21:13:14,583 Warning: delayed region timeout
2018-11-05 21:13:14,584  region is 15 seconds old, will retry - bad connection?
2018-11-05 21:13:14,584  5 late responses:
2018-11-05 21:13:14,584      12 png  :  20s
2018-11-05 21:13:14,584      13 png  :  19s
2018-11-05 21:13:14,585      14 png  :  18s
2018-11-05 21:13:14,585      15 png  :  17s
2018-11-05 21:13:14,585      16 h264 :  15s
2018-11-05 21:13:15,136 Warning: delayed region timeout
2018-11-05 21:13:15,137  region is 15 seconds old, will retry - bad connection?
2018-11-05 21:13:15,137  4 late responses:
2018-11-05 21:13:15,137      12 h264 :  20s
2018-11-05 21:13:15,137      13 h264 :  19s
2018-11-05 21:13:15,138      14 png  :  17s
2018-11-05 21:13:15,138      15 png  :  15s
2018-11-05 21:13:16,185 client @36.545 server is not responding, drawing spinners over the windows
2018-11-05 21:13:16,693 client @37.045 server is OK again
2018-11-05 21:13:21,187 client @41.545 server is not responding, drawing spinners over the windows
2018-11-05 21:13:22,221 client @42.577 server is OK again
2018-11-05 21:13:30,172 client @50.515 server is not responding, drawing spinners over the windows
2018-11-05 21:13:30,458 client @50.811 server is OK again
2018-11-05 21:13:34,376 Warning: sanitizing invalid gtk selection
2018-11-05 21:13:34,376  format=0x340957e8, type=0x2abaae0, length=-0x1
2018-11-05 21:13:35,183 client @55.545 server is not responding, drawing spinners over the windows
2018-11-05 21:13:37,291 client @57.640 server is OK again
2018-11-05 21:13:40,203 client @00.561 server is not responding, drawing spinners over the windows
2018-11-05 21:13:42,778 client @03.140 server is OK again
2018-11-05 21:15:05,525 client @25.875 server is not responding, drawing spinners over the windows
2018-11-05 21:15:05,781 client @26.140 server is OK again

At some time, I wondered if available bandwidth would be an issue.
I turned the quality to the lowest possible setting (favoring bandwidth), and it seemed to be working.
Also, speedometer showed from a "constant" peak of ~1.1 mb/s, to drop to 380 kb/s - 640 kb/s.
I believe that my connection's peak is also ~1.3 mb/s, which could explain the timeouts (10 Mbits)

  • Is it possible to have some estimation on how much bandwidth a shadow session would require?
  • .. or have any kind of "real-time" plottable statistics?

My server's setup is 3 screens (1680x1050+0+30, 1920x1080+3600+0, 1920x1080+1680+0)
I have a 10/10 Mbits connection on the client, assume inf/inf at server
Server's altered settings are only to disable sound/mic/webcam (otherwise all are at default)
Client has disabled OpenGL (for no reason, I just don't like the warning), sound/mic/webcam, and scaled desktop (because 1600x1050 is non-standard for me, and 1920x1080 is already the host screen)

  • Is there any setting that would help me work under the bandwidth limitation?

Lowest quality is not really nice if I have to discern anything smaller than 320x240 pixels

Attachments (1)

trac-2029.zip (527.1 KB) - added by stdedos 16 hours ago.

Download all attachments as: .zip

Change History (4)

comment:1 Changed 9 days ago by Antoine Martin

Owner: changed from Antoine Martin to stdedos

Is it possible to have some estimation on how much bandwidth a shadow session would require?

No, that depends entirely on what is happening in the session and how well the encoders deals with it.

.. or have any kind of "real-time" plottable statistics?

The session info window should have some, including a plot which you can save.

Client has disabled OpenGL (for no reason, I just don't like the warning

Which warning?

Is there any setting that would help me work under the bandwidth limitation?

From a local terminal, try this command to start the shadow server:

XPRA_SHADOW_REFRESH_DELAY=250 xpra shadow ...

This will limit the framerate to 4fps (default is 50ms which gives 20fps).
If that helps, please post the -d encoding,bandwidth server debug log and we should be able to make the shadow framerate automatically adapt to the bandwidth conditions.

comment:2 in reply to:  1 Changed 16 hours ago by stdedos

Replying to Antoine Martin:

.. or have any kind of "real-time" plottable statistics?

The session info window should have some, including a plot which you can save.

I tried to take some. with-delay_no-quality_timeout was taken about at the end. "At" the end, red line spiked to 2M, and then died in ~5 seconds.
Otherwise, all "traffic" (both timed out and not) looked the same. Maybe I should've tested the bandwidth from the server side, like I did last time?

Client has disabled OpenGL (for no reason, I just don't like the warning

Which warning?

Warning: vendor 'Intel' is greylisted,
 you may want to turn off OpenGL if you encounter bugs

Since I don't know "what bugs to expect", I just disable it altogether

Is there any setting that would help me work under the bandwidth limitation?

From a local terminal, try this command to start the shadow server:

XPRA_SHADOW_REFRESH_DELAY=250 xpra shadow ...

This will limit the framerate to 4fps (default is 50ms which gives 20fps).
If that helps, please post the -d encoding,bandwidth server debug log and we should be able to make the shadow framerate automatically adapt to the bandwidth conditions.

It seems to me that XPRA_SHADOW_REFRESH_DELAY does not change the result.
All the servers were started with

(XPRA_SHADOW_REFRESH_DELAY=250) xpra shadow -d encoding,bandwidth :0

and attached with

"C:\Program Files\Xpra\xpra_cmd" attach ssh://sntentos@172.16.57.121/0 --desktop-scaling=0.75 --opengl=no (--quality=10)

--quality=10 was much more of a definite factor to get it working, rather than anything else.
Both adding XPRA_SHADOW_REFRESH_DELAY and trying to set the quality/bandwidth from the tray icon looked like no-ops.

Changed 16 hours ago by stdedos

Attachment: trac-2029.zip added

comment:3 Changed 23 minutes ago by Antoine Martin

From the log samples:

  • nonvideo(100, framerate lowered): we should probably stick with video encoders for shadow windows, you can try r21002 or later (server side update).
  • your OS doesn't have webp support.. so we end up using png, which uses tons of CPU and bandwidth - upgrading to Ubuntu 18.04 or later would help with that, that explains why lowering the quality helps so much: you end up using jpeg instead, which uses a fraction of the bandwidth
  • despite noticing that there is a backlog: send_delayed for wid 1, delaying again because of backlog: 5 packets, batch delay is 497, elapsed time is 2541ms, the automatic quality and speed heuristics keep the values way too high:
    update_encoding_options(False) wid=1, want_alpha=False, speed=99, quality=99, \
        bandwidth-limit=0, lossless threshold: 59 / 5, rgb auto threshold=32768 (min=2048, max=32768), \
        get_best_encoding=<bound method WindowVideoSource.get_best_encoding_video...
    

This looks like a bug.
Can you post the server's -d encoding,bandwidth,stats output please?

Note: See TracTickets for help on using tickets.