stdedos
commented
1 month ago ... or idk - maybe it was really a bad connection. But we are talking home network, Gigabit Eth over WiFi (@ ~135Mb/s)
Open stdedos opened 1 month ago
stdedos
commented
1 month ago ... or idk - maybe it was really a bad connection. But we are talking home network, Gigabit Eth over WiFi (@ ~135Mb/s)
stdedos
commented
1 month ago (also btw - graph window is not working)
totaam
commented
1 month ago Maximum latency at 22 seconds! 159 Megapixels/s Don't expect miracles!
stdedos
commented
1 month ago Idk - I don't want to say that xpra is lying, but ...
"How can I have latency 22 seconds?!?" I have a (home) shit LAN, but not 22s latency from a Gigabit ETH to 135 Mb/s WiFi
I have "just an HD monitor", so the math doesn't add up:
For an HD (High Definition) resolution, typically 1920x1080 pixels, we can calculate the required data transfer rates at different frame rates (25, 30, and 60 fps).
- Resolution: 1920 * 1080 = 2,073,600 pixels (approximately 2.07 Megapixels per frame)
Now, let's calculate the required Megapixels per second for each frame rate:
25 fps: ( 2.07 \, \text{Megapixels} \times 25 \, \text{fps} = 51.8 \, \text{Megapixels/s} )
30 fps: ( 2.07 \, \text{Megapixels} \times 30 \, \text{fps} = 62.1 \, \text{Megapixels/s} )
60 fps: ( 2.07 \, \text{Megapixels} \times 60 \, \text{fps} = 124.2 \, \text{Megapixels/s} )
Therefore, for screen mirroring an HD resolution (1920x1080):
- At 25 fps, you need 51.8 Megapixels/s.
- At 30 fps, you need 62.1 Megapixels/s.
- At 60 fps, you need 124.2 Megapixels/s.
Given these numbers, a transfer rate of 159 Megapixels/s is more than sufficient to handle HD screen mirroring at any of these frame rates, including the highest at 60 fps.
I am more than happy to take an FPS hit, and "color-quality" hit (but ofc no blur, since a lot is text 😕) - and I assume that the v5 video encoders can do something about it?
I think your stats are a bit misleading: If data arrives "all the time" e.g. here
2024-05-25 22:54:56,334 server is not responding, drawing spinners over the windows (xpra_cmd:54748): Pango-WARNING **: 22:55:04.863: couldn't load font "Gentium Book Basic Bold Italic Not-Rotated 57.331", falling back to "Sans Bold Italic Not-Rotated 57.331", expect ugly output. (xpra_cmd:54748): Pango-WARNING **: 22:55:04.875: couldn't load font "Gentium Book Basic Bold Italic Not-Rotated 57.096", falling back to "Sans Bold Italic Not-Rotated 57.096", expect ugly output. (xpra_cmd:54748): Pango-WARNING **: 22:55:05.134: couldn't load font "DejaVu Serif Not-Rotated 59.797", falling back to "Sans Not-Rotated 59.797", expect ugly output. (xpra_cmd:54748): Pango-WARNING **: 22:55:05.142: couldn't load font "URW Bookman L Not-Rotated 52.762", falling back to "Sans Not-Rotated 52.762", expect ugly output. 2024-05-25 22:55:05,186 server is OK again
but for some reason you don't update those stats in-between server is not responding / server is OK again - then yes, in ~10s the buffers maybe finally returned 159 MP/s.
But then I'd say you'd have to instead report 159 MP/s / 10s = 15.9 MP/s received
totaam
commented
1 month ago "How can I have latency 22 seconds?!?"
It's easy on wifi, you are experiencing bufferbloat. xpra is really not lying about this.
totaam
commented
1 month ago BTW, if you have latency / bufferbloat issues, you should definitely try connecting using QUIC rather than ssh.
stdedos
commented
1 month ago BTW, if you have latency / bufferbloat issues, you should definitely try connecting using QUIC rather than ssh.
idk, it doesn't look like it
Ofc it's not a nice result - but not 22 seconds delay ....
It seems that opening the Session Info window "causes more damage" than the connection itself
... also quic seems to not be an option?
Also, since I haven't played with certs, it'd be cool if it could be setup via ssh-auth (e.g. to send a random, client-generated certificate - and even on a random port).
I tried to see if GUI would make it easier, but it doesn't look like it
totaam
commented
1 month ago The problem is the wifi, always is.
It has its own buffer for re-transmits, and TCP head of line blocking can cause packet delays as big as what you are seeing.
It seems that opening the Session Info window "causes more damage" than the connection itself
Populating the info window makes requests and the responses are relatively big. This is a known limitation - see previous tickets on the subject. Normally not a big issue on a good connection.
As for aioquic, don't install it in a venv unless you also install xpra there (don't).
I guess we could add some sort of xpra gen-ssl command to generate self-signed certs - potentially remote ones too.
And maybe a xpra get-ssl command to just download a remote ssl cert.
stdedos
commented
1 month ago As for
aioquic, don't install it in a venv unless you also install xpra there (don't).
Yeah, ofc I wouldn't have wanted to do that. I just wanted to try it, and if it doesn't work simply rm -rf it.
However, I don't know which package would have it for xpra:
$ apt-cache madison xpr\t
xpra xpra-client xpra-codecs xpra-codecs-nvidia xpra-html5 xpra-x11 xprobe
xpra-audio xpra-client-gtk3 xpra-codecs-extras xpra-common xpra-server xprintidle None of them sounds "needed, but missing"
I guess we could add some sort of
xpra gen-sslcommand to generate self-signed certs - potentially remote ones too. And maybe axpra get-sslcommand to just download a remote ssl cert.
I mean, "eventually maybe" I should start my own CA, etc etc - but for a barebones way to bootstrap a quic session using some kind of auth would be nice. ssh keys give that flexibility. "Sort-of similar" to how e.g. https://mosh.org/ works
totaam
commented
1 month ago However, I don't know which package would have it for xpra:
Support for quic is included in all recent versions, you just need to install aioquic to get it. (pip install or whatever)
stdedos
commented
1 month ago Ah, okay - I see. I just thought that xpra would not pick up from the "currently active environment" (user or venv) - but simply its own (system or "something special" for python packages installed via apt-get/dpkg).
I started getting mindful of "polluting" my system/user catch-all pip installs and tried to move them e.g. in pipx.
Is there a "reasonably easy" way to convince xpra to "extend its path" to include a venv?
totaam
commented
1 month ago Is there a "reasonably easy" way to convince xpra to "extend its path" to include a venv?
This is not an xpra question, it's an OS / venv one.
python3 /usr/bin/xpra ... is your entry point.
stdedos
commented
2 weeks ago I managed to hack something together for Ubuntu, but still on Windows, I am getting:
(pyasn1)
I think that on Windows builds you cannot "add" anything, so is this an omission?
Ofc, this is a Light build - so maybe that's it?
stdedos
commented
2 weeks ago ... also on the normal ones
totaam
commented
2 weeks ago Probably caused by the "Light builds" packaging changes in #4100
Please try r35929 or later.
stdedos
commented
4 days ago
and
... idk what I'm doing wrong 😕
totaam
commented
3 days ago ... idk what I'm doing wrong
Not sure what the problem is here. What am I supposed to be seeing? The quic packaging problems are solved so are we back to the "server is not responding" issue?
stdedos
commented
3 days ago I am trying to mimic xpra shadow ssh://..., using quic (as per your suggestion)
Describe the bug A clear and concise description of what the bug is.
To Reproduce Steps to reproduce the behavior:
System Information (please complete the following information):
Additional context Add any other context about the problem here. Please see "reporting bugs" in the wiki section.