fra81

[fra81]

Hi Walter,

please show us the output of these three commands:

nvidia-smi --query-gpu=timestamp,temperature.gpu,utilization.gpu,utilization.memory,memory.total,memory.free,memory.used --format=csv -l 1

nvidia-smi --query-compute-apps=timestamp,process_name,pid,used_memory --format=csv -l 1

nvidia-smi --query-accounted-apps=timestamp,pid,gpu_util,mem_util,time --format=csv -l 1

Run each the command, reproduce the issue with high GPU temperature, the collect the output.

Also gather logs from the linux machine as shown in https://www.nomachine.com/AR10K00697.

[fra81]

Hi,

please also try to disable hardware encoding. To do so, edit the ‘/usr/NX/etc/node.cfg’ configuration file by adding the following line:

EnableHardwareEncoding 0

Then restart the service:

/usr/NX/bin/nxserver --restart

[fra81]

Hi,

it is possible that the X server is working with reduced performance while in headless mode. You can try to turn it off so NoMachine will create its own X virtual frame buffer:

# sudo systemctl stop display-manager

To disable automatic start and make the change persistent:

# sudo systemctl disable display-manager

Then restart the NoMachine service:

# sudo /etc/NX/nxserver --restart

[fra81]

Hello,

multiple connections should have a minimum impact on system resources. This looks more like a bandwidth limitation of the network. That may be checked by lowering the quality to the minimum value in the Display settings panel.

[fra81]

Hi electrosaur,

does this occur with a specific application? Any idea what could be triggering the issue (e.g. a special key combination)? Did you try to press and release modifiers (like Ctrl or Alt) to see if any of them got stuck?

[fra81]

Hello,

this is not possible at the moment. It is something we planned to add, and still on the list, but not with high priority. In fact it has to be considered that a FullHD 60fps uncompressed video will take around 4Gbps, a 4K video will take something like 16Gbps…and this would be too much data for any network.

[fra81]

Yes, it must be the disconnections.

I’ve seen the video (thanks for sending it) and that is what I would expect in case of disconnection. Local windows are destroyed and so their content, saved locally, is gone. Upon reconnection, only not overlapped content will be rendered and sent. This is how X applications (connected to the same X display) work and we can’t change this.

Now it would be interesting to investigate these disconnections. Client side logs can be gathered as explained in https://www.nomachine.com/DT10O00163#2. Also server side logs could be useful. To gather them now you can follow instructions in https://www.nomachine.com/AR10K00697.

[fra81]

Hi MickM,

I couldn’t reproduce with a similar setup, but probably I’m missing something. Could you send a video showing the problem?

[fra81]

You don’t see nxcodec.bin when using vp8 because the encoding, in that case, is done by the nxnode process. Generally speaking, encoding, if done in software, is a heavy operation, and I don’t see anything abnormal in your description.

[fra81]

Do you think the cpu’s server cannot handle encoding h264 and could be the reason of high cpu on on a mac client ?

This is possible if you say that the resolution is very high and given that the CPU is not very powerful. But also note that such CPU usage just means that a bit more than 2 CPU cores are used of the 8 at disposal. To limit CPU usage further, besides reducing the resolution, you can try to lower the frame rate in the Display settings panel.

[fra81]

Now hardware decoding is working, although my cpu is 135%, a little worse than with software decoding.

Normally hardware decoding offloads the CPU, but this could not happen with particular combinations of hardware and drivers. Unfortunately this is not something that our software can have control over.

[fra81]

Thanks for info!

Finally we reproduced something similar between two Macs in our labs. I’ll let you know the results of investigations.

About color spaces you are right, but NoMachine dealt already with this problem (see https://www.nomachine.com/FR03M02907).

[fra81]

Thanks for info. Indeed you would have to export those devices explicitly in order to trigger that problem.

Would you mind to try one more thing? In https://www.nomachine.com/AR03P00973 you can find a couple of methods to turn off the local X server on Ubuntu. In this case NoMachine will then use its own virtual frame buffer and we would be able to exclude or narrow down this issue to drivers on server side. And if possible, it would be nice to check the CPU usage of the server while reproducing the issue.

[fra81]

Hi,

this is very strange. Logs look clean and we can’t reproduce anything similar on various Windows Servers in our labs. Though another user experienced a similar problem: could you check if the workaround here makes any difference for you?

[fra81]

A small clarification to what Britgirl wrote – obviously we handle multi-touch events such as the ‘traditional’ two-finger swipe or pinch-to-zoom in our iOS and Android apps, and we will add support for them on Windows tablets soon.

[Author]

Posts