Forum Replies Created
-
Posts
-
There is a limit on the maximum resolution that encoders are able to deal with, and your setup probably exceeds the limit.
That problem will be solved when the following Feature Request is implemented:
The logs look clean (provided they are from the “bad” case).
Did you try to disable the hardware decoding on the client (Display settings tab in the player’s menu).
Not that I know of. I don’t know if Windows Remote Desktop can use the graphics card in any way. NoMachine for Windows will only allow you to connect to the physical desktop.
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.
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.
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.
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.
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.
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 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.
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.
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.
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?