Xpra: Ticket #1855: Continuous Spamming of Network Quality Issues

Windows 10 (1803/17134.48) (connecting wirelessly @ 240 Mbit/s) connecting to Ubuntu 16.04.3 (Ethernet, 1 Gbit/s)

Xpra gtk2 client version 2.3-r19246 64-bit
 running on Microsoft Windows 10
GStreamer version 1.14.0 for Python 2.7.15 64-bit
 desktop size is 1600x900 with 1 screen:
  2\WinSta-Default (423x238 mm - DPI: 96x96) workarea: 1600x860
    DISPLAY1 (310x174 mm - DPI: 131x131)
 downscaled by 75%, virtual screen size: 2133x1200
  2\WinSta-Default (423x238 mm - DPI: 128x128) workarea: 2133x1147
    DISPLAY1 (310x174 mm - DPI: 174x175)
 keyboard settings: layout=us
enabled remote logging
Xpra shadow server version 2.3-r19255 64-bit
 running on Linux Ubuntu 16.04 xenial
setting scaling to 67%:
sending updated screen size to server: 2402x1351 with 1 screens
  2\WinSta-Default (423x238 mm - DPI: 144x144) workarea: 2402x1291
    DISPLAY1 (310x174 mm - DPI: 196x197)

After some time, I keep getting "Network Performance Issue", "Your connection is struggling to keep up".

It doesn't matter if I press "Lower bandwidth limit" or "Cancel". I've tried both, it keeps coming up. I've tried to change the settings to the tray icon (Speed / Quality), but nothing happens. However, I feel that it's possible that tray icon is not listening to me i.e. it does not apply my options.

Trying to WinSCP a 1GB file I get a speed ~7 - 22 MB/s, so, I wouldn't say that actual network speed is problematic



Mon, 28 May 2018 12:34:56 GMT - stdedos: attachment set


Mon, 28 May 2018 13:02:14 GMT - stdedos: component changed


Mon, 28 May 2018 15:17:35 GMT - Antoine Martin: owner, description changed

I guess we haven't tested this well enough with problematic connections like wifi. Can you post the "-d bandwidth" server log?

Clicking the "Ignore" button should prevent any further warnings. (the "-d bandwidth" logs should show it, maybe add "-d notification")

Trying to WinSCP a 1GB file I get a speed ~7 - 22 MB/s, so, I wouldn't say that actual network speed is problematic

That's the maximum bandwidth your connection is capable of. But wifi has a lot of jitter, and xpra is very sensitive to that.


Mon, 28 May 2018 15:25:51 GMT - Antoine Martin: milestone set


Tue, 29 May 2018 15:08:10 GMT - Antoine Martin:

Another workaround is to start your server with:

XPRA_ACK_TOLERANCE=1000 xpra start ...

I have also created a ticket to improve this and detect jittery connections: #1860


Wed, 30 May 2018 04:06:19 GMT - Jordan: attachment set

log of bandwidth notification spamming


Wed, 30 May 2018 04:08:03 GMT - Jordan:

I captured a log of this issue. I started xpra with the following parameters:

--debug bandwidth,notifications --encoding=png --dpi=96 --speaker=off --pulseaudio=no \
    --resize-display=no --printing=no --file-transfer=no --notifications=no --webcam=no :991

But I don't think it actually logged notification debug messages.

I connected at 21:27:48 and opened glxgears. I ran that for a while and it didn't trigger. I then opened firefox and started a youtube video. I saw the bandwidth notification show up at about 21:32:29, 21:33:37, and 21:34:51. Each time I clicked on 'ignore'.

This test is run over wifi -> internet -> remote xpra server. The internet connection is about 30 mbps.


Wed, 30 May 2018 04:35:25 GMT - Antoine Martin: owner, status changed

FWIW:

PNG is a CPU pig and not particularly efficient at compressing either.


As for the log itself:

(probably caused by wifi packet loss)

I have no idea why the notifications keep showing up, but now at least I should be able to reproduce it by artificially triggering the same events.


Thu, 31 May 2018 14:45:41 GMT - Antoine Martin: owner, status changed

Turns out that this is trivial to test with this server env var:

XPRA_ACK_TOLERANCE=-500 xpra start --start=xterm

Will use a negative value for the ack tolerance, which triggers the warnings every time. With this in place, I got the warnings on the win32 client, but clicking "Ignore" silenced all warnings for all windows until the session ended.

@stdedos: if you can still reproduce, please post the "-d bandwidth,notify" debug log.


Thu, 31 May 2018 15:14:44 GMT - stdedos:

I can still replicate (see attachments)


Thu, 31 May 2018 15:33:51 GMT - stdedos: attachment set


Thu, 31 May 2018 15:34:49 GMT - stdedos:

Hopefully now it comes okay. ...However, I noticed I had the original files stored.

So, you have 2 log traces! :-D

(on the second one, I also added -d bandwidth,notify on the client)


Thu, 31 May 2018 15:36:37 GMT - stdedos:

server trace always leads with:

2018-05-31 18:22:22,393 Warning: the python netifaces package is missing
2018-05-31 18:22:22,503 init bandwidth_limit=None
2018-05-31 18:22:22,506 bandwidth-limit setting=None, socket-speed=None
2018-05-31 18:22:22,506 bandwidth-limit capability=0
shadow session now available on display :0

(however, not on the /run file I assume)


Thu, 31 May 2018 16:51:24 GMT - Antoine Martin:

I only just noticed that you're using a shadow server. The fix is in r19547 + r19549. beta packages with these fixes will land here: https://xpra.org/beta.


Mon, 04 Jun 2018 11:20:37 GMT - stdedos:

Replying to Antoine Martin:

I only just noticed that you're using a shadow server. The fix is in r19547 + r19549. beta packages with these fixes will land here: https://xpra.org/beta.

Note: xpra_2.4-20180531r19548-1_amd64.deb is there; however, missing the r19549


Mon, 04 Jun 2018 13:05:21 GMT - Antoine Martin:

however, missing the r19549

Sorry forgot to push some newer builds, try now.


Fri, 08 Jun 2018 09:55:11 GMT - stdedos:

I have follow-up on that. Now passing notifications works.

However, pushing "limit bandwidth" does really kill the connection (see attachments).

Should we continue here or at #1860?


Fri, 08 Jun 2018 09:56:38 GMT - stdedos: attachment set


Sat, 09 Jun 2018 03:16:52 GMT - Antoine Martin:

However, pushing "limit bandwidth" does really kill the connection (see attachments).

Nothing suspicious there, but there have been fixes to bandwidth handling lately. Please try the latest beta builds, both client and server side.

Should we continue here or at #1860?

The only think to verify there is documented in ticket:1860#comment:4. Do you see the correct value on your setup?


Sat, 09 Jun 2018 09:00:12 GMT - stdedos:

Replying to Antoine Martin:

Should we continue here or at #1860?

The only think to verify there is documented in ticket:1860#comment:4. Do you see the correct value on your setup?

Unfortunately, that will have to wait until Monday :/


One last thing, I always wanted to ask: Are all these errors "known/safe to ignore" etc etc?

* Error: avcodec error -1094995529 decoding [...]
* Error: decode failed on  [...]
* unknown string message: 0xc08fL  [...]
* C:/Program Files/Xpra/library.zip/xpra/gtk_common/gtk_util.py:658: GtkWarning: gdk_property_delete: assertion 'window != NULL' failed
* Error collecting system bug report data using [...]

Sat, 09 Jun 2018 09:18:19 GMT - Antoine Martin:

Error: avcodec error -1094995529 decoding [...] Error: decode failed on [...]

Fixed: #1868

unknown string message: 0xc08fL

Safe to ignore.

GtkWarning: gdk_property_delete: assertion 'window != NULL' failed

Safe to ignore.

Error collecting system bug report data using [...]

No idea: what is [...] ?


Sat, 09 Jun 2018 09:22:26 GMT - stdedos:

Replying to Antoine Martin:

Error collecting system bug report data using [...]

No idea: what is [...] ?

I didn't want to pollute comments - so I truncated the error(s). On the end of 1855-follow-up.7z​ > 1855-follow-up_terminal.txt:

2018-06-08 12:51:26,707 Error collecting system bug report data using <function get_sys_info at 0x00000000233675f0>
Traceback (most recent call last):
  File "./xpra/client/gtk_base/bug_report.py", line 281, in get_text_data
  File "./xpra/client/gtk_base/bug_report.py", line 137, in get_sys_info
  File "./xpra/scripts/config.py", line 385, in read_xpra_defaults
  File "./xpra/os_util.py", line 439, in osexpand
TypeError: object of type 'NoneType' has no len()

Sat, 09 Jun 2018 12:07:37 GMT - Antoine Martin:

Error collecting system bug report data using <function get_sys_info at 0x00000000233675f0>

I can't reproduce it, but in any case it should be fixed in r19594.


Sat, 09 Jun 2018 13:53:50 GMT - stdedos:

Replying to Antoine Martin:

Error collecting system bug report data using <function get_sys_info at 0x00000000233675f0>

I can't reproduce it, but in any case it should be fixed in r19594.

I guess it's complicated, since user is in AD


Sun, 10 Jun 2018 07:02:55 GMT - Antoine Martin: status changed; resolution set

I believe this bug is fixed, let's follow up in ticket:1860#comment:4.


Sat, 23 Jan 2021 05:35:34 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1855