fra81

[fra81]

Hi Cam,

sorry for delay!

Rootless sessions use a different protocol. H.264 is not used to encode all the screen, but only for encoding the videos, and that’s why it is not reported. You can check (or show us) the logs on client side to confirm that H.264 is actually used.

As for the specific problems with Chrome (and since you confirm that Firefox behaves differently), it may be that Chrome suffers for the lack of hardware acceleration. This would not be considered a NoMachine issue.

[fra81]

After further testing in our labs, I can say that this tearing problem is due to the limitations of the display server that NoMachine uses to render application’s windows in floating window mode on Windows. We are aware of that, and such problems will be solved by this Feature Request: https://www.nomachine.com/FR02N03010.

Note that this problem does not apply to other types of session, so you could run the browser is a virtual desktop for best performance. Additionally, you can disable the ‘X11 vector graphics mode’ in order to use the mode that is specifically optimized for multimedia content and rich graphics.

[fra81]

I still can’t imagine how NoMachine can cause this issue. While we try to reproduce in our labs, please make sure you check the following in order to exclude two possible causes:

– disable any remote resize caused by NoMachine (i.e. make sure ‘Resize remote screen’ button is not enabled in the session menu and also the ‘Match the client resolution upon connecting’ not checked in the Display settings);

– disable screen blanking (i.e. make sure ‘Lock the physical screen when somebody connect’ is not checked in the Server preferences -> Security tab on the server).

Do you confirm that only NoMachine triggers this behaviour and not the other remote desktop solutions that you tried?

[fra81]

Hi.

For sure NoMachine plans to support Wayland. Support for Wayland is currently under development, but I can’t say at the moment when it will be ready.

[fra81]

Hi Rich,

please provide more info about the Linux distribution in use on the server and the version of the browser, so that we can test the same in our labs. Please also tell if you are running the browser in a Custom session in Floating window mode (single application). Then you can check the CPU usage on client and server side, as well as the available network bandwidth, in order to search for possible bottlenecks.

[fra81]

Yes, in that case the problem is clearly with the video card.

 

[fra81]

Do you mean that 640×480 is the only resolution listed in the display settings panel of the remote OS? NoMachine can only use the resolutions that are made available by the system, so it depends entirely on the graphics card.

You may try to attach a monitor for a moment to your server and see if the additional resolutions will still be available after you detach the monitor.

[fra81]

NoMachine will generally try to make use of the available CPU power in order to deliver the best experience with even graphical intense applications. But that 60% when idle looks indeed strange and unusual. Please let us know:

1) the exact NoMachine version that you are using;

2) if by saying ‘idle’, you mean that you are connected with NoMachine to that server but no application is updating the screen (that looks as a still image);

3) if toggling the ‘Use acceleration for display processing’ option (Server settings -> Performance tab) has any effect.

Also the logs could be useful for further investigation. If you are willing to send them to us, please find here the instructions: https://www.nomachine.com/DT07M00098#3. You can send them to forum[at]nomachine[dot]com.

In other respects, consider enabling the H.264 codec, if you didn’t do already. That will help you saving CPU power (and bandwidth). Here you can find all the relevant info: https://www.nomachine.com/AR10K00706.

[fra81]

Hi Cam,

running 10 concurrent sessions all running CPU-demanding, graphics-intense applications on two cores doesn’t seem very realistic, considering that each core has to be shared between 5 sessions. Regarding the performance of the single session, you can try to turn off the ‘X11 vector graphics mode’ (Server settings -> Performance tab), thus enabling the “video” mode. The video mode is specifically designed for graphics-intense desktops and applications and for multimedia content. Also, it will allow to leverage the hardware encoding capabilities provided by your Maxwell GPU. While using the video mode, I’d also check in the NoMachine player GUI if H.264 encoding is actually in use (bring up the session menu and enter Display settings, codec info is at bottom).

[fra81]

Hi,

can you please provide more info:

1) Is the server a headless machine?

2) If it’s not headless, are the VM consoles on the physical screen of the host?

3) Can you provide the name of the VMware product in use and its version?

4) Can you provide the version of the nvidia driver?

[fra81]

It seems that putty is trying to connect to the same port (4000) where the NX daemon is listening, as you can see in the following line:

ERROR! Invalid client identification ‘SSH-2.0-PUTTY

To get rid of the error, you can either change putty configuration, or change the port for the NX server, by editing the NXPort key in the’/usr/NX/etc/server.cfg’ configuration file. For example:

NXPort 4001

[fra81]

Hi,

it is indeed a possible use case, though specific. I’m adding a note to the Feature Request.

[fra81]

In order to understand the cause of these errors we need debug logs from the server side. Please uncomment and set the ‘SessionLogLevel 7’ configuration key in the ‘/usr/NX/etc/server.cfg’ file. Here you can find detailed info on how to gather logs: https://www.nomachine.com/DT07M00098.

Then reproduce the issue and send the collected logs to forum[at]nomachine[dot]com.

[fra81]

It’s worth noting that such functionalities are already offered by the operative system. When a user logs in, it is logged with the specific priviliges of the logged system user. For example, the operative system can provide “public” directories designated to allow the file sharing between users. Even restricting the file transfer to specific directories, we wouldn’t prevent the user from copying a readable file from a restricted directory into an allowed directory, and then proceeding with the download (e.g., copying ‘/etc/passwd’ to ‘/MyDownloadableDirectory/Notes.txt’ and then downloading Notes.txt).
In other words, we would step on the operative system’s toes, that we don’t think it is a good idea.

But still, a detailed and accurate logging is absolutely necessary.

 

[fra81]

Hi Chris,

it looks like the same issue described here (fixed in version 5.1.40):

https://www.nomachine.com/TR04N06709

Upgrading the server side to the last version should solve it.

[Author]

Posts