18:34 -!- tc424 [~steved@2001:470:1f1d:e3b::34] has joined #winswitch
18:34 -!- Topic for #winswitch: winswitch 0.12.23 | xpra 2.3.2 | please try updating to the newest version before reporting bugs
18:34 -!- Topic set by totaam [~antoine@users.devloop.org.uk] [Tue Jun 26 19:01:38 2018]
18:34 [Users #winswitch]
18:34 [@totaam    ] [ Benjojo ] [ davidl_   ] [ icasdri  ] [ qyliss     ] [ tc424    ]
18:34 [ [Neurotic]] [ bolt    ] [ docmax    ] [ idupree7 ] [ raso2      ] [ tribut   ]
18:34 [ `brain`   ] [ Boobuigi] [ ds_shadof ] [ izibi    ] [ rootman    ] [ tsto     ]
18:34 [ akaWolf   ] [ bug2000 ] [ early     ] [ jbrett   ] [ rudi_s     ] [ wodencafe]
18:34 [ Akronym   ] [ CcxWrk  ] [ elibrokeit] [ kugel    ] [ shadoxx    ] [ yomii    ]
18:34 [ amir      ] [ Chaz6   ] [ EliDupree ] [ luke-jr  ] [ smo        ]
18:34 [ aterius   ] [ copec   ] [ femme     ] [ mtgx`    ] [ Some_Person]
18:34 [ atrus     ] [ darvon  ] [ grazzolini] [ ohama    ] [ stux       ]
18:34 [ Avengence ] [ davidl  ] [ hosenknopf] [ pfallenop] [ tbr        ]
18:34 -!- Irssi: #winswitch: Total of 50 nicks [1 ops, 0 halfops, 0 voices, 49 normal]
18:34 -!- Channel #winswitch created Wed Nov  2 07:11:40 2011
18:34 -!- Irssi: Join to #winswitch was synced in 1 secs
18:36 < tc424> hi all, new to xpra, have installed latest version on server (ubuntu 16.04) and client (18.04), but a bit surprised at the latency versus direct X forwarding, given this is 1Gb/s connection
18:37 < tc424> forcing rgb/png helps a bit, but not as much as I'd hoped, and I don't know why it's not picked automatically given link speed. anything obvious I may have overlooked?
18:39 <@totaam> tc424: set --speed=100 instead
18:39 <@totaam> or force just rgb
18:39 <@totaam> there should be zero latency on a gigabit link
18:40 <@totaam> except for link latency itself, obviously
18:41 < tc424> ah, will try that, thanks - was a bit shocked when moving from flaky wifi to ethernet didn't seem to help!
18:43 <@totaam> wifi is usually terrible, but better in 2.4
18:43 <@totaam> latency jitter is hard to deal with
18:43 <@totaam> on ethernet gigabit, you can forward 4k windows as long as they don't update too quickly
18:43 <@totaam> for 4k video, you need hardware encoding
18:44 < tc424> ok, got --speed=100, was briefly ok when I first connected, now seem frame delay around ~250ms!
18:44 < tc424> something is obviously really wrong :(
18:44 <@totaam> that's definitely not right
18:45 <@totaam> tc424: see http://xpra.org/trac/wiki/ReportingBugs
18:46 <@totaam> those are the kinds of details we need to investigate anything
18:46 < tc424> thanks, it could be something local, my machines tend to end up a bit hacked up, but the client machine at least should be pretty clean
18:46 < tc424> it's basically an Intel SoC box being used as an X terminal
18:47 <@totaam> SoC - as in low power?
18:48 < tc424> yeah, fairly
18:48 < tc424> but fully accelerated gfx
18:48 < tc424> seeing may 10-20% cpu utilization
18:49 < tc424> straight X using XDMCP is fine, pretty much indistinguishable from the "server" console
18:50 <@totaam> tc424: make sure opengl rendering is enabled
18:50 < tc424> I /think/ it is
18:50 <@totaam> it should say in the client output
18:50 < tc424> 2018-07-07 18:42:28,299 OpenGL enabled with Mesa DRI Intel(R) HD Graphics 500 (Broxton 2x6)
18:50 < tc424> 2018-07-07 18:42:27,684 No OpenGL_accelerate module loaded: No module named OpenGL_accelerate
18:50 < tc424> 2018-07-07 18:42:28,241 Warning: vendor 'Intel Open Source Technology Center' is greylisted,
18:50 <@totaam> OK, then it is
18:50 <@totaam> I'm out of ideas
18:51 <@totaam> 250ms is way too much
18:51 < tc424> now at 875ms!
18:51 < tc424> the batch delay keeps climbing
18:51 <@totaam> please file a ticket
18:51 <@totaam> with at least "xpra info"
18:52 < tc424> OK, will do, is there a way to monitor  batch delay computations in real time as they happen?
18:52 <@totaam> "-d stats" will show more details
18:52 <@totaam> (server side)
18:52 <@totaam> it's not very readable
18:52 <@totaam> coule be bandwidth limits triggering it
18:53 <@totaam> try adding --bandwidth-limit=0
18:53 < tc424> will do, it's not set according to the GUI, but just in case...
18:57 -!- docmax1 [~docmax@x4e3376e8.dyn.telefonica.de] has joined #winswitch
19:00 -!- docmax [~docmax@x55b26367.dyn.telefonica.de] has quit [Ping timeout: 256 seconds]
19:00 -!- docmax1 is now known as docmax
19:05 < tc424> OK I see the same thing just running the client + server on the same machine ..
19:06 < tc424> network 1-3ms, damage ~90ms, batch ~110ms
19:25 <@totaam> tc424: running on the same machine should use mmap, which means all delays should be near zero there
20:54 -!- Boobuigi [~weechat@unaffiliated/boobuigi] has quit [Ping timeout: 240 seconds]
21:31 -!- Boobuigi [~weechat@unaffiliated/boobuigi] has joined #winswitch
21:33 < tc424> totaam: yeah, that's what I thought :(
21:51 < tc424> totaam: will open proper ticket tomorrow hopefully when brain is less broiled, but in the meantime https://pastebin.com/nuZjFBH0 shows the escalating batch delay
21:53 < tc424> 2018-07-07 21:38:29,099 record_latency: took 2098.1 ms round trip, 2098.1 for echo,  285.0 for decoding of      273 pixels,     1145 bytes sent over the network in 1813.0 ms, 1813.0 ms for echo
21:53 < tc424> ..that doesn't look healthy..
22:11 -!- davidl_ [~usrname@fsf/member/usrname] has quit [Ping timeout: 265 seconds]