Forum / NoMachine for Linux / Xorg high CPU utilization, Matrox bug
- This topic has 11 replies, 4 voices, and was last updated 9 years, 1 month ago by fra81.
-
AuthorPosts
-
November 2, 2015 at 10:01 #8894ericbParticipant
Hello,
I’m stumped on an interaction between NoMachine and Xorg. As soon as I connect a NoMachine client to my server the Xorg CPU percentage goes to 90 to 100% and stays their as long as the client is connected. This high CPU utilization makes both the direct attached GUI and the NoMachine remote GUI almost unusable. If I use X11 remotely there is no issue.
I’m guessing this has something to do with hardware drivers, but, from what I read NoMachine doesn’t use the graphics card on the server side so I’m not sure what to look for. Any suggestions on how to debug this are greatly appreciated.
- OS: Ubuntu 14.04.3 LTS
- NoMachine Server and Client: 5.0.47
- Xorg: 1.17.1
Eric
November 2, 2015 at 10:59 #8918fra81ModeratorHello Eric,
this actually looks like a problem with your drivers. What NoMachine does is querying the screen content few times per second. This is not a high work load and the X servers normally handles it without any problem on the widest range of systems we tested.
Can you provide more info on your graphics card and the drivers? Is it possible to upgrade the drivers?
November 4, 2015 at 12:17 #8936ericbParticipantSorry for the late reply fra81, I didn’t receive an email notifying someone had replied to this thread.
Based on your suggestion I investigated my graphics driver setup and it seems that I don’t have a driver for my card. And, although the issue has been reported to Ubuntu and there has been quite a bit of discussion there doesn’t appear to be any agreement on a solution. One suggestion was to install xserver-xorg-video-vesa, but, due to dependencies issues it will not install on Ubuntu 14.04.
https://bugs.dogfood.paddev.net/ubuntu/+source/xorg-server/+bug/1316035
*-display UNCLAIMED
description: VGA compatible controller
product: G200eR2
vendor: Matrox Electronics Systems Ltd.
physical id: 0
bus info: pci@0000:09:00.0
version: 01
width: 32 bits
clock: 33MHz
capabilities: pm vga_controller bus_master cap_list
configuration: latency=64 maxlatency=32 mingnt=16
resources: memory:90000000-90ffffff memory:91800000-91803fff memory:91000000-917fffff
I’m not sure what to try next.
Eric
November 5, 2015 at 13:45 #8978fra81ModeratorI am sorry to say that this is an issue which needs fixing in Ubuntu (and the xorg version they are using) and is out of own hands unfortunately.
November 10, 2015 at 14:45 #9032kbbParticipantI’m having this same issue of high Xorg load when connecting to a CentOS6 with ATI Radeon HD 7770 graphics card. Are there an known issues here?
OS: CentOS 6.7
NoMachine: 5.0.47
XOrg: 1.15
November 10, 2015 at 14:50 #9041BritgirlKeymasterSimilarly to what was suggested above you could try updating the driver.
November 11, 2015 at 11:08 #9044kbbParticipantI am using the most up to date Xorg driver supported by CentOS6. Are there any known issues there?
Alternatively, is there a recommended video card for use with CentOS6 and NX?
November 11, 2015 at 12:52 #9049fra81ModeratorI am not aware of any problem with Radeon or Nvidia cards (for example we tested CentOS 6 with Radeon HD 6570).
You may try to install proprietary drivers from AMD (or remove them if you already did).
November 11, 2015 at 13:17 #9043ericbParticipantkbb, I haven’t found a solution yet. I’m not fully convinced that this is entirely an Xorg issue since the only thing that seems to cause the problem is NoMachine. It seems to me if these were simply an Xorg bug other configurations would trigger the problem. But, in my experience both the direct attached display and remote X11 work just fine.
Eric
November 11, 2015 at 18:20 #9060fra81ModeratorYou could say that this X.org bug is triggered by NoMachine, but only in the sense that the applications you mention usually perform drawing operations to the X server (in this case data is sent to video buffer) and very rarely ask for the screen content back (in this case data is received from video buffer).
NoMachine already makes sure of performing the minimum amount of operations to get the screen content, and this has been proven to not significantly overload the X server in the great majority of systems.
November 16, 2015 at 09:24 #9088ericbParticipantI’ve found a workaround for the issue, but, it won’t work for everyone. I installed an old PCI graphics card in my Dell PowerEdge R630 and did a complete reinstall of Ubuntu 14.04. Before the reinstall I did try adding drivers for the card, but, that caused X to crash on launch. The only other thing I had to do was to disable the integrated VGA graphics in to BIOS.
Thank you all for your help.
Eric
November 16, 2015 at 11:50 #9103fra81ModeratorHi Eric,
I’m happy that you found a way around the problem. Be aware that this case was already investigated in the past. We tested all methods (at least 5) provided by X for getting the screen content, but none of them demonstrated to be any faster than the method currently used by NoMachine.
That said, we are already working on a totally new method for screen capture that won’t require any interaction with the X server and that should solve that kind of slowness. It is currently in testing phase and it will be included in one of the next releases. It should be noted anyway that pulling data from the GPU shouldn’t be so slow, and this can’t be considered in any way a NoMachine bug.
-
AuthorPosts
This topic was marked as solved, you can't post.