fra81

[fra81]

Hi David,

as for the missing text in the error message, I can try to guess that it is about “can’t start command”. If you are using a custom command, are you sure that you’re writing it correctly or that it is in the PATH or even installed?

Given also the missing fonts, it seems like you don’t have a complete graphical environment installation on the server. Is that a possibility?

[fra81]

Notwithstanding the above, are there some reasons why one should favor the virtual session’s protocol? If there aren’t any, I will just stick to the physical session’s protocol.

It depends strictly on the desktop environment and used applications. X11 vector graphics mode is incomparable better at compressing traditional X traffic, but modern desktops and applications make more and more use of graphical effects and multimedia content. If physical session’s protocol works better for you, you should definitely use it. You can find more info here:

https://www.nomachine.com/AR01M00832

For this purpose, I installed the enterprise desktop evaluation but do I need to re-install the clients after I bought the fully licensed version of the terminal server?

You don’t have to reinstall clients. But be aware that the evaluation version doesn’t provide the library for H.264 software encoding. If your graphics card is not capable of H.264 hardware encoding, then you could not experience the best possible performance.

https://www.nomachine.com/AR10K00706

[fra81]

Hi Will,

nice to hear you found a solution. In fact this is not something that could be fixed on NoMachine side 😉

[fra81]

Hi Lars,

most data in virtual desktop is coming from images (#72 and #243 in the stats file), while other drawing operations don’t seem to contribute in a significant way, which is quite unexpected from a “lightweight” desktop. Physical desktop sessions can perform better in this specific case because used protocol is specifically optimized for multimedia content. Of course you can use the same protocol also in virtual desktop sessions, by simply unchecking the ‘Use X11 vector graphics mode in virtual sessions’ option in Server preferences -> Performance tab.

Alternatively, you can try to disable the Composite extension in virtual desktop sessions. This could cause the Xfce desktop to fallback to a rendering backend that, I hope, will make less use of bitmaps. To try that, add the following line to the ‘/usr/NX/etc/node.cfg’  file:

DisplayServerExtraOptions “-extension Composite”

 

A final note about compression ratio: the 1.260:1 ratio you report only includes X11 protocol compression but without considering images compression, which is the biggest part here. The correct overall value that includes also image compression is reported here:

overall: 709795968 bytes (693160 KB) in, 10296814 bytes (10055 KB) out.

That is a compression ratio of about 69:1. Not bad. Problem is that the desktop produced as many as 3000 images in only 100 seconds…

[fra81]

Hi Lars,

I don’t expect the virtual session to take more bandwidth, rather the contrary when using a lightweight desktop like Xfce, unless it is a matter of the applications running on it.

Please take the NoMachine statistics from the NoMachine Player menu and attach them here or send to forum[at]nomachine[dot]com. You can find the ‘Take the statistics’ button in the Connection tab of the session menu.

You can use this trick to take “partial” statistics while reproducing the problem:

– click on ‘Take the statistics’ and discard the result (this will reset all counters);

– operate inside the session with the slowness problem;

– click on ‘Take the statistics’ again to get partial stats.

[fra81]

This looks like the same issue reported in https://forums.nomachine.com/topic/lock-the-physical-screen-when-somebody-connects-session-disappears#post-18075. It seems that the bug upstream is still open.

To work around the issue, you can try to unselect ‘Lock the physical screen when somebody connects’.

[fra81]

Hi,

it looks like a crash of the X server. I’d start with checking X server’s logs, typically ‘/var/log/Xorg.0.log.old’, but to be sure you can grab any file starting with “Xorg.” in /var/log. You can attach the files here or send to forum[at]nomachine[dot]com. You may also try to update your system.

[fra81]

Yes, there is no way at the moment, but indeed that could be useful in some specific cases. We will evaluate if this is possible to achieve with used codecs without breaking in any way NoMachine’s sophisticated algorythms, and possibly in a way that is consistent across all codecs. In case, a feature request will be opened.

Thanks for the suggestion.

[fra81]

Hi Will,

I see another process using the graphics card besides the X server:

 0      1276      G   ...ts/.local/share/Steam/ubuntu12_32/steam   197MiB

Could you try to turn Steam off and see if anything change? In the meanwhile we will try to reproduce in our labs with same distro and card.

[fra81]

Hi Lars,

this is strange indeed. Xfce is a lightweight desktop that is known to work perfectly with NoMachine. Do you confirm that CPU usage is low not only for NoMachine processes but also for other system processes? And can you confirm that Xfce desktop is the one running also in the virtual session? (note: it wouldn’t be chosen normally by default)

Did you check the CPU usage also on client side?

Please tell us more about the distribution in use, so we can check it in our labs.

And last, what is your graphics card? Did you install proprietary drivers?

[fra81]

Also, I see that you have ‘Disable multi-pass display encoding’ checked. Can you try to uncheck it and see if you still reproduce the problem?

[fra81]

Hi Will,

it looks like a problem with video drivers. I would try to install latest from nVidia. But before that, please tell what is the Xorg version and more info about installed drivers:

# lspci

# nvidia-smi

# lshw -C display

[fra81]

Hi.

When the highest Display quality is set for the session, NoMachine is already cofigured to target the best quality possible.
Changing encoder presets would not affect quality, but only the ratio between encoding time (CPU usage, but also responsiveness) and video frames size (bitrate).

[fra81]

Hi @danny,

good to hear 🙂

[fra81]

Hi @saips,

it’s not all clear to me yet: you make a fresh system installation, then upgrade it and get the issue? Everything on the same machine? And what is the Xorg version in the fresh installation?

Also I see that you have an external keyboard and mouse. Can you check if you still reproduce the issue after unplugging them?

[Author]

Posts