- This topic has 12 replies, 4 voices, and was last updated 4 years, 11 months ago by
.
-
Posts
-
Hi, I was a big user of NoMachine 3.x from Windows at work to Linux at home. With the 4.x release, I remember having performance issues that I couldn’t spend time resolving at the time, so switched to x2go instead. I’d love to get back to using NoMachine again now, and to that end I’ve installed free versions of nomachine_6.9.2_1.exe on my Win10 (1803) physical workstation at work and nomachine_6.9.2_1_amd64.deb on my physical UbuntuStudio 19.10 workstation running XFCE at home. I am connecting from Win10 to Ubuntu.
The 5 second lag I’m experiencing seems to have to do with the client input getting to the remote server, even though that doesn’t make sense to me. It’s just single mouse clicks, or keyboard presses. A GUI example is, Thunderbird email client displaying an HTML email with lots of images. I click the mouse on a different HTML email with lots of images and there is no response whatsoever for about 5 seconds, after which the full email, with full quality images and all, snaps into view. A non-GUI example is, in a terminal emulator I type uptime<ENTER> and 5 seconds later the echo’ed uptime command appears with the results.
Some things I’ve tried changing are: setting the server to use VP8, H.264, or MJPEG with no differences, other than worse quality using MJPEG. Setting disable client side hardware decoding. Reducing the display quality all the way down to 1. Disabling audio streaming and microphone input.
Can you help? Thanks! -Ross
Hi Ross,
please gather server and client side logs, as explained in https://www.nomachine.com/AR10K00697 and https://www.nomachine.com/DT10O00163#2.3. You can send them to forum[at]nomachine[dot]com.
Also session statistics could be useful:
– open the Connection panel in the NoMachine Menu Panel (see https://www.nomachine.com/DT07M00087#9);
– click on ‘Take the statistics’ once to reset counters and discard the result;
– reproduce the issue (for example type in the terminal and wait for the result);
– click on ‘Take the statistics’ one more time and send us the resulting file.Log and session statistics files just sent, thanks for looking at this with me.
Interestingly, there was a brief time yesterday afternoon when the 5 second lag went away, so I’m hopeful that means there is a way to resolve this. I kept the session open for a couple of hours and unlocked the screensaver periodically to work on it. One of the times I unlocked the screensaver, the session did not have the lag! I was able to freely click around, run commands, use the mouse wheel to scroll, all without significant lag. The next time I unlocked the screensaver, though, it was back to the 5 second lag for each input. Same for rest of yesterday and this morning.
One final piece of information, on the reverse connection, with my home Ubuntu workstation as client and my work Win10 workstation as server, there was no lag.
I was able to eliminate the problem by toggling the Resize Remote Screen setting a couple of times, and it’s possible that toggling the Fullscreen setting was involved as well. I’ve captured the same logs and session statistics (sent in another email) now that there is not the 5 second lag, hoping that this will help identify the exact cause. I will continue to test! -Ross
Logs are pretty clean. Are you sure it’s not something with your network setup. Are you using a VPN service between the client and the server maybe? Could that be the culprit?
I would also try to disable UDP (Edit connection -> Advanced -> uncheck ‘Use UDP communication for multimedia data’).
Also, please check CPU usage during the “freeze”.
I’ve narrowed it down to one specific action that always gets rid of the 5 second response lag problem.
My standard procedure was to connect with the Resize remote screen disabled in the client, and then I was maximizing the client window (not selecting Fullscreen mode). All of this kept whatever screen sizing was already on the server as is.
What I’ve discovered is that as soon as I do anything that causes the the server screen sizing to adjust, it seems to “connect” the client and server screens in some special way and eliminates the 5 second response lag.
So, now I am keeping Resize remote screen enabled on the client all the time, and as long as there is some kind of screen size synchronization between the client and the server, there is no 5 second response lag. Without knowing more about the inner workings of the protocol I can’t explain why this works, but it does.
Hi, I was able to test disabling UDP today, and unfortunately did not see any change in behavior. I will continue to test with UDP disabled, but it doesn’t look promising. Any other thoughts? Other logging I can capture?
This is a really strange issue. Could this Trouble Report possibly apply to your case?
Hard to say, I’m not exactly clear on what is meant by using “a USB device is connected inside the NoMachine session”. Also, the fact that the keyboard and mouse make that ticket’s symptoms go away for a while is not the same as what I’m seeing. I do have a USB keyboard, mouse, Plantronics headset, and Imprivata badge reader at the Windows client, but none of those are exported to the remote computer. I don’t think it matters what’s on the remote Linux computer, but there I have a USB keyboard, mouse, and a MIDI controller.
Thanks for info. Indeed you would have to export those devices explicitly in order to trigger that problem.
Would you mind to try one more thing? In https://www.nomachine.com/AR03P00973 you can find a couple of methods to turn off the local X server on Ubuntu. In this case NoMachine will then use its own virtual frame buffer and we would be able to exclude or narrow down this issue to drivers on server side. And if possible, it would be nice to check the CPU usage of the server while reproducing the issue.
I’m willing to try that idea, but I don’t think I could use it as a long-term solution. One of the reasons I wanted to switch back to !M from X2go (the main reason is security!) was so that I could keep the same session up at all times. I lock it at home, go to work and connect to the same session from the office.
Do I understand the idea of that knowlegebase article correctly?
This topic was marked as solved, you can't post.