fra81

[fra81]

Hi Gurguff,

we checked the logs and they don’t seem to point to any bug in the software. The disconnections seem to actually happen because of some problem in your network.

[fra81]

Looking at the statistics it’s easy to verify that NX5 does a better job than NX3, assuming the application is producing the same X11 output. But this doesn’t exclude that two different applications, or even two different versions of the same application, can produce different X11 output, causing, in the end, inferior performance.

A suggestion I can give is to try to disable the Composite extension. This may hint Firefox to draw using different strategies. Just a hint, since I can’t give you any guarantee that this will actually improve the performance. To do that, add the following line to the ‘/usr/NX/etc/node.cfg’:

DisplayAgentExtraOptions “-extension Composite”

[fra81]

Yes, but according to my analysis of the output, those X11 primitives are, by a vast majority, orders to put bitmaps somewhere on the screen. And, as we are comparing NX 5 to the old 3.5, the nxagent 5 exposes many more extensions that were not implemented in the old version. Some of these extensions are there to let applications beautify their output, something they normally achieve by producing X11 primitives that are more XPutImage and more bitmaps.

[fra81]

Hi,

the repeated keypresses are originated on your client side OS by the autorepeat feature. We are aware of the problem and we are working on a solution that can work as expected with video games while preserving, at the same time, the autorepeat functionality with other applications.

As a workaround you can disable the autorepeat on your Linux machine by typing the following command in a local terminal:

# xset r off

[fra81]

Hi snejok,

we observed a similar behaviour in our labs with the same environement. Firefox seems to actually draw by bitmaps and it is not suprising that the codec (along with the other techniques developed by NoMachine for the new display protocol) performs better in these circumstances.

However we are already working to provide the best experience in lightweight mode even with the graphics-intense drawing performed by some modern applications. In version 5.1 is already implemented https://www.nomachine.com/FR01N03003. Further optimizations will come 😉

[fra81]

Hi,

does the spinning wheel stay forever? Or does the connection recover at some point if you wait?

To understand what is going on in this case, the session logs would be more useful than the statistics. Please find here the instructions on how to gather them: https://www.nomachine.com/DT07M00098. You can send the logs to forum[at]nomachine[dot]com.

[fra81]

Hi,

we can’t reproduce any problem with the same platforms in our labs. To investigate this issue further, we would need the logs from the client and the server side. Please find the instructions here: https://www.nomachine.com/DT07M00098. You can send them to forum[at]nomachine[dot]com.

[fra81]

Hi Larry,

at the moment NoMachine only uses the NVENC capabilities on cards of the Maxwell generation. That is because NoMachine relies on some encoder features that are not fully supported in the previous Kepler generation, and that is the case of the K520 card virtualized in the G2 instance.

However we are already working on a special mode that can work with Kepler cards without glitches, and we are going to enable NVENC on such cards in the next release.

[fra81]

Is it possible that there have been other changes in you system (e.g. a bigger monitor)?

There are a few requisites to fulfill for actually enabling H.264. Here you can find the relevant info:
https://www.nomachine.com/AR10K00706
You can check the codec currently in use in the Display settings panel from the session menu.

If you are willing to test a debug package, I renew the offer to send it to you. In that case contact us to forum[at]nomachine[dot]com.

[fra81]

Please try to add the following line to the ‘/usr/NX/etc/node.cfg’ file on your server machine and restart the server (‘/usr/NX/bin/nxserver –restart’):

DisplayServerExtraOptions “-nodamage”

That should confirm if the problem is due to an incorrect event reporting from the Damage extension.

 

Here you can find the relevant info about H.264:
https://www.nomachine.com/AR10K00706

[fra81]

Can you please provide some more info:

– Are you connecting to a physical or a virtual display?

– What is the desktop evironment in use (Gnome, KDE, …)?

– A screenshot of the Display settings panel: Open the session menu -> Display -> Change settings.
Among other things, there is indicated the codec in use.

[fra81]

The attached sample doesn’t seem to indicate a faulty state, as most CPU cycles are spent on diplay encoding. We are not able to say if upgrading to El Capitan will solve the problem, since we are not able to reproduce this problem with any OS X version.

Regarding your last question, here you can find how to install from command line:
https://www.nomachine.com/AR07K00683

Let us know the result of your test. The next step would be sending you a debug package, should you be willing to test it. In that case you can contact us to forum[at]nomachine[dot]com.

Also enabling the H.264 encoding would decrease the CPU usage. You can find more info in these links:
https://www.nomachine.com/AR10K00706
https://www.nomachine.com/AR10K00695

[fra81]

The release of this feature has not been scheduled yet, but you can track it here and also decide to be notified:

https://www.nomachine.com/FR02N03010

[fra81]

Hello,

as you noted, on headless machines it should be possible to set any resolution. We are trying to reproduce your issue in our labs. We will be back to you!

[fra81]

Sure, the patch will be included in the next release! Thank you for letting us know.

You can check here to be notified when the Trouble Report will be closed:

https://www.nomachine.com/TR01N06366

[Author]

Posts