- This topic has 9 replies, 4 voices, and was last updated 10 years, 5 months ago by
.
-
Posts
-
We just installed CentOS 5.10 x86_64 on a 4-core server and decided to try Nomachine 4.0.
We downloaded and installed the Linux RPM.
And we downloaded and installed the Windows 7 (64-bit OS) client.
When we establish a connection from Windows 7 to CentOS 5.10, the I/O over the gigabit local area network is painfully slow. To enter the user ID, for example, we type one letter at a time, wait 1-2 seconds, type the next letter, and so on. Some characters auto-repeat a couple of times so we have to delete those one-by-one and try again.
When the system finally logs in (KDE Desktop), all GUI operations are quite slow as well.
In the past we used NX 3.5.0.x on similar systems without any such performance problem.
What’s happening with version 4???
Good try. With a couple of hundred thousand 4 installs already around and more of 70% of customers who already upgraded from the old 3 we didn’t receive a single complain about performance. You are the first. So there must be something wrong with your install, or on that specific machine, or on your network. But, to be honest, I have some difficulties to believe.
If you know how to do, run the session for a couple of minutes, then locate the nxnode.bin process running the session. It shouldn’t be difficult. Considering the poor performance you are experiencing I suppose it must be very high on top. Do a kill -USR1 of the pid, then make a zip on the .nx directory in %HOME% on the client and a tar.gz of /usr/NX/var and of the .nx directory of the desktop user on the server. Send to our support. You can also display the statistics in the player. Open the panel -> Connection -> Take the statistics. I’m curious to see what is it.
For every problem there is a first reporter. Whether you have 100 or 1 million other successful installations is irrelevant.
There are 2 attachments here:
1. Screenshot of “top”
2. Connection –> Take the Statistics report.It looks like Xorg process is pegged at 93+% CPU.
I am sending these and zip/tar files to your Tech Support.
Attachments:
What makes you think it is a NoMachine bug?
It looks like Xorg process is pegged at 93+% CPU.
Not only that. I see nxnode.bin at 0.7% and nothing else running. I suggest you send an email to the CentOS people or Red Hat. I’d tend to exclude it’s NoMachine.
For the record: it seems that you are running a “remote desktop” session, not even a “virtual desktop”. So your KDE desktop runs in Xorg, not in nxnode. In other words X clients are connected to Xorg. What NoMachine does for “remote desktops” is just querying the content of the top-level windows on a interval (in your case, probably 25 times a second). I have never seen a Xorg instance taking more than 5% of the CPU to return 25 XShmGetImage() per second, even on HW of 10 years ago (that we keep here for testing). Even if you had disabled the X-SHM extension in Xorg.conf (that would have been deliberate), load should have distributed 50%-50% between Xorg and nxnode. Yes, it looks like a Xorg or KDE bug. I’ve also seen Pulseaudio causing this kind of behavior. I hope for you it can be solved with an upgrade.
Hi,
I experienced the same performance issues when connecting to a physical desktop on the local network (using TerminalServer eval, v4.0.366-2 ). This is between 2 machines running Ubuntu 12.04.
My case is similar to the original post in that X is pegged near 100% on the server when connected remotely. The server in on a gigabit link, has 24 cores and 32Gb of memory.
User input is painfully slow as described in the original post.
Is this typical for a connection to a physical desktop?
Should I expect significant improvement if running a virtual session connection?
Thanks!
We are running KDE on CentOS 5.10 and virtual desktops are enabled by default. But we still face this problem in which the screen contents seem to be sampled every Nth of a second as a bitmap and sent over the network to the client (viewer). At least that is my interpretation of titan’s post. We have not solved this problem yet and have moved on to other things. It seems we need a paid subscription to send data to Nomachine tech support so we haven’t followed up. If you are able to find the time to resolve this via some configuration change on your server, please post the solution. I may delegate this problem to one of our resident Linux experts soon.
The free version doesn’t appear to support virtual sessions in version 4.x, only physical desktop connections, which throws X11 into a tizzy, resulting in poor performance. I’m not sure if this is normal behavior as I’m new to NX, but this was a pretty bad first impression.
I’ve installed the TerminalServer eval and this allows virtual sessions, bypassing X11. The performance with this is quite good.
As I said already, this is a X bug. It may be interesting to investigate, but I don’t think it has specifically to do with NoMachine. NoMachine performance with physical desktop sessions are at least as good as with virtual desktop sessions. They are often better, given that the physical desktop sessions are normally HW accelerated, while HW acceleration in VD is more limited, given the lack of “virtualization” capabilities in current GPU drivers.
Please provide all the information that can be useful to dig into this. Xorg version, desktop environment version, graphics card model, GPU driver and specific version.
BTW, did you try updating to the latest version of Xorg?
It seems we need a paid subscription to send data to NoMachine tech support so we haven’t followed up.
That’s obviously the norm. Except in the case data can be useful to solve a bug of general interest, like in this case.
I renamed the topic since it was unrelated to the actual problem. The new name describes the problem better.
Please people also provide the requested info so that we can chek if further investigation is required. This topic is hanging around since weeks. If this is not a NoMachine problem I think it’s time to close it.
Closed because the user did not provide further feedback. Please notify us if you confirm that it is resolved or open a new topic if you have the same problem.