Forum Replies Created
-
Posts
-
Hello,
your problem could be similar to the one reported here: https://www.nomachine.com/forums/topic/ubuntu-desktop-freeze-on-login-if-headless. Please check if the solutions reported there are feasible for you.
Alternatively you could try to configure your xorg.conf to support the headless mode. After a quick search I found a couple of links (that I didn’t test):
http://jasonjuang.blogspot.it/2016/02/how-to-configure-xorgconf-for-headless.html
http://www.virtualgl.org/Documentation/HeadlessNVHi Markus,
sorry again for the delay. We are still unable to reproduce this issue in our labs. We just got one report from a user that observed a couple of times that all processes started consuming more CPU and everything got fixed by a system reboot. Did you try to reboot and see if the problem settles down? Or, if the affected user creates a new session, is the new one also slower than normal? And more important, are always the same users affected, or anyone can be? Could this be happening for sessions running since a long time?
Anyway I’m afraid that, after we excluded all other cases, only thing left to do is profiling the nxnode.bin process, assuming that CPU usage is really related to the problem. Unfortunately this won’t be easy, because the profiler slows down the process itself, and so it might be hard to detect when you are reproducing the problem. If you are willing to try, please follow the instructions in https://www.nomachine.com/AR09L00809, but with a different DebugOptions key:
DebugOptions “–tool=callgrind –dump-instr=yes –callgrind-out-file=/tmp/nxnode.%p.callgrind.out”
And lastly, you mentioned CentOS 7 boxes. Are they running on top of a virtualization tool? Which one and what version? This might be what is different in our tests.
An issue with the driver is a possibility. You can try to disable the hardware acceleration in NoMachine:
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.