Forum Replies Created
-
Posts
-
NoMachine will generally try to make use of the available CPU power in order to deliver the best experience with even graphical intense applications. But that 60% when idle looks indeed strange and unusual. Please let us know:
1) the exact NoMachine version that you are using;
2) if by saying ‘idle’, you mean that you are connected with NoMachine to that server but no application is updating the screen (that looks as a still image);
3) if toggling the ‘Use acceleration for display processing’ option (Server settings -> Performance tab) has any effect.
Also the logs could be useful for further investigation. If you are willing to send them to us, please find here the instructions: https://www.nomachine.com/DT07M00098#3. You can send them to forum[at]nomachine[dot]com.
In other respects, consider enabling the H.264 codec, if you didn’t do already. That will help you saving CPU power (and bandwidth). Here you can find all the relevant info: https://www.nomachine.com/AR10K00706.
Hi Cam,
running 10 concurrent sessions all running CPU-demanding, graphics-intense applications on two cores doesn’t seem very realistic, considering that each core has to be shared between 5 sessions. Regarding the performance of the single session, you can try to turn off the ‘X11 vector graphics mode’ (Server settings -> Performance tab), thus enabling the “video” mode. The video mode is specifically designed for graphics-intense desktops and applications and for multimedia content. Also, it will allow to leverage the hardware encoding capabilities provided by your Maxwell GPU. While using the video mode, I’d also check in the NoMachine player GUI if H.264 encoding is actually in use (bring up the session menu and enter Display settings, codec info is at bottom).
Hi,
can you please provide more info:
1) Is the server a headless machine?
2) If it’s not headless, are the VM consoles on the physical screen of the host?
3) Can you provide the name of the VMware product in use and its version?
4) Can you provide the version of the nvidia driver?
It seems that putty is trying to connect to the same port (4000) where the NX daemon is listening, as you can see in the following line:
ERROR! Invalid client identification ‘SSH-2.0-PUTTY
To get rid of the error, you can either change putty configuration, or change the port for the NX server, by editing the NXPort key in the’/usr/NX/etc/server.cfg’ configuration file. For example:
NXPort 4001
In order to understand the cause of these errors we need debug logs from the server side. Please uncomment and set the ‘SessionLogLevel 7’ configuration key in the ‘/usr/NX/etc/server.cfg’ file. Here you can find detailed info on how to gather logs: https://www.nomachine.com/DT07M00098.
Then reproduce the issue and send the collected logs to forum[at]nomachine[dot]com.
It’s worth noting that such functionalities are already offered by the operative system. When a user logs in, it is logged with the specific priviliges of the logged system user. For example, the operative system can provide “public” directories designated to allow the file sharing between users. Even restricting the file transfer to specific directories, we wouldn’t prevent the user from copying a readable file from a restricted directory into an allowed directory, and then proceeding with the download (e.g., copying ‘/etc/passwd’ to ‘/MyDownloadableDirectory/Notes.txt’ and then downloading Notes.txt).
In other words, we would step on the operative system’s toes, that we don’t think it is a good idea.But still, a detailed and accurate logging is absolutely necessary.
Hi Chris,
it looks like the same issue described here (fixed in version 5.1.40):
https://www.nomachine.com/TR04N06709
Upgrading the server side to the last version should solve it.
Thank you ggkekas, that is really a great point!
I was sure that we had something printed in the logs already, but I checked the software and it doesn’t seem to be the case. This is a must have feature and I don’t know actually how we could have missed it.
We opened a FR right away:
https://www.nomachine.com/FR08N03169
Please let us know if you have any more suggestions 😉
Please try the suggestion here:
https://www.nomachine.com/forums/topic/black-screen-after-updating-a-few-days-go#post-11940
It seems the same problem described in the following Trouble Report:
https://www.nomachine.com/TR11M06216
We’re going to add a reference to the Cadence application. You can check the box to be notified when it will be closed.
NoMachine is already designed to optimize the responsiveness while targeting a given quality, so all you have to do is tweaking the Quality slider in order to obtain the desired balance between quality and speed.
After further investigations, we spotted a possible problem and are working on a fix. The issue could be possibly triggered by not having XQuartz installed on your Mac. XQuartz is a prerequisite for running custom sessions in floating window mode. Is this your case? And if it is already installed, could you try to start it manually before starting the custom session?
This is not a known issue. The crash log would really help. Also the the nxplayer’s logs could help (‘/Users/<name>/.nx/R-*’ directory).
X2go and Thinlinc clients and servers are able to discover and set screen resolutions correctly. Why is NoMachine unable to do this?
You are probably talking about different types of products. NoMachine free is for sharing the physical desktop, and possible resolutions are the ones made available by the hardware. Of course there is no limitation on screen resolutions if we talk of virtual sessions, that are supported by the NoMachine Workstation and the Enterprise products.