Very slow with Xubuntu 20.04

Forums / NoMachine for Linux / Very slow with Xubuntu 20.04

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #33069
    Avatarbobnx
    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
    Avatarbobnx
    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
    AvatarCarin
    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
    Avatarbobnx
    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
    Avatarbobnx
    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
    Avatarbobnx
    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
    Avatarbobnx
    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
    AvatarCarin
    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
    Avatarbobnx
    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
    Avatarfra81
    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.

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.