fra81

[fra81]

Hi,

if you are connecting to the “physical” display of your Ubuntu machine, it is a matter of configuring your X.org server. For example in this link you can find a few hints on how to add virtual monitors: https://askubuntu.com/questions/453109/add-fake-display-when-no-monitor-is-plugged-in. For example I tested myself successfully the configuration with the Intel driver (VirtualHeads option).

If you are using one of the NoMachine products providing virtual desktops, the implementation of this Feature Request should address your case: https://www.nomachine.com/FR12K02799.

[fra81]

Hi!

I start to say that this is strange. Given that server and client should settle, more or less, for a frame rate of 30 fps by default, added lag should be no more than 1000/30, that is 33 ms.
Please check the Display settings panel in the session menu. What value frame rate is set to?
And can you describe exactly how you are measuring such input lag? What procedure, what measurement method?

That said, are you connecting to the physical display of the server? Is it a headless machine? I would also check cpu usage on both client and server side.

[fra81]

Hello,

please gather logs from the server as explained in https://www.nomachine.com/AR10K00697. If possible, also client side logs could be useful. Instructions here: https://www.nomachine.com/DT10O00163#2. You can send everything to forum[at]nomachine[dot]com.

In the meanwhile you could try to uncheck the ‘Use acceleration for display processing’ option in Server preferences -> Performance tab.

[fra81]

Hi,

in order to detect what is the bottleneck, network or hardware resources, for a start I would:

– check CPU usage on both client and server side;

– gather NoMachine session statistics as shown in https://www.nomachine.com/DT10O00157&dn=session%20menu#9.

 

Please also make sure you are using H.264 encoding. More info in this article:

What do I need to do to allow NoMachine software to use H.264?
https://www.nomachine.com/AR10K00706

[fra81]

Hi,

indeed it is a very strange issue!

Please try checking the ‘Disable client side image post-processing’ option in the session menu and send us a screenshot if possible.

[fra81]

Hello,

thanks for the logs. It seems your desktop is now using the Wayland compositor. It’s not clear whether, before using the new NVidia drivers, the old desktop was doing so. We are definitely trying to reproduce the problem in our labs, so that we can work on this Wayland issue. In the meanwhile, can you try to disable Wayland and check again? Just to see if it is Wayland-specific or a more general problem with this NVidia driver.

To disable Wayland:

– set WaylandEnable=false in /etc/gdm3/custom.conf;

– run systemctl restart gdm3

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

[fra81]

Hi Mick,

unfortunately we weren’t able to reproduce this issue even with Virtuoso. Can you please provide more info:

– What is Cadence Virtuoso version?

– Do you have NoMachine version 6.3.6 on both sides?

– Do you have the possibility to verify if the issue is reproducible when connecting from a different OS than Mac?

– Does the issue occur also in a NoMachine virtual desktop?

– Does the issue occur when opening a specific dialog or with any dialog?

– If the issue occurs with a specific dialog or a specific sequence of actions, can you provide step-by-step instructions?

– It would be nice to have a longer video that would show all the steps.

[fra81]

Hi,

please send us NoMachine log files and X.org configuration:

sudo tar zcf NoMachine.log.tar.gz /usr/NX/var/log

sudo tar zcf Xorg.log.tar.gz /var/log/Xorg.*

sudo tar zcf xorg.conf.tar.gz /etc/X11/xorg.*

And your graphics card model:

sudo lshw -C display

You can send the files to forum[at]nomachine[dot]com.

[fra81]

That should already happen, unless you hit a bug or some corner case. What I had supposed is that those windows were originally rendered with “vector graphics” and then compressed as an image upon reconnection (as it can be necessary due to the stateless nature of X11 protocol). And that would be the reason why you see a difference. Can you send a screenshot of the NoMachine window showing the issue and of your Display settings?

[fra81]

Hi!

1. The AVC pack will help for sure.

2. NoMachine will adapt automatically to network conditions to achieve best performance possible. Just use the Display quality slider (that you can see in the session menu – Display settings tab) to find the best trade-off between quality and speed that works for you. You can leave other settings to the defaults. Consider that of course also screen resolution will affect used bandwidth.

[fra81]

Hi,

keyboard layout is reset at reconnection accordingly to the client side layout. However NoMachine offers the possibility to run custom scripts that will be triggered on specific events, so you can add your xmodmap command to the UserScriptAfterSessionReconnect script in /usr/NX/node.cfg. You can find more info in https://www.nomachine.com/DT04O00139#11.6 and some examples in https://www.nomachine.com/AR02L00787.

Regarding pixelation and colors issue at reconnection, what you see is probably the effect of jpeg compression. If I understand correctly, you’re running custom sessions in floating window mode that use the ‘X11 vector graphics mode’. Being X11 protocol stateless, it may happen that at reconnection windows are redrawn using compressed image instead of vector graphics. Increasing display quality could be enough, or you can try to set a lossless compression method. For example, edit /usr/NX/etc/node.cfg by adding this line:

ProxyExtraOptions pack=16m-png

[fra81]

As for your second question, H.264 will be supported soon also on iOS devices:

https://www.nomachine.com/FR12M02992

One thing you could try is checking “Disable client side image post-processing” (https://www.nomachine.com/it/DT10O00157#5.7). You may also attach session statistics here for inspection (https://www.nomachine.com/it/DT10O00157#9).

[fra81]

It doesn’t depend on NoMachine. The same problem can be found when connecting from any remote access tool. You can see other users with the same issue here:

https://serverfault.com/questions/815775/google-compute-engine-vm-display-driver
https://serverfault.com/questions/817910/installing-a-virtual-graphics-adapter-on-a-windows-server
https://productforums.google.com/forum/#!msg/chrome/IPZFTPihzWA/ZEzq0ZWeBwAJ

The fact is that without a display adapter, no rendering can even happen on the server. The exception is RDP, but only because it creates a virtual session – it doesn’t connect to the physical display.

However, it seems that now Google Cloud makes available instances with a GPU (at least in beta, as far as I can see). You may want to check that here: https://cloud.google.com/gpu/.

[fra81]

Thank you for all the info!

Naturally file transfer bandwidth has to be limited in a way that it doesn’t slow down the streaming of the session, but definitely what you describe doesn’t look as the correct behaviour. We will test your setup deeply in our labs.

[fra81]

You’re welcome!

Maybe NoMachine could display the frames information in the stream window, in one of the corners, as an option (printing it in real time).

That’s a great idea and it is present in the Feature Request we opened:

https://www.nomachine.com/FR09P03680

The file transfers between these computers reached 100mb/s through Windows, but when using NoMachine, the file transfer ranged from 300kb/s to 3mb/s

Do you confirm that you are referring to NoMachine’s file transfer service (that wouldn’t use all the available bandwidth)? Or you mean instead the streaming of the NoMachine session?

So, it could be a client-side option between showing “black margins” (simulating the 4:3 resolution on the server-side) or leaving the image stretched.

1:1 mode should be the default! Please check in the Display panel in the session menu that ‘Fit to window’ is not selected. You can also use the quick icons at the bottom of the menu to switch between display modes.

[Author]

Posts