November 30, 2020 at 09:21 #30548MisterMoonlightParticipant
This is a following of this interesting post now closed since it looks similar:
I am new to NoMachine. But experienced Linux/Windows users. I have experiment with the free version at home to see how good it is. The server/client are recent free version:
Windows 10 64 bits client: NoMachine 6.12.3_7 (i7 10700)
Linux mint 19.3 64 bits server: NoMachine 6.12.3_7_amd64 (core 2 duo 3Ghz) resolution used 1152X864 using ati radeon 4350 and analog vga monitor.
First impression on local lan used only: I can say that i am very impressed with the result of the performance (for remote control of the Linux server) when everything is installed and configured correctly. My Windows client can control the Linux system quickly on 100Mbits lan and i tested at 1gig speed that i can even run multimedia software remotely (even listening to a dvd playing remotely) with great performance and limited noticeable performance on the server.
Ok now are the bad points. I think that the way this product is advertized and supported, the support web pages are highly confusing and make it very difficult to understand and to use/configure it. Just looking at the web support forum, there are so many pages and confusion between the versions and what could be used, and to which software a specific information could be used make it very hard to setup and understand. And I am an experience technical senior. As an example, it was so hard to understand what to do to make a shortcut to start the connection with the server without the screen having to being resized everytime. Almost all the display settings option and mode are not doing anything in the free version (only full screen and window mode in my case). If i was to spread in company use in a large scale, i am not sure i would deal with it. I think this is not the fault of the tecno that seems very good, but everything around it which needs a lot of improvement. Design changes, better QA and redesign of the web support.
Here is another example of the problem encountered that was not expected at all. Once everything was setup correctly and perfectly stable, i made a simple assumption that appear to be wrong: because the system as a shared monitor (with a permanent video adapter) and i expected to use NoMachine to control it without a monitor permanently attached, i disconnected the monitor (without changing anything to the software setup) and NoMachine began to be completely unusable! Important lag (5 secs?) between keyboard press on my client, between mouse click now are happening on a setup that was completely efficient before! It took me around a whole day to understand the problem and find a solution and NoMachine software was no help in this process (no error displayed, no indication that something is wrong). It appears that just connecting the monitor and rebooting the system repairs the problem. NoMachine is running without a monitor with a resolution on the physical adapter of 1024X768 (lower that the one i used above when the system is booted with a monitor plugged in!). So after searching multiple post and idea on the forum, i finally plugged my monitor and get the xrandr and cvt tool in Linux to extract all the monitor supported modes when it is connected, and fake with a script at login to artificially create these monitor modes on the radeon 4350 video adapter with the xrandr tool then force the same 1152×864 video mode to the vga adapter even if the monitor is not connected. Magically NoMachine started to work as good with or without a monitor plugged now.
Where i think the software fails in this specific case is that it should have done it by itself, or at least clearly warns me some hint to correct that situation (as i understand it is may be difficult to solve from all differents systems) instead of making me loose a full day on efforts to solve this. The are probably bugs under the hood here, but i still don’t know yet the solution to fully confirm this. But i guess running a remote server without a monitor is probably a use case to be often expected.December 1, 2020 at 12:17 #30593graywolfModerator
NoMachine is designed to work with headless servers and works well with the majority of set-ups.
There are some cases where screen sharing of the physical display of headless servers poses problems (mainly on Linux) and these are problems that we share with many other remote desktop solutions out there as searching the internet will show.
On Linux in particular, these are the most common results of headless screen sharing:
1. It works out-of-the box
2. It works fine, but may be stuck to a fixed screen resolution
3. It works but there may be performance issues and badly rendered objects
4. It does not work at all: nothing displayed
5. X does not start because “no screens is found”
In the last case (5), NoMachine is able to automatically detect this situation and runs its own virtual display. Problem solved.
For cases 2-4, we cannot say when and why it will happen in advance because it can depend on one or a combination of the following:
1. The GPU model
2. The software driver
3. The operating system
4. The programs using the GPU for rendering
It is reasonable to think that GPUs are designed to go into a kind of low performance mode when they have no output to display.
Based on what we know, people handle such problems in a few different ways:
1. Setup Xorg for working in headless mode:
1.a. AllowEmptyInitialConfiguration (NVIDIA proprietary driver only)
1.b. Xorg dummy driver
1.c Create fake EDID and use it in Xorg.conf (Extended Display Identification Data are stored in the monitor and read out by the GPU when monitor is connected)
2. Use a virtual framebuffer X (like NoMachine virtual display)
3. Use a fake display plug.
Regarding point 3, it generally works because with the plug attached, the GPU performs as if there were a real screen attached to it. Hence this is what we suggest and the topics in this forum are testament to that. A viable alternative is to install NoMachine Workstation for Linux and neither of the steps 1-3 above will be necessary.December 1, 2020 at 15:56 #30596BritgirlKeymaster
Regarding your comments about our online knowledge base, we are already working on improving this by removing/moving documentation which can now be considered irrelevant (such as articles etc about our legacy products 3.5 and version 4). In an ideal world there wouldn’t be any need for support 🙂 but that proves to be a an impossible feat even for providers of operating systems, let alone for the ISV’s that make the programmes to run on them. All the more reason to make sure help resources are easy to find. In any case, we appreciate the feedback you’ve provided because it gives us some extremely useful insight into what users of our software are experiencing, so thank you!
Look out for version 7, coming soon, which will provide a streamlined UI, making navigation of the player and server components as well as connection creation/configuration much simpler.December 2, 2020 at 09:20 #30602MisterMoonlightParticipant
At some point I was saying myself that this post could have been filtered out because of the negative aspect of it. I spent some time to wrote it trying to figure out honestly the goods and the bads. I am happy it was not filtered. Another good point for you guys.
Hope the UI and user experience will improve in the next version. Continue the good work.
Regarding point 3, it generally works because with the plug attached, the GPU performs as if there were a real screen attached to it.
In my case, the asus 4350 graphic radeon card does not need to have a fake plug on the connector at all (as i don’t have such a dummy plug), so the solution is purely software: just configuring an forcing the same real monitor mode that is in use when the monitor is plugged and it works perfectly 100% all the time (like if the monitor was connected), with no other hardware involve, no monitor plugged at all. So i guess the software could have detected that no monitor at all was configured in my setup and react in some way…December 9, 2020 at 09:52 #30701BritgirlKeymaster
So your solution is to adopt Graywolf’s suggestion in 1c 🙂
the software could have detected that no monitor at all was configured in my setup and react in some way
It’s a bit difficult to predict that it won’t work even if there is no monitor detected (the combination of GPU model, the software driver, the OS etc). The answer is to force the set-up to use our virtual display even when it might not be necessary, that’s not what all users want.
This topic was marked as solved, you can't post.