3

We're dealing with three linux systems:

  • a "server" (actually a workstation that is also used as desktop PC) running ubuntu 18.04.

  • an old client (laptop with sandy-bridge cpu, no dedicated GPU) running arch linux

  • a new client (laptop with comet lake cpu, dedicated Nvidia GPU, hybrid setting in the bios, no bumblebee installation) running debian testing and using the proprietary nvidia drivers from the debian repositories

the two clients are in the same network (adjacent ports on the switch, same IP range, both gigabit ethernet adapters, speedtest.net reports the same connection speed for both).

I can ssh onto the server from both clients and X forwarding generally works except much slower on the new client (as test cycle i start the intel vtune gui and close it once the main menu is completely drawn. that takes ~ 26s on the new client and ~5s on the old client).

With ssh -vvv I don't see any difference between the two setups (both aes128-gcm@openssh.com as cipher, neither use connection compression. in fact the $HOME/.ssh/config files and /etc/ssh/ssh_config files are the same (the latter shipped slightly differently but I copied the file from the old client to the new to rule out that that's where the difference comes from).

Obviously we would like to get x forwarding on the new client to get as fast as it is on the old client. suggestion where to look for differences? can the X configurations / graphics drivers on the clients cause the slowdown (we don't see general graphic issues on any of the three systems)?

update

Both systems run the same window manager (i3). enabling/disabling compression doesn't change the behaviour.

A bit by accident (though triggered by the suggestion of @symcbean) I noticed on the new client that the behaviour changes dramatically when switching network device on the new client: connecting through the USB-C to ethernet that came with it, I observe the slow behaviour. Connecting through wifi I get down to ~9s for the start-and-quit cycle mentioned above. (the old client uses the builtin ethernet adapter).

Digging further, while speedtest.net says both clients get 800Mbit/s (ethernet on both clients), a scp from the server to the clients gets 90MB/s to the old client, but only 5 MB/s to the new client with ethernet (50MB/s with wifi).

update 2

in ip addr I see the qdisc setting differs between the clients:

  • new client ethernet <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
  • old client ethernet <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
  • new client wifi <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000

iperf3 (to a public iperf server)

old client

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  92.7 MBytes   777 Mbits/sec    0   1.54 MBytes       
[  5]   1.00-2.00   sec  73.8 MBytes   619 Mbits/sec    0   1.54 MBytes       
[  5]   2.00-3.00   sec  71.2 MBytes   598 Mbits/sec    0   1.54 MBytes       
[  5]   3.00-4.00   sec  76.2 MBytes   640 Mbits/sec    0   1.54 MBytes       
[  5]   4.00-5.00   sec  97.5 MBytes   818 Mbits/sec    2   1.14 MBytes       
[  5]   5.00-6.00   sec  95.0 MBytes   797 Mbits/sec    0   1.27 MBytes       
[  5]   6.00-7.00   sec  93.8 MBytes   786 Mbits/sec    0   1.34 MBytes       
[  5]   7.00-8.00   sec  93.8 MBytes   786 Mbits/sec    0   1.44 MBytes       
[  5]   8.00-9.00   sec  95.0 MBytes   797 Mbits/sec    0   1.48 MBytes       
[  5]   9.00-10.00  sec  86.2 MBytes   724 Mbits/sec    0   1.48 MBytes  

new client (ethernet)

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  30.0 MBytes   252 Mbits/sec   49    382 KBytes       
[  5]   1.00-2.00   sec  35.9 MBytes   301 Mbits/sec    0    447 KBytes       
[  5]   2.00-3.00   sec  41.5 MBytes   348 Mbits/sec    0    515 KBytes       
[  5]   3.00-4.00   sec  47.6 MBytes   399 Mbits/sec    0    580 KBytes       
[  5]   4.00-5.00   sec  53.6 MBytes   450 Mbits/sec    0    648 KBytes       
[  5]   5.00-6.00   sec  58.2 MBytes   489 Mbits/sec    0    714 KBytes       
[  5]   6.00-7.00   sec  66.2 MBytes   555 Mbits/sec    0    781 KBytes       
[  5]   7.00-8.00   sec  52.5 MBytes   440 Mbits/sec   10    625 KBytes       
[  5]   8.00-9.00   sec  57.5 MBytes   482 Mbits/sec    0    690 KBytes       
[  5]   9.00-10.00  sec  61.2 MBytes   513 Mbits/sec    0    740 KBytes       
8
  • Does enabling compression on the ssh connection (ssh -C or ssh -o Compression=yes) make any difference on the new client? Also, are there significant differences in the desktop environments used on the old/new clients? Could it be that the window manager on the new client is more heavyweight?
    – zackse
    Jan 15, 2021 at 1:04
  • both use i3 as window manager. enabling/disabling compression doesn't lead to a perceivable change.
    – pseyfert
    Jan 15, 2021 at 12:47
  • 1
    Given the difference between the LAN and WLAN connection I would concentrate the efforts at improving the LAN connection. Is there a possible mismatch in the ethernet configuration between the new client and the switch? (ethtool or mii-tool could shed a light on this) Jan 15, 2021 at 15:44
  • Could you check if both of them are using X11? Maybe new one uses wayland? You can check it with ` echo $XDG_SESSION_TYPE` Jan 18, 2021 at 13:48
  • @AlexBaranowski both X11
    – pseyfert
    Jan 18, 2021 at 13:50

1 Answer 1

-1

I've not used vtune / don't know what it does - do you perceive that the older device is more responsive?

X is rather chatty. The first place I would be looking is at the network stack - not the video card. Try running iperf3 / check for differences on the collision algo / TCP offloading (this can increase latency while reducing CPU load). Make sure you've got irqbalance running on the new box.

2
  • i don't think it's relevant what vtune does exactly. it's just a bit on the heavy side for X forwarding - with display or xeyes I don't notice slowness. Triggered by your suggestion (see updates) I have to admit that I ruled bandwidth issues out too quickly: the new client does not manage to use the internet connection. (didn't run iperf3 yet between server and clients because i'm fighting with the gateway).
    – pseyfert
    Jan 15, 2021 at 13:17
  • This looks like much more of a comment than an answer. Jan 21, 2021 at 12:56

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.