Windows 10 to Debian 11 is sluggish

Forum / NoMachine for Windows / Windows 10 to Debian 11 is sluggish

Viewing 15 posts - 16 through 30 (of 30 total)
  • Author
  • #41211

    Hi, disabling HW decoding on the client is done in the Player configuration, apologies if this was not made clear:

    You need to edit the file $HOME/.nx/config/player.cfg and set the configuration key “Enable hardware accelerated decoding” to “disabled”.

    The options are:
    – true: hw decoding enabled
    – false: hw decoding disabled (but libraries for hw decoding are loaded)
    – disabled: hw decoding disabled (libraries for hw decoding are never loaded and the checkbox is greyed out inside menu panel)

    You can also toggle HW decoding from the connection menu (during the session), but this will toggle between true and false, see above).

    Can you confirm that the player.cfg file has “disabled” next to the Enable hardware accelerated decoding key?



    Thanks, @Britgirl.

    “Enable hardware accelerated decoding” is disabled on the Linux machine, but that is the server. The player (client) is running on Windows. I did find a setting in the advanced display settings to “Disable client side hardware decoding”, and I selected that. The Connection information on the client side reports that Encoding and Decoding are both set to SW.

    Now we wait and see if the symptoms return.



    From an earlier comment of your “When I disabled it before, I only did it on the Windows machine. Should I have also disabled it on the Linux (server) machine?” – no it was not necessary 🙂

    HW decoding is a client-side setting (the device you are connecting from), so in your case you only needed to disable it on your Windows computer.


    I’ve spent the last week trying lots of things in an attempt to find something to provide a clue, but nothing I’ve tried has resulted in a consistently responsive connection. Here are the things I’ve tried:

    1. I updated the NoMachine software on both client and server to 8.2.3.

    2. I updated the graphics driver on the client to the latest AMD version dated 10/2022. I eventually had to roll back to the earlier driver, because it sometimes failed to produce any image in browser windows.

    3. I tried both enabling and disabling hardware decoding on the client.

    4. I set the server up to dual boot both Xubuntu 22.04 and Debian 11. Similar behavior on both.

    5. I tried both wire (gigabit) and WiFi connections between the client and the server.

    6. I have the client set up within sight of the server’s display. Any action (keyboard, mouse, scroll) on the client machine show up immediately on the server display, but takes a variable amount of time to respond on the client display. Sometimes its virtually instantaneous, other times there is a delay.

    7. I tried to determine if the NoMachine process on the client machine was using excessive CPU, but this is not really possible using the Task Manager -> Display tab as suggested earlier, because the results are updated about once per second, and I don’t think there is a way to take a screenshot of the Task Manager display while connected to the server. As an alternative, I check the Task Manager -> Performance -> CPU tab, because it provides an indication over time. Even when displaying video on the server, the graph never goes above 20% utilization.

    8. I resurrected my old laptop (with an Intel processor), updated to the same software versions as the new one (with an AMD) processor. Recall that my original fear was that the difference was in the processor/graphics department. The old laptop is now displaying similar behavior to the new one – sluggishness.

    9. I tried rolling both client and server software back to version 7.10.1. I believe I have copies of version 6.9.2, but I haven’t tried those yet.

    One more detail that I don’t think has been considered before: I’m running X11, not Wayland.

    This is very frustrating. There are times when everything briefly is working well, often shortly after client and/or server machines are rebooted or when I disconnect/reconnect to the server. Then I start seeing typing, scrolling, moving from window to window or desktop to desktop on the server take a variable amount of time, sometimes up to several seconds.

    Is there any other type of debugging/logging/testing I can try?



    Follow up and correction to my previous post:

    I decided to confirm my impression that my old laptop (Intel CPU/Graphics)  was behaving in the same way as the new one (AMD/Radeon graphics). I was surprised to find that the old computer works fine, while the new one is problematic.

    I no longer have any doubt that there is some interaction between either the AMD processor or the graphics chip/driver that is causing this issue.

    While I searched the Forums for NX issues between Windows 10 and Debian, I have not yet attempted to see if there is any mention specifically relating to AMD/Radeon. I’ll pursue this angle next.





    our own tests don’t show the issues you are encountering and we are not aware of specific issues related only to AMD.

    Let’s look at the statistics which you can get from withing the session itself and the Windows player and Ubuntu server logs with debug enabled. – this document includes the instructions for server and player side logs.

    You can also enable server side logs (Your Ubuntu machine) from the UI by going in to Server settings -> Status -> Server logs – 7

    To retrieve statistics for your NoMachine session, run the menu panel within the session by Ctrl+Alt+0 or click on the page peel. Click on Connection, then click on ‘Take the statistics’ and save them on your local device.




    I believe I have stumbled on to the underlying cause of this issue.

    I decided to look closer at the graphics driver. First, in the Device Manager listing for Display Adapters, I found the driver and went to the Properties->Driver->Update Driver tab. Then, “Browse my computer for drivers” and “Let me pick from a list of available drivers on my computer”. This led to the original driver that came with the computer, the one that I had downloaded from AMD and a third option, “Microsoft Basic Display Adapter”. I switched to the Basic Display adapter and noticed the same sluggish behavior.

    I then opened a tab in the Properties box called “Events”. I noticed a number of instances of a description “Device not started (amdwddmg)”. The description of the error was just “had a problem starting”. I noticed this starting at the time I bought the new computer. I also saw the same event when I switched to the Basic Display driver.

    I then searched the Internet for issues that people were having with the AMD Radeon driver (amdwddmg), finding that there were a number of issues reported of this event code, mostly with people gaming. One suggestion was to uninstall the device and reinstall it, then reboot.

    After doing this, I went back to the Properties->Events tab and noticed that the last instance of the error message was from my previous update of the driver, not the re-installation.

    I next connected to the server, and from what I can tell so far, all is well. Since this problem has taken a while to show up before, I’ll give it some time before declaring victory, but so far it looks good.

    (I found the references to collecting logs and created them, then browsed through the results, but they didn’t really mean much to me. I was actually looking for another issue I had noticed that you had discussed in another thread on this forum relating to the server not using hardware encoding since the transition from version 7 to version 8. I had noticed this, too. I wasn’t able to confirm that the server was using hardware encoding, even after supposedly enabling it in the server status application. I don’t know whether this is something that requires hardware that I don’t have on the server machine, so I didn’t pursue it any further.)



    I found the references to collecting logs and created them, then browsed through the results

    Send them in anyway, we’ll take a look. Send them to the forum[at]nomachine[dot]com email like before.

    Something I forgot to mention in my last follow up as a last attempt to see if it’s related to NoMachine software was to try disabling UDP from the connection sections. Go to Machines in your Player, right click the connection, click Edit and then Configuration -> Multimedia, make sure the box is NOT ticked. Do this before you gather any statistics and logs I requested earlier today.


    I declared victory too soon.

    This morning I am back to the sluggish screen updates.

    I guess the good thing is that now I have been able to collect logs that may be more helpful:

    1. I set the server log level to 7

    2. I disabled UDP in the player connection

    3. I disabled client-side hw decoding

    4. I enabled server logs

    5. I viewed video data for a few minutes in a browser window. The video was jerky.

    6. I collected then disabled the server logs.

    7. I collected the player logs and statistics

    I’ll attach the result here and email them.



    My best guess is that this is an issue in the AMD graphics driver that is obscure enough that it is not likely to be resolved, as I feared when I first posted. I go back and forth between my old Intel-based laptop and my AMD-based one. The Intel one has no problems. The AMD one seems to start out ok after a reboot and gets progressively worse the longer it is running, to the point that after a few days to a week or so it is very noticeable.

    I guess I’ll live with it until I can afford to replace this laptop with another Intel-based one. 🙁



    The logs don’t indicate any issue with NoMachine software. Rather there are multiple reconnects which would indicate problems with your network. Statistics show high latency which also indicates network issues. We can see “268 ms latency 5s, 221 ms latency 30s”.

    For 5 seconds there was an average of 268 ms latency and for 30 seconds there was an average of 221 ms latency, so you should looking in to your network conditions. It might not even neccessarily be a bandwidth problem, but maybe some other bottlenecks like router, switch, or network card even. Maybe you could do a ping and traceroute and monitor them when you’re reproducing the problem.



    Maybe I’ve been chasing the wrong tail. Given that I only see this problem on the new laptop, maybe there’s a network driver issue here.

    Thanks, @Britgirl. I’ll spend some time investigating this.




    I’m convinced that the problem has to be in the network driver on the laptop.

    As I’ve observed before, rebooting the laptop generally improves or eliminates the problem for some period of time. Once the laptop has been running for a while (sometimes more than a week), the sluggishness begins to appear and gets progressively worse over time. Once the problem gets bad enough that the connection to the server becomes practically unusable, if I ping from the laptop (via WiFi router and then by hardwired ethernet through a gigabit switch) to the server, I periodically see a lot of very long ping times, sometimes a second or more.

    I’m assuming that the problem is in the connection between the laptop and the WiFi router (i.e., the new laptop’s network driver), since the connection between the router and the server machine would be the same for both laptops, and the old laptop works fine. So I think my next step is to try to determine if there is a known issue with this driver and if there is some remedy available, such as a driver update or maybe some adjustable parameters to tweak.

    I think it’s safe to say that while the problem isn’t solved, at least it is no longer within the scope of this forum.

    Thanks for your help, @Britgirl.



    Hi BlueNGray,

    I’m replying on behalf of Britgirl;

    We were happy to help and thank you for the update on your issue, and hope you find a solution to the problem 🙂

    Please let us know if you have further issues that we need to investigate!

    Best Wishes,


    Thanks, @Bilbotine!

Viewing 15 posts - 16 through 30 (of 30 total)

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