Forum Replies Created
-
Posts
-
So, if I understand, the non-working case is with NoMachine player running on the Windows 7 guest, connecting to NoMachine server running on the Windows Server 2016 (virtualized) host.
The fact NVENC encoder is available or not shouldn’t have any effect on the blank screen, but maybe there is some problem with the passed-through GPU. Please try to open the NoMachine Server preferences menu on the Windows Server host (server side of the connection), go to Performance tab, and uncheck ‘Use acceleration for display processing’.
In any case, you can send us the logs for further investigations as eplained in https://www.nomachine.com/DT07M00098. You can send to forum[at]nomachine[dot]com.
Hi,
if there is a very limited bandwidth, I wouldn’t touch the settings at point 1 and 2, but rather let NoMachine do its job at controlling congestion. In fact checking those boxes will limit the ability of congestion control algorythms to adapt to detected network conditions by adjusting image quality dinamically. Those settings won’t change the final quality, they only affect the progression and the speed how the target quality is reached.
In your case, I think that the best option is to act on the Quality slider only to find the best balance between quality and responsiveness, assuming that the lack of responsiveness is only, or mostly, due to limited bandwidth. Maybe it’s worth checking the network latency too (round trip time), if you didn’t do already (VPN could play a role here). You can do that also from NoMachine user interface (‘Take the statistics’), or with the ‘ping’ command.
A last note about Capture2.png: that blurriness around edges of coloured images is due to the chroma subsampling introduced by the encoder. NoMachine has algorithms to correct such color shift (https://www.nomachine.com/FR03M02907), but those are enabled only for quality level 5 or above (from the middle of the Quality slider to the right).
Well spotted!
The intention was to say:
Setting a higher value for the ‘latency’ option means that NoMachine will not attempt to reduce the throughput to minimize response time as long as the latter is below the indicated value.
I corrected the FR accordingly. Thanks for reporting!
Is there any other way to modify the quality in addition to the display setting window?
No other way besides checking ‘Disable multi-pass display encoding’ to disable “progressive encoding”. But this will consume much more bandwidth.
1) Some screenshots, or even better a video, would be great.
2) Yes, definitely it is possible that achieved quality is not exactly the same with the hardware encoder, but at the moment I’m not able to say how much a Pascal card would improve things. Maybe you can try to compensate by increasing display quality in the Display settings panel?
Hi Gareth,
are you using the NoMachine free product and connecting to the physical display? And what version?
What is the desktop environment on the server (GNOME, KDE, …)?
Is that a headless server? What graphics card and drivers?
Hello,
you may want to take a look at the recently updated:
https://www.nomachine.com/FR03M02905
Hardware encoding with QuickSync is now supported out of the box on Windows, while on Linux further configurations are needed, as explained in the referenced article.
I’m not sure I understand what you mean with “artifacts problem”. Are you referring to some known problem of the nVidia encoder? Or a problem with NoMachine? A screenshot of those artifacts could help to clear things out.
Hi Will,
we verified the problem in our labs and opened the following Trouble Report to track it:
https://www.nomachine.com/TR09O08043
Thanks for reporting.
We reproduced the issue in our labs. A fix will be probably released in the next software update.
You can track it here:
https://www.nomachine.com/TR09O08042
Thanks for reporting 😉
Hi Thor,
what you say about other window managers being affected seems to point to video drivers. Without getting into details on how difficult is the cooperation between applications doing direct rendering, window managers, X.org and video drivers, I can say that this is not the first time we observe this kind of problems, as video drivers are better designed to push images to the video device rather than to pull them back into main memory. NoMachine in the current implementation doesn’t do anything special, as it uses core X.org functions to get screen images. So what appears to be broken here is a very basic functionality, as we can see with the simple xwd utility.
What you suggest is indeed a possibility. One that we evaluated in the past, I have to say. But I think that now we have a much better chance. We are already working at an alternative implementation that doesn’t rely on X.org, but that will work at the level of the grapchics card. This will help in supporting the new Wayland display manager, but it will also benefit X.org-based environments.
You may want to track this Feature Request to know when that will be released:
Sorry, it looks like there was a formatting problem. It should be ‘- -restart’ (without the space). But to make it easy, you can just reboot the machine.
Should you still be unable to connect after restart (or reboot), please send us the logs for further investigations (https://www.nomachine.com/DT07M00098). You can send them to forum[at]nomachine[dot]com.
As for performance, let’s see how it will be after the configuration change is applied, but it has to be noted that 200ms is quite a long ping time.
Can you try to issue a ‘ping’ command from the Windows host to the Mac and tell us the result?
Is the Mac host a headless machine (Mac Mini with no monitor attached)?
Finally, please try to edit the ‘/Applications/NoMachine.app/Contents/Frameworks/etc/node.cfg’ file. Add there this line:
DisplayServerExtraOptions “-nostreamgrab”
That will enable an alternative screen capture method. After applying the change, you will have to restart the server:
sudo /Applications/NoMachine.app/Contents/Frameworks/bin/nxserver –restart
You’re welcome!
I’d just like to add that NoMachine can leverage the GPU acceleration in order to reduce drastically the CPU usage in most situations. Unfortunately the actual GPU support level inside virtual machines not always is as required.
Hi Val,
I would start with checking the basics in order to narrow things down. How is the CPU usage on both client and server side, and how does the bad case compare to the good case? Did you try already to verify the bandwidth and latency actually available between the sites? Do the different sites use the same desktop environment (xfce 4.8 on CentOS 6) and applications?
Hi MalcomS,
that could mean that 3D acceleration is not available in the virtual machine, and so the most advanced screen capture mechanisms cannot be used by NoMachine. You can try to assign more CPU resources to your virtual machine. For example, if you assigned only one CPU, that is usually not enough. You may also try to enable 3D acceleration for the guest, but from my experience results are not always as expected and they strongly depend on the system.
If necessary, and you still want to send logs for further inspection, here are instructions: https://www.nomachine.com/DT07M00098. You can send them to forum[at]nomachine[dot]com.