graywolf

[graywolf]

Hello zinv,

please try to switch on/off UDP transport in the advanced settings of a saved session and tell us if something changed.

 

Please follow these instructions to gather server and client log data of a troublesome case, then send them to forum (at) nomachine (dot) com for further analysis.

 

 

• This reply was modified 7 years, 9 months ago by graywolf.

Attachments:

1. 

   udp.png
   

[graywolf]

Hello ogm94,

thanks for reporting this.

If I understand:

1. you and your colleague updated two different servers to NoMachine 5.2
2. he didn’t got any problem with his server
3. you experience the lag with your colleauge’s server as well as with yours

Can you confirm?

Could you provide information about the NoMachine products installed on the servers (Free Edition, Workstation, etc.)?

The information about OpenGL applications let me think you used to work with “virtual desktops” in version 3.5 while you share the physical display of the server in version 5.2. Is that the case?

[graywolf]

Let me try to put all the pieces together.

Complaints are about response times when sharing the screen of a Linux system (specifically SLES11 SP3 x86_64 with GNOME)
and Xorg process using a relevant share of CPU time.

The issue is reported across different hardware:
NVIDIA card with proprietary driver and multiple screen attached
VMware Player
HP server

The problem doesn’t affect NVIDIA with a single screen.
For the HP server the problem affects the mga driver for Matrox card.
We didn’t got more information about VMware Player.

I’d like to have a unique solution for this kind of issue. Nevertheless, it depends
very much on things over which we have limited control, like: device-dependent code in Xorg,
video drivers, and video card capabilities.

So that, it looks quite appropriate searching for different techniques of capturing the output of
a video card. A such work is currently in progress. More details are provided in this Feature Request:
https://www.nomachine.com/FR05O03416

[graywolf]

Assuming that Windows XP could be affected, the cons would overweigh the pros anyway: see point 4 above.

[graywolf]

Hello.

I’m not able to reproduce using LibreOffice package 1:5.1.6~rc2-0ubuntu1-xenial2 that looks the latest version available on repository.

Your version is newer. Did you enable the -proposed repository?

[graywolf]

Hello.

What you asked is not possible at the moment but we’re evaluating such a feature: see FR10M02977. Check the box in that page to be notified about updates.

[graywolf]

Hello Andreeeeee,

I guess you got this problem in sessions of kind “virtual desktop”.

It could be due to the font path not completely set up in the NoMachine virtual display server.

To check the current font path, run a terminal emulator in the virtual desktop and type the command xset q.

In order to temporarily append elements to the font path, use the command xset fp+ <new element>, e.g. xset fp+ /usr/share/X11/fonts/misc.

If you find the missing paths and they fix the issue, you can set up the default font path to the value you need using key DisplayServerExtraOptions in node.cfg, e.g.
DisplayServerExtraOptions "-fp /usr/share/X11/fonts/encodings:/usr/share/X11/fonts/encodings/large:/usr/share/X11/fonts/misc:/usr/share/X11/fonts/Type1:/usr/share/X11/fonts/util"

[graywolf]

Thanks to the continuous improvement we have being introducing into the software since the release of version 4 we don’t expect any loss in performance – compared to what you could get using a mirror driver – even with the few Windows operating systems that might still use it.

[graywolf]

fermulator, we don’t mean to replace the mirror driver with anything, it’ll be just removed.

Could you detail the question? Which functionality are you referring to?

[graywolf]

Check the font path with command xset q.

You can change the font path with command xset fp= <comma separated set of strings> (notice the blank after “=”). Suitable directories to be added are usually located at /usr/share/X11/fonts and /usr/share/fonts, e.g.:

xset fp= /usr/share/fonts/default/ghostscript/,/usr/share/fonts/default/Type1/,/usr/share/fonts/liberation/,built-ins

(Warning: any invalid item would make the whole command fail).

“built-ins” fonts aren’t in any directory, they stay in the display server itself.

To start with the needed font path already set, consider editing of /usr/NX/etc/node.cfg in this way:

DisplayServerExtraOptions "-fp /usr/share/fonts/default/ghostscript/,/usr/share/fonts/default/Type1/,/usr/share/fonts/liberation/,built-ins"

[graywolf]

That feature is planned to be implemented (FR12K02799), but at this moment is not available.

[graywolf]

Do you mean in a terminal in the remote desktop? It depends on the terminal application. And in case of Linux applications you can paste the selected text just with middle-click.

[graywolf]

Hello, server log is missing. if you prefer you can send it to forum (at) nomachine (dot) com.

[graywolf]

It appears the “service gdm stop” command is not available on Red Hat Enterprise Linux 6, please advise, thanks.

You’re right, sorry. Try this: init 3
to switch to runlevel 3.

Edit /etc/inittab if you want to make runlevel 3 the default.

[graywolf]

I’m suspecting the server had gdm turned off. In that case NoMachine launches its own virtual display that is able to resize to any resolution.

So I suggest try to turn off gdm (service gdm stop) and restart NoMachine (/usr/NX/bin/nxserver --restart).

[Author]

Posts