Forum Replies Created
-
Posts
-
@protoclown: if your server is Linux, what you can do is put in a /usr/bin/xterm in Xsession right before your desired desktop appears. That’s a great debugging tool to see what’s happening if you just get the “black screen”. You can then use the xterm window to run the desktop on the command line and watch what’s happening.
I’d be curious to see if your performance got better if you lower the resolution of the Chromebook.
I would be interested in hearing more about this issue. These are virtual Linux sessions? How many nodes are you running? Are you using the Terminal Server as a node as well or just a broker for the nodes? Your terminal server being the broker receives all network traffic from the nodes and then routes it out from one interface. I have 310 users logged in right now, and it’s running around 100Mb with a peak of 240Mb. Scaling that up by a factor of 4, you might be hitting a bottleneck here if you have a 1Gb connector or infrastructure.
Use iftop to watch the traffic from and to the nodes and then the total. If your terminal server is a node, consider turning that off and making it just be the broker. There might be some ways to use heartbeat feature to increase capacities too.
Also something to consider is that when people log into a server first thing in the morning, they do so because they need to use the computer immediately. So you might have a high number of people opening browsers initially, and then slowly through the day their usage drops.
We have been testing Chromebooks heavily with success. We have found that the speed of the NX client is greatly influenced by the resolution of the screen. HD (1920×1080) is fast and responsive. But when the resolution goes higher, the client gets slow. Plugging in an external monitor at 3440×1440 runs about at 1/2 speed of HD. You can type much faster than it can render the keystrokes.
We also received a tip from support that helped with this:
node.cfg:DisplayServerExtraOptions “-novideo”
Seems to have improved speed, especially on higher resolution monitors.
If the videos are trying to play in lightweight mode, it won’t work. What you see is the first few frames will paint and the sound will get choppy and then the whole thing will eventually stop playing.
FR12K02799 is a big help and very close to solving our needs. In our use case, the NX client runs over two monitors…yet still has a window manager and therefore does not consume the entire screen. It’s consuming about 95% of the screen, and this allows the users to have a bit of exposure to a task panel and to be able to click into other applications.
Many dialogs open right in the gap of the monitors and when you log in the account/password is typed partially on both monitors.
We’d love for NX to see this as two monitors and center things assuming the mid point is the gap between the monitors. For instance, two monitors at 1440×900 would be 2880×900. NX client would then be about 2800×850. We’d like it to treat this as two monitors each at 1400×850 in terms of dialogs and maximize buttons. It would be ok for this to be command line flags if it could not be automated.
@brandon.ess: We do not use the standard HP tools — we have found our own home brewed solutions to work far better. What you do is take a t620 and go into the admin side and assign a password to root. Then you create a custom connection to run /usr/bin/xterm which gives you the command prompt. Then you type in ‘fsunlock” to be able to change the file system. Then download the NX 4 .deb package and install using normal dpkg commands. At that point, the client runs and you can connect to the server. We run the NX client as user ‘user’, and what I do is mount a RAM file system into /home/user/.nx. The NX client sees this as hard drive space and all caching then is done at memory speeds instead of using the local flash “hard drive” which are much slower. When users pick NX, I lay a new tarball with all settings into /home/user/.nx and then activate the client. That way the users have no way to bork up the settings and everything is wiped clean with each new launch. t5725, t5745, t610 and t620 all work with this technique. The t620s are blazingly fast.
When we push updates to the HP workstations, we always use the open source software FOG. It’s far faster than the HP tools. We can do hundreds of workstations a night with FOG with no problems.
We have the NX 3.5 and NX 4.0 clients on HP thin clients. I have installed the 4.0 client on t5725, t5745, t610 and t620 (current model). The t5725s need a good amount of tuning because they are so old and only have a single core. But t5745 and higher work perfectly well. In our case, we are deploying using LightWeight mode. If you deploy using one of the codecs, you will probably need the t620.
I can confirm this issue. There are Android devices that have no touch screen. For instance, the PC For TV devices have a mouse pointer, and no way to touch the screen with your fingers. The NoMachine client runs perfectly on these devices, but the mouse pointer does not work for dragging windows and you cannot expose the corner activation feature.
Interestingly, it appears that if you have a blue tooth keyboard connected to an iPad , you can hold the backspace key down and it repeats.
You can do this with the undocumented –exit command line flag. It will then drop back to the parent shell and not return the NX UI screen.
nxplayer –help does not show this flag, but it works and seems to be around from the 3.5 days.
@sservice It looks to me like the theme isn’t loading quite right, so maybe it’s having a theme/font type problem. Possibly it’s looking for a certain font and when it’s missing it’s just silently failing. Some applications are only tested local from the system console, and need a bit of tweaking. The technique that I use in this case is to put in a few lines of debugging information in the script that calls this application and compare NX 3 vs NX 4. In this case I would check for fonts and for environmental variables. So, something like:
echo “DEBUG: fonts start here” > /tmp/nx4.log
xlsfonts | sort >> /tmp/nx4.log
echo “DEBUG: environmental variables here” >> /tmp/nx4.log
env | sort >> /tmp/nx4.log
Then just diff the two files.
@Zaq,
Sent you a node.cfg file which has been upgrade many times with patches. You can see the file has gotten bigger and has dupes. What might work is the approach of reading in all the keys and then generating a fresh/clean file which does not try and merge into an existing file. As long as there is always a backup, that approach seems like it would keep the file clean.
The above list is a good amount of work for me on each upgrade. We don’t want clients to have printer or SMB support and we only allow them to use GNOME. These types of things would be the reason I would never enable automatic updates. It seems great to reload the keys with paths and features, but the actual concept of enabling them seems like not the right approach on an upgrade. I do understand that you are trying to find the balance between plug-and-play and power users that have made customizations.
For sure, rpm -U does wipe and change information from the .cfg files. I have to hand check them on each upgrade to ensure it’s all right. We have a high number of things “locked down” and it seems like the testing is done with more permissive settings so it’s not seen. Off the top of my head, I know that:
AvailableSessionTypes unix-gnome
Gets wiped with each upgrade and goes back to
AvailableSessionTypes physical-desktop,shadow,unix-xsession-default,unix-gnome,unix-xdm
I also have found the upgrade scripts are adding duplicate entries which are commented out, and the file is getting bigger and bigger.
Confirmed this field entry is buggy on Android. What I have found is that it works if you create a new entry, but if you try and edit one that already exists, it chops off characters from the host field.
@hamel: I can’t speak to your exact license situation, but from a technical standpoint there is a way to publish a Windows app on the web. Linux support multi-user connections and has no CALs. What you could do is create user accounts on Linux, and in the Xsession file instead of running a desktop, just run a rdesktop connection back to Multi-user Windows and their software applications. Using rdesktop on Linux, you can publish a whole desktop with Start bar or just run one particular application. Rdesktop also can kick into fullscreen mode with no window manager, so it will consume the whole pane of NX.
We have many Windows applications deployed using NX on Linux in a similar manner. We purchased User CALs instead of workstation CALs, which allows users to connect from any end device and gives you more freedom.