Forum / NoMachine for Linux / Input latency
- This topic has 7 replies, 2 voices, and was last updated 5 years, 10 months ago by fra81.
-
AuthorPosts
-
February 1, 2019 at 09:43 #21240DrPepperParticipant
I’m running NoMachine on Arch Linux and I noticed that there is a significant delay in input. Regardless of bandwidth, I can see lag of about 100 ms or more when I use the client mouse, as well as when I use my Steam Controller via USB forwarding. I tested it on a 100 Mbps ethernet connection with every combination of performance and quality settings I could think of. It can handle the maximum quality setting just fine, so I don’t get it. Why would it lag, and what can I do about it?
February 1, 2019 at 10:50 #21246fra81ModeratorHi!
I start to say that this is strange. Given that server and client should settle, more or less, for a frame rate of 30 fps by default, added lag should be no more than 1000/30, that is 33 ms.
Please check the Display settings panel in the session menu. What value frame rate is set to?
And can you describe exactly how you are measuring such input lag? What procedure, what measurement method?That said, are you connecting to the physical display of the server? Is it a headless machine? I would also check cpu usage on both client and server side.
February 1, 2019 at 19:39 #21255DrPepperParticipantThe frame rate is not set to anything in particular. The option “Request a specific frame rate” is unchecked.
I actually don’t have a way to measure the lag. I was just guessing, so maybe my estimate was meaningless. However, the lag is definitely noticeable. If I try to play Minecraft, there is enough of a delay when looking or jumping to make it not worth play using NoMachine. Also, if I enable “Show remote cursor pointer”, I can see the cursor trailing if I move it even a little bit.
I am connecting to the “physical” display of the server. It is headless, but I’m using an HDMI dummy plug.
The CPU usage on the client and the host look good. They are well below 100%.
I forgot to include information about the software I’m using, so I’ll do so now.
- NoMachine free version 6.4.6 on both the local and remote machine
- Problem arises connecting to a physical display
- Remote OS: Arch Linux, up to date, kernel version 4.20.6
- Local OS: Manjaro, up to date, kernel version 4.14.94
- MATE desktop on both the client and server
February 5, 2019 at 17:22 #21297fra81ModeratorIt could be a problem with slow access to video memory. We happened to observe such behaviour in the past on headless machines, but it could also depend on the drivers. Please attach the output of glxinfo.
You can also test what would happen if you use the virtual framebuffer provided by NoMachine instead of the “physical” output. In order to try that you have to turn off the graphical environment on the server (‘sudo systemctl stop gdm‘ or ‘sudo systemctl stop lightdm‘ or any other command which is suitable for the display manager in use) and then restart the NoMachine service (‘sudo /usr/NX/bin/nxserver –restart‘). So NoMachine will create a virtual framebuffer which you can connect to and test performance.
February 6, 2019 at 09:14 #21300DrPepperParticipantI was unable to get NoMachine to start my desktop environment. I tried adding unix-xsession-default to AvailableSessionTypes in node.cfg and server.cfg, and also setting DefaultDesktopCommand to “/usr/bin/dbus-launch –exit-with-session /usr/bin/mate-session”, but mate-session couldn’t connect to DBus.
Attachments:
February 8, 2019 at 23:55 #21330DrPepperParticipantI have some more information. I looked in /usr/NX/var/log/node/C-*-1001-*/session and found “NvInitCuda: ERROR! Failed to initialize CUDA device”. So I googled the error and found https://www.nomachine.com/TR02N06446. I tried the solution I found on that page, but when I ran the compiled program I kept getting 999 as output, even when running as root. After some more googling I decided to install the cuda and opencl-nvidia packages for Arch Linux. After rebooting, I again ran the program I compiled and its output this time was “0”. However, for NoMachine got a new error: “NvEncode: ERROR! Error is 15, ‘Invalid version’.”
The best information I could find for this error was at https://www.nomachine.com/TR01Q09096, but it supposedly only applies to Volta GPUs, and mine is a GTX 970.
February 11, 2019 at 15:48 #21339fra81ModeratorI was unable to get NoMachine to start my desktop environment. I tried adding unix-xsession-default to AvailableSessionTypes in node.cfg and server.cfg, and also setting DefaultDesktopCommand to “/usr/bin/dbus-launch –exit-with-session /usr/bin/mate-session”, but mate-session couldn’t connect to DBus.
It should work out of the box. Please check this article for some common issues with the desktop environment:
February 11, 2019 at 16:02 #21340fra81ModeratorHowever, for NoMachine got a new error: “NvEncode: ERROR! Error is 15, ‘Invalid version’.”
This will be fixed in the upcoming software update. It is a compatibility problem with most recent drivers (and the Trouble Report you mentions is indeed related). However this error should not prevent sessions from working correctly.
-
AuthorPosts
This topic was marked as solved, you can't post.