Very slow with Xubuntu 20.04

Forum / NoMachine for Linux / Very slow with Xubuntu 20.04

Viewing 15 posts - 1 through 15 (of 20 total)
  • Author
    Posts
  • #33069
    bobnx
    Participant

    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.

    #33073
    bobnx
    Participant

    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.

    #33077
    Carin
    Participant

    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?

    #33080
    bobnx
    Participant

    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.

    #33087
    bobnx
    Participant

    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

    #33119
    bobnx
    Participant

    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.

     

    #33131
    bobnx
    Participant

    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.

    #33147
    Carin
    Participant

    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.

    #33148
    bobnx
    Participant

    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?

     

    #33258
    fra81
    Moderator

    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.

    #33269
    commandline
    Participant

    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)

    #33276
    bobnx
    Participant

    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.

    #33288
    Carin
    Participant

    @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” ?

    #33279
    shelter
    Participant

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

    The libs are under /usr/NX/lib/

    #33297
    bobnx
    Participant

    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.

Viewing 15 posts - 1 through 15 (of 20 total)

This topic was marked as solved, you can't post.