fra81

[fra81]

Hi!

We were not able to reproduce this problem with a similar environment.

Please attach the output of the ‘xdpyinfo’ command run inside the Ubuntu machine.

Also NoMachine logs could be useful. You can find here instuctions on how to gather server side logs here: https://www.nomachine.com/DT07M00098. You can send them to forum[at]nomachine[dot]com.

[fra81]

Hi Markus,

can you tell me which is the process consuming more CPU in the bad case?

[fra81]

Hello.

I don’t know how you collected the network usage, but you could try to use the own NoMachine tool for more detailed info (https://www.nomachine.com/AR02N00875). Consider that even if the average bandwidth usage is around 2 MB/s, the encoder could still produce overshoots on scene changes. And even if the link capacity is not reached, also the transfer time of large packets is to be considered. In order to estimate to what extent the lag is due to the bandwidth usage, you can try to lower the Quality slider.

Finally, I suggest to enable the H.264 encoder, if you didn’t do it already, by following the instructions in https://www.nomachine.com/AR10K00706. That will help with both bandwidth and CPU usage.

[fra81]

Thank you for the logs.

We reproduced the same problem with very high resolutions, and it is now tracked here:

https://www.nomachine.com/TR12N07455

Note that you should be able to create a virtual desktop having a lower resolution regardless the current layout of your monitors, by just not maximizing the NoMachine Player window. In fact the virtual desktop’s screen should have the same size of the player’s window. I recommend to create a new connection though, since the resolution could have been saved in the configuration file of the existing connection.

[fra81]

Hi tobi,

please find the core file on your server (usually /home/<user>/core), and get a backtrace from it following these instructions: https://www.nomachine.com/AR09L00810. Attach it here or send to forum[at]nomachine[dot]com.

[fra81]

Hi Markus,

that sounds strange indeed and I have no record of similar experiences.

For a start, I would note CPU and memory usage on both client and server side.

You can also gather a full set of logs as explained in https://www.nomachine.com/DT07M00098 and send them to forum[at]nomachine[dot]com, so that we can try to find a clue there.

Additionally, also session statistics might be useful (https://www.nomachine.com/DT07M00087&dn=statistics#9). Take them, if possible, for a “good” and a “bad” case.

Don’t hesitate to let us know if you spot any difference between the good and the bad cases.

[fra81]

Hi Christos,

it looks like your configuration enables a “viewport” mode in the X server, that is the screen is treated as it were not visible outside the central rectangle area (“the viewport”). So that, areas outside the viewport are not refreshed. I would probably avoid  to mess with xorg.conf. You may try instead to revert it and try one of the two solutions suggested in this post: https://www.nomachine.com/forums/topic/ubuntu-desktop-freeze-on-login-if-headless#post-13240.

• This reply was modified 7 years, 4 months ago by fra81.

[fra81]

This probably occurs because when no monitor is attached no rendering actually happens (graphics card is “turned off”). You can try to stop the X server as suggested here: https://www.nomachine.com/forums/topic/ubuntu-16-04-headless-resolution-stuck-1024×768#post-11035. NoMachine will then create his own virtual display.

Alternatively you can use a display emulator dongle.

[fra81]

Hi Tord,

VirtualGL splits OpenGL rendering from other graphical operations and redirects it to the local X server. NoMachine does not interfere with this process, thus practically reducing to zero the possibility of an incompatibility between the two.

According to the information in our possession, NoMachine users mainly use Nvidia cards, of different models, with satisfactory results.

For more information we suggest to refer to the VirtualGL documentation, for example https://cdn.rawgit.com/VirtualGL/virtualgl/2.5.1/doc/index.html#hd004.

[fra81]

Hi!

Such CPU usage doesn’t look “pathological”, though there are a few things that you could try to lower the CPU usage:

– checking the ‘Disable client side image post-processing’ option in the Display settings tab;

– verifying if the ‘Disable hardware decoding’ option in the same tab is unckecked;

– disabling the ‘Fit to window’ display option.

 

However NoMachine is currently working on porting most of its image processing algorithms to the GPU, thus offloading the CPU. Work on this is in an advanced state.

[fra81]

Can you please provide more info:

– Are you connecting to the physical display of the Ubuntu server or are you running virtual sessions?

– And if you are running virtual sessions, is ‘Use X11 vector graphics mode’ checked? (it is by default)

– What desktop environment is in use in the remote session (either in the physical display or in the virtual session)?

– What graphics card and driver is installed on the remote system?

[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.

[Author]

Posts