Forum Replies Created
-
Posts
-
Hi.
Please try to add the following line to the ‘/usr/NX/etc/node.cfg’ file on the server:
DisplayAgentExtraOptions “-legacydpy”
Create a new session and let us know if that makes any difference.
Hi.
Yes, we checked them, sorry for the delay in getting back to you.
We couldn’t see anything abnormal. We can confirm that the CPU usage is mostly due to the encoder. We are speaking of more than 50 ms to encode a frame, which seems to explain that CPU usage. This result is consistent with what we observe with very large virtual screens as you have (4480×1440 from your logs).
As I said in a previous post, you can improve the CPU usage by enabling the H.264 encoding:
https://www.nomachine.com/AR10K00706
https://www.nomachine.com/AR10K00695Hi,
we reproduced this problem in our labs. You can track the issue here: https://www.nomachine.com/TR03N06663. A fix should be made available with the next update.
Thanks for reporting 😉
Are you using NoMachine free and connecting to the Physical display of your Ubuntu machine? Can you send a screenshot of your Display settings panel while using the session (Ctrl+Alt+0 to open menu -> Display -> Change settings)?
I would start narrowing down by checking if this is a issue with CPU or bandwidth. Please check the CPU usage on both client and server machines during the session, and verify the link speed of your networks.
Sorry but I’m a bit confused now. What do you mean with ‘physical display session’? In your previous post you were saying that the option solved the problem when connecting to the Physical display.
Anyway, from the message that you copied, this seems a different problem. We would need the server side logs to tell what is wrong. You can find instructions on how to gather them here: https://www.nomachine.com/DT07M00098. You can send them to forum[at]nomachine[dot]com by referencing the title of this topic.
Can you attach a screenshot showing the problem? Also a screenshot of the ‘Display settings’ panel of the menu could be useful.
Hi kumar,
we were not able to reproduce any problem with R and the plot command in our labs. Please provide step by step instructions on how we can try to replicate it: the link to the exact R version that we need to install, how to start it, and the exact command that we can use for reproducing.
Also further info on your environment could be useful:
– NoMachine version installed on client machine.
– Remote and local Windows/Mac/Linux version (Windows XP/7/8, OS X 10.x, Ubuntu xyz, Mint x.y, etc.).
– If on Linux, desktop version (GNOME. KDE, whatever) on client and on server.Hi,
that option won’t cause any increase in bandwidth usage. NoMachine does most of the work and uses the Damage events reported by the system only as hints.
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.
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”
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.
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
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 😉
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.
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.