Forum / NoMachine for Windows / Windows 10 to Debian 11 is sluggish
- This topic has 29 replies, 4 voices, and was last updated 1 year, 11 months ago by BlueNGray.
-
AuthorPosts
-
September 12, 2022 at 19:53 #40101BlueNGrayParticipant
In February I bought a new laptop with an AMD Ryzen 5 PRO 4650U processor and started having a problem I never had before with Intel processors.
Using free version nxviewer version 7.10.2_8 on Windows 10 connection to nxserver version 7.9.2_1 on Linux Debian 11 (with a physical display), the response of the remote seems very sluggish. Not at all what I’m used to. I’ve tried upgrading and downgrading the NX versions with no effect.
It almost feels like a machine loading issue on the remote end, but the load average is typically < 1.0 , and it’s not always sluggish by the same amount. Sometimes it can take several seconds to react to a character typed into a console window or a button pressed in a graphical application. Other times it’s less than a second, but still enough to be noticeable.
For a while I thought it was related to multiple connect/disconnect cycles, perhaps due to some processes running on the Windows client being left running after disconnecting. It would get worse with each connect/disconnect until I rebooted the Windows machine, then it would get better for a while. Recently, however, that doesn’t seem to help much.
While researching this a few months ago, I think I saw a reference to issues with AMD graphics drivers, but I haven’t been able to locate that reference again.
I’d sure love to know what is causing this, because it’s making it almost painful to use NX any more. Should I be sorry I bought a laptop with an AMD processor?
September 13, 2022 at 13:00 #40110BilbotineParticipantHello BlueNGray,
Your description indeed lets us think that it is a problem with the drivers, but we can’t be sure. Can you tell us if the AMD processor is on the Windows machine (the client) or the Debian one (the server)?
We suggest to try to disable hardware decoding on the client, and please also show us the CPU usage on client and server.
Looking forward to your answer.
September 13, 2022 at 17:04 #40117BlueNGrayParticipantHi Bilbotine:
Thanks for your reply.
I’ll answer some of the questions, with a commitment to provide an update with CPU usage information soon (but maybe not today, a lot of things going on around here right now, and after a few changes described below and reboots, things are doing ok for the moment.)
NX Client:
Windows 10 Pro, 21H2 release with all updates applied
AMD Ryzen 5 Pro 4650U with Radeon graphics 2.10 GHz
16 GB RAM
Nomachine version 7.10.2
NX Server #1:
Debian 11 Bullseye fresh install (yesterday) fully updated OS and packages. XFCE4 desktop version 4.16.
Intel i3 2120 CPU @ 3.3 GHz
AMD Cedar [Radeon HD 5000/6000/7350/8350 Series] graphics @ 33 MHz clock
32 GB RAM
Updated to Nomachine version 7.10.1_1_amd64 yesterday
NX Server #2:
Debian 11 Bullseye fully updated OS and packages. XFCE4 desktop version 4.16.
Intel Core i7-3630QM @ 2.40 GHz
Intel 3rd Gen Core processor Graphics Controller
8 GB RAM
Updated to Nomachine version 7.10.1_1_amd64 yesterday
Other Information:
Both servers are connected via a Gigabit switch to a Netgear R6400 v2 router. The Windows client is connected to the servers via the router’s WiFi link (5Ghz). The wireless link is pretty lightly loaded. At the moment the Windows connection to NX server #1 is the only active link. I sometimes have a wireless link to an Amazon Fire Stick 4k and/or a Samsung Galaxy Tab 3 active on the link, but those typically don’t make much difference.
When I see the issue, it affects both of the Debian servers, which, along with the fact that the problem didn’t show up until I replaced my Laptop in February with an AMD processor based one, leads me to suspect something on the Windows end.
This morning I disabled hardware encoding on the Windows client, and rebooted. For the moment, the performance seems ok, but it sometimes takes a day or more after rebooting Windows before I start seeing the issue. Since I’ve made some changes, I’ll watch it for a while and provide CPU usage numbers if it shows up again. The Linux load averages should be easy enough to collect, but what form would you like to see the Windows numbers in? (I’m not much into Windows)
Thank you for your time.
September 14, 2022 at 12:11 #40128BilbotineParticipantHi BlueNGray,
You can check the following link to find out more about collecting usage on Windows:
Is that what you are looking for, or did I misunderstand you ?
We look forward to your update on the CPU usage 🙂
Best regards,
September 15, 2022 at 19:12 #40159BlueNGrayParticipantHi Bilbotine:
Yes, the link you provided gives me an idea of what needs to be done.
It’s been a couple days now since I disabled hardware decoding on the client and I haven’t noticed the sluggishness I had earlier. I’ve attached CPU usage for the client and server #1, which is the one I use most.
I think the next step will be to re-enable hardware decoding and see if the sluggishness comes back. If so, I’ll update with new CPU usage info.
Thanks.
Attachments:
September 16, 2022 at 09:57 #40163BilbotineParticipantHi BlueNGray,
One of your files was too big and couldn’t be uploaded (“CPU-Usage-hw-decode-disabled.png”).
Can you please send it by email to forum[at]nomachine[dot]com, making sure to reference the topic in subject ?
Thank you!
September 16, 2022 at 11:10 #40169sil04ParticipantHi BlueNGray,
may you please tell us also which is the driver version of graphic card on the client?
September 16, 2022 at 13:26 #40170BlueNGrayParticipantHi Bilbotine:
I emailed the file as requested. As I mentioned in the email, I don’t know for sure if this is what you’re looking for. It’s a screen shot of the CPU utilization during a time that the nomachine connection was active. If you were looking for individual processes that were running at that time, I’ll have to send something else.
Hi Sil04:
Here is the information of the client graphics driver:
Driver Provider: Advanced Micro Devices, Inc.
Driver Date: 12/29/2021
Driver Version: 30.0.13040.5001
Driver Signer: Microsoft Windows Hardware Compatability PublisherSeptember 23, 2022 at 14:15 #40311BritgirlKeymasterI think the next step will be to re-enable hardware decoding and see if the sluggishness comes back. If so, I’ll update with new CPU usage info
Ideally, we would need a screen of the Details tab of the Task Manager. If you reproduce it again, submit that.
September 25, 2022 at 00:28 #40338BlueNGrayParticipantI’ve had hardware decoding re-enabled for more than a week now and the sluggishness has not yet returned, at least not noticeably so. I’m still monitoring for it daily, but I haven’t been working very actively since then.
If it comes back, I’ll send another screenshot of the Details tab.
October 3, 2022 at 20:09 #40534BlueNGrayParticipantIt’s been a couple weeks since I’ve re-enabled hardware decoding, and I’ve now been seeing the sluggish behavior gradually increasing. I’ll upload a couple of screen shots of the Task Manager Details tab as requested. I certainly don’t see any sign of the CPU being monopolized by any process. However, since the Details tab provides a real-time display of CPU utilization, I don’t know how meaningful this information will be, because I can’t observe the sluggish behavior and trigger the screen shot at the same time.
I’m thinking the next step will be to go back to disable the hardware decoding. Perhaps the issue was actually there, but I just didn’t wait long enough for it to show up. I won’t do that yet, though, in case there is some other test you want me to try first. On the other hand, if the permanent work-around ends up being to run with hardware decoding turned off, I could live with that.
Attachments:
October 4, 2022 at 17:33 #40567BritgirlKeymasterPlease “re”-disable the hardware decoder. We need to be sure that it is indeed the cause.
October 4, 2022 at 18:53 #40577BlueNGrayParticipantI’ve disabled hardware encoding on the Windows (client).
When I disabled it before, I only did it on the Windows machine. Should I have also disabled it on the LInux (server) machine? Maybe that will be the next step if the sluggishness comes back. In either case, I’m not going to be too quick to assume that this fixes the problem. I’ll run it this way for a couple weeks.
Thanks.
October 23, 2022 at 04:40 #40879BlueNGrayParticipantAfter disabling hardware encoding on the Windows client, the sluggishness came back after a week or so.
I have now (a few days ago) disabled it on the Linux server. So far, everything seems to be running fine with no sluggishness. I’ll update when I think I’m satisfied the change has resolved the issue.
November 3, 2022 at 05:17 #41200BlueNGrayParticipantSorry for taking so long to update, but my last test didn’t fix the problem. Meanwhile, I’ve been trying a lot of things.
First, I found that disabling hardware encoding on both the client and server machines didn’t change anything. Then, I realized that the setting for hardware encoding is in the Server settings, so I wouldn’t have expected changing the client machine to have any effect. If there is a separate setting for client-side hardware encoding, I didn’t find it. This made me wonder if I wasn’t correctly addressing @britgirl’s request that I disable hardware decoding.
Next, I switched the server machine from Debian 11 to xubuntu 22.04 (LTS). Still not much difference.
Finally, I installed all the latest Microsoft updates on the Windows 10 client and updated the client and server NX software to version 8.1.2.
It’s only been less than an hour since I installed the NX update, but so far, the responsiveness is still good, but since it has typically taken a couple days of use and connect/disconnect to see the sluggishness return, I’m not going to declare victory yet.
Another test I’m running is to go back to my previous laptop (where I wasn’t having this issue), bring it up to date with the same Windows 10 and NX versions as I’m running on the new laptop. I haven’t had much time to play with this configuration, but my first attempt to use it resulted in the connection being dropped after about 3 seconds every time I connected. This seems a bit concerning, but it’s not as critical right now as getting everything running right on my new laptop.
(To refresh a key point here: The old laptop has an Intel processor and dual Intel/NVIDIA GeForce video (not sure which is being used), the new one has an AMD processor and Radeon graphics. I was concerned that the difference in processor/graphics may have been the cause of my problem.)
-
AuthorPosts
This topic was marked as solved, you can't post.