Very slow with Xubuntu 20.04

[bobnx]

Server – Desktop running Xubuntu 20.04 with NoMachine 7.4.1

Client – Connecting from Laptop running Xubuntu 20.04 with NoMachine 7.4.1

Screen on client (Laptop) very slow to refresh.  If for example you open a terminal window and type “a”, it does not appear (but does appear on Desktop screen). Then type “s” and “as” appears on client screen.  Input ‘seems’ to go to the server correctly and fast.  It is the response back to the client that is slow.

Same laptop can connect to another Desktop running Xubuntu 18.04 and all works well.

The Xubuntu 20.04 Desktop did work fine (using 18.04) until upgrade to 20.04.

[bobnx]

Additional info – right click on desktop brings up the desktop menu on the server but menu does not appear on client until mouse is moved.

[Carin]

Hi bobnx,

we were not able to reproduce this problem on an updated Xubuntu.
Can you verify your network connection? Is it wifi? When you are able to reproduce the issue, can you please also verify CPU and ram usage on the server-side?

[bobnx]

1gb LAN connection.
Both Desktops same LAN.
Both 8gb memory
Usable desktop Intel(R) Core(TM)2 Duo CPU     E8500  @ 3.16GHz
Unusable desktop Intel(R) Core(TM)2 Quad CPU    Q9400  @ 2.66GHz

One difference is slow desktop has:
VGA compatible controller: NVIDIA Corporation G86 [GeForce 8500 GT] (rev a1

Fast desktop has:
Intel Corporation 4 Series Chipset Integrated Graphics Controller (rev 03)

I have tried with both the NVIDIA driver and native Linux driver with no difference.

[bobnx]

Perhaps a clue or maybe a red herring –

Both desktops have 2 network cards.  The second cards in each desktop are connected via a crossover cable.  However (in theory) all network traffic should go via the first network cards.  Only DRBD traffic goes over the crossover.

I use the term “desktops” liberally.  I really think of them as servers but with a GUI.  That is they use Xubuntu desktop software and have physical displays attached.  Each “server” runs a number of KVM virtual machines.

Bad server :

br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 192.168.0.200  netmask 255.255.255.0  broadcast 192.168.0.255
inet6 fe80::30da:806f:e448:d89b  prefixlen 64  scopeid 0x20<link>
ether 00:1d:7d:d5:1d:03  txqueuelen 1000  (Ethernet)
RX packets 103571  bytes 72608255 (72.6 MB)
RX errors 0  dropped 14268  overruns 0  frame 0
TX packets 85227  bytes 20241875 (20.2 MB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 10.0.0.200  netmask 255.255.255.254  broadcast 10.0.0.255
inet6 fe80::1ad6:c7ff:fe06:b0a6  prefixlen 64  scopeid 0x20<link>
ether 18:d6:c7:06:b0:a6  txqueuelen 1000  (Ethernet)
RX packets 6692  bytes 547764 (547.7 KB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 6750  bytes 414873 (414.8 KB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp5s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
ether 00:1d:7d:d5:1d:03  txqueuelen 1000  (Ethernet)
RX packets 121528  bytes 77840793 (77.8 MB)
RX errors 0  dropped 476  overruns 0  frame 0
TX packets 92360  bytes 20614249 (20.6 MB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10<host>
loop  txqueuelen 1000  (Local Loopback)
RX packets 1930  bytes 143736 (143.7 KB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 1930  bytes 143736 (143.7 KB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
inet 192.168.100.1  netmask 255.255.255.0  broadcast 192.168.100.255
ether 52:54:00:5f:52:d0  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Good Server :

br1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 192.168.0.201  netmask 255.255.255.0  broadcast 192.168.0.255
inet6 fe80::6ef0:49ff:fe14:81c3  prefixlen 64  scopeid 0x20<link>
ether 6c:f0:49:14:81:c3  txqueuelen 1000  (Ethernet)
RX packets 726796  bytes 257686600 (257.6 MB)
RX errors 0  dropped 193314  overruns 0  frame 0
TX packets 655460  bytes 139205557 (139.2 MB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp1s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet 10.0.0.201  netmask 255.255.255.0  broadcast 10.0.0.255
inet6 fe80::1ad6:c7ff:fe06:b0d6  prefixlen 64  scopeid 0x20<link>
ether 18:d6:c7:06:b0:d6  txqueuelen 1000  (Ethernet)
RX packets 4611352  bytes 6260495476 (6.2 GB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 2044631  bytes 187886200 (187.8 MB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
ether 6c:f0:49:14:81:c3  txqueuelen 1000  (Ethernet)
RX packets 13344889  bytes 17710341246 (17.7 GB)
RX errors 0  dropped 6409  overruns 0  frame 0
TX packets 2581827  bytes 341784717 (341.7 MB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
inet 127.0.0.1  netmask 255.0.0.0
inet6 ::1  prefixlen 128  scopeid 0x10<host>
loop  txqueuelen 1000  (Local Loopback)
RX packets 15789  bytes 1183514 (1.1 MB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 15789  bytes 1183514 (1.1 MB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
inet 192.168.123.1  netmask 255.255.255.0  broadcast 192.168.123.255
inet6 fe80::c024:d7ff:fe3e:30b9  prefixlen 64  scopeid 0x20<link>
ether c2:24:d7:3e:30:b9  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 9  bytes 642 (642.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

virbr1: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
inet 192.168.100.1  netmask 255.255.255.0  broadcast 192.168.100.255
ether 52:54:00:c7:7c:fe  txqueuelen 1000  (Ethernet)
RX packets 0  bytes 0 (0.0 B)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 0  bytes 0 (0.0 B)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vnet0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet6 fe80::fc54:ff:febf:aa61  prefixlen 64  scopeid 0x20<link>
ether fe:54:00:bf:aa:61  txqueuelen 1000  (Ethernet)
RX packets 1751478  bytes 185570661 (185.5 MB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 11585242  bytes 17530475362 (17.5 GB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vnet1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
inet6 fe80::fc54:ff:fed3:86ec  prefixlen 64  scopeid 0x20<link>
ether fe:54:00:d3:86:ec  txqueuelen 1000  (Ethernet)
RX packets 219007  bytes 340890947 (340.8 MB)
RX errors 0  dropped 0  overruns 0  frame 0
TX packets 680119  bytes 180866367 (180.8 MB)
TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[bobnx]

Another clue!

There is a KVM Xubuntu 20/04 virtual machine running under the “slow NX” machine.

So effectively both the main server and the virtual machine are both Xubuntu 20.04 (with latest updates) and NX 7.4.1

Server is slow.

Virtual machine is perfect.

A bit of info – server was an upgrade from 18.04 (also had NX server).  Virtual machine was a fresh install.

 

[bobnx]

Another clue –

If I run glxgears on the client and then open a terminal, the performance is fine i.e. if I type “a”, it appears straight away.

[Carin]

Hi bobnx,

Could you please test the point 2. described in this article https://knowledgebase.nomachine.com/AR03P00973 ?
This way NoMachine will not attach to a physical display, but to a virtual one created by NoMachine.

[bobnx]

Yes, using:

sudo systemctl stop lightdm
sudo /etc/NX/nxserver --restart

Then when I connect, the client screen is very responsive.

I hope that this is helpful to you?

 

[fra81]

Hi,

so this seems to be a problem with the specific combination of graphics card and drivers. Even if sending data to the GPU for rendering can be fast, in some exceptional cases pulling data back from the GPU for screen capture can be much slower. When you stop lightdm, NoMachine creates a virtual framebuffer which is independent from the actual graphics card and drivers. Unfortunately that issue can’t be solved in NoMachine, but you may check for a different version of video drivers. For example, you may try to install proprietary Nvidia drivers or, in case you did already, install the open source ones.

[commandline]

Hi,

Similar issue with Ubuntu 20.04.

What is apparent is nxclient.bin keeps consuming 100% CPU

Running ldd /usr/NX/bin/nxclient.bin shows quite a bit of missing libraries.

ldd /usr/NX/bin/nxclient.bin
linux-vdso.so.1 (0x00007ffd18395000)
libqt.so => not found
libnxdixl.so => not found
libnxdiex.so => not found
libnxdift.so => not found
libnxdifb.so => not found
libnxup.so => not found
libnxd.so => not found
libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f6b660e2000)
libnxn.so => not found
libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f6b660dd000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6b660d7000)
libnxcau.so => not found
libnxs.so => not found
libsync.so => not found
libnxcsl.so => not found
libnxc.so => not found
libnx.so => not found
libz.so => /lib/x86_64-linux-gnu/libz.so (0x00007f6b660b9000)
libpng.so => /lib/x86_64-linux-gnu/libpng.so (0x00007f6b6607f000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f6b6605c000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6b65f0d000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6b65ef2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6b65d00000)
/lib64/ld-linux-x86-64.so.2 (0x00007f6b662e7000)

[bobnx]

In answer to post of May 5, 2021, as mentioned in post of 26th April, I have tried both the Nvidia and the Open Source drivers with no change in behavior.

Hopefully, Potex are still investigating this problem?

FYI using VNC works without problems (except of course the general VNC problems). But would much prefer to use NX.

[Carin]

@commandline The client with high CPU load issue will be handled in the topic here https://forums.nomachine.com/topic/nxclient-bin-high-cpu-load-100-ubuntu-20-04-lts

@bobnx  What do you mean with “Potex are still investigating this problem” ?

[shelter]

The missing libs are because NoMachine runs in it own “chroot” or something. Nothing to worry about.

The libs are under /usr/NX/lib/

[bobnx]

Hi @commandline, sorry about Potex reference.  A bit of a senior moment I am afraid.  I have an issue on the ZK forum and was on there just before I posted here.  ZK is something from Potrex.  My brain got confused as to who owns/develops NX. (:-)

What I was really trying to say is – I hope NoMachine/NX are still looking at the problem.  It is annoying that stock Xubuntu does not work and I have to kill Lightdm.  Some of the comments seem to imply it is a Xubuntu/Lightdm problem and we have to live with it.

I don’t think is acceptable to blame xubuntu/lightdm – NX always worked previously and VNC works.

[Author]

Posts