User: Password:
|
|
Subscribe / Log in / New account

Bad and complex architecture

Bad and complex architecture

Posted Jul 25, 2009 19:54 UTC (Sat) by sbergman27 (guest, #10767)
In reply to: Bad and complex architecture by nix
Parent article: Google releases Neatx NX server

"""
Even ADSL has high enough latency that raw X or
VNC are seriously painful. Modem links are utterly intolerable.
"""

Raw X actually works remarkably well over a direct modem to modem ppp connection. There the hardware compression really helps the bandwidth, and latency is nearly instantaneous. (Ping time may be 100ms, but that's just the time it takes to actually transmit 64 bytes back and forth. The real latency is almost nonexistent.) Over a modem connection through an ISP and over the internet, both VNC and X are intollerable. Raw X being worse than VNC. X's main problem is, of course, latency and not bandwidth.

I have used NX over 56k modem connections (typically 45kbps) for full desktop, fullscreen sessions, and performance is remarkably good. I sure wouldn't want to use it all day. But it's pretty serviceable. Framebuffer strategies simply cannot beat the combination of aggressive, context-aware compression and aggressive caching. To get good performace, you have to be operating at the X protocol level.

NX memory usage is also significantly better. This makes a difference if you run a lot of desktops. My largest server (server in this context meaning the machine running the actual apps) runs about 65 simultaneous Gnome sessions.


(Log in to post comments)

Bad and complex architecture

Posted Jul 25, 2009 22:42 UTC (Sat) by nix (subscriber, #2304) [Link]

As you suspected, I was indeed going via an ISP. Direct modem-to-modem is
probably much better.

Bad and complex architecture

Posted Jul 26, 2009 18:11 UTC (Sun) by astrand (guest, #4908) [Link]

""
Framebuffer strategies simply cannot beat the combination of aggressive, context-aware compression and aggressive caching. To get good performace, you have to be operating at the X protocol level.
""

Xvnc can basically operate on the X level: The Xvnc server is aware of which drawing operation is performed. For example, it can instruct the client to move an existing rectangle, rather than repaint/resend it.

Still, there are many more techniques (including caching) that could be added to VNC to enhance performance even further. Prototypes are already available.

""
NX memory usage is also significantly better. This makes a difference if you run a lot of desktops. My largest server (server in this context meaning the machine running the actual apps) runs about 65 simultaneous Gnome sessions.
""

Compared to what? As far as I know, GNOME uses the same amount of memory regardless of if the Xserver is Xvnc or the NX one. It is really GNOME and its applications that consumes the memory; not the Xserver. Not with Xvnc, at least.

Bad and complex architecture

Posted Jul 27, 2009 17:57 UTC (Mon) by sbergman27 (guest, #10767) [Link]

"""
Compared to what? As far as I know, GNOME uses the same amount of memory regardless of if the Xserver is Xvnc or the NX one. It is really GNOME and its applications that consumes the memory; not the Xserver. Not with Xvnc, at least.
"""

Compared to the RealVNC, which is what I have actual experience with in an environment in which they could be directly compared. And I think you might be surprised, in an environment with many desktop sessions running, just how low the requirements of the actual desktop are when shared memory savings are figured in. At the time that I ran the comparison, I believe we were running about 74MB per desktop user. (4096MB ram for 55 users. And yes, significant swap was used, although the actual swapping overhead was relatively low.)

I don't remember the actual numbers, but the nxagent and Xvnc processes tended to be at the top of the 'top' output when sorted by memory use. And the (res - shared) values were consistently better for nxagent than for Xvnc. NX is doing something more efficiently. I'm not sure what.

Bad and complex architecture

Posted Jul 27, 2009 19:37 UTC (Mon) by astrand (guest, #4908) [Link]

""
I don't remember the actual numbers, but the nxagent and Xvnc processes tended to be at the top of the 'top' output when sorted by memory use. And the (res - shared) values were consistently better for nxagent than for Xvnc. NX is doing something more efficiently. I'm not sure what.
""

Perhaps this is due to the fact that NX has multiple process (NX agent and NX proxy)? You'll need to count both for a valid comparison.

In any case, the Xvnc memory usage is no deal. On my Fedora 11 system, the local Xorg now consumes 63 MiB (resident), while Xvnc only consumes 34 MiB.

Bad and complex architecture

Posted Jul 30, 2009 4:34 UTC (Thu) by sbergman27 (guest, #10767) [Link]

No nxproxy. Just nxagent and nxnode, with nxnode using less than a meg of res - shared.

For X, most of that "resident" is resident *video ram*, often mapped multiple times, and not system RAM. X servers always look like they are using a lot more system than they really are.

At any rate, when we switched from VNC to NX, I recall that the reduction in memory use was clearly discernable in the systat reports. Note that the 34MB for the Xvnc process represents 3.4GB with a hundred desktops running. When people tell me that program Q "only" consumes 34MB, I automatically multiply by 70 to see what the *real* consumption would be if my users were running it on my most heavily loaded server. It makes a difference.

Bad and complex architecture

Posted Jul 30, 2009 7:35 UTC (Thu) by astrand (guest, #4908) [Link]

""
No nxproxy. Just nxagent and nxnode, with nxnode using less than a meg of res - shared.
""

As I understand it, nxnode is a shell script, so it's no surprise that it consumes less memory than a full Xserver...

Why are you not running a nxproxy?

The nxagent should be the Xserver, so that is what should be compared to Xvnc. One theory why it consumes less memory than Xvnc is that it (AFAIK) is based on a very old X implementation, X.Org 6.9 or something like that. Back when we delived Xvnc based on that old implementation it was also more lightweight, consumed less than 10 MiB or so. But of course, it also lacked many modern X extensions.

It's not the VNC part of Xvnc that consumes the RAM; it's the X server.

I agree with you that small figures can turn into large numbers when you multiple with the number of users. But I still claim that even 28 MiB (RES-SHR, right now) is not a big deal if you are running a full, modern desktop environment and mainstream applications. These typically consumes much, much more.

Bad and complex architecture

Posted Jul 30, 2009 15:11 UTC (Thu) by sbergman27 (guest, #10767) [Link]

I have pretty good numbers on what it takes to run 50-70 Gnome desktops. I went back and looked, and when we made the VNC->NX switch, we were 32 bit and running about 50 desktops on 4GB memory. So aout 82MB per user. (Surprised?)

Apparently the functions of nxproxy have been subsumed by nxagent. We're running freenx 0.7.3 with nxlibs 3.3. NX has become somewhat simpler.

Although we have no need for multimedia, and in fact actively discourage it, I did run a side by side comparison of NX and Tiger last night using this amusing and endlessly fascinating video:

http://www.elphel.com/3fhlo/samples/333_samples/m021_300_...

This is on a 1680x1050 screen. It comes up at 320x240 or so. And Tiger reports a 2177kbit connection speed. At that size, both NX and Tiger are jerky. I clearly see each frame update. However, the Tiger instance seems to update at a more even rate. The NX framerate jumps around a lot, which is annoying. I'd give VNC the edge, there. I would say that Tiger is barely usable at that size. If I maximize the totem window, or go full screen, both Tiger and NX go down the toilet. Maybe 2 frames per second. In fact, neither Tiger nor NX are usable if I increase much at all over 320x240.

Interestingly, if I let NX run it through several times, it eventually will play at any size, even full screen, with silky smoothness. Tiger can't begin to match NX's client-side caching. But of course, for this use, that's cheating.

Running this test, I spent a good bit of time on both types of remote desktop. And did some more testing of things like browsing the web and scrolling through PDFs. With NX, it's so easy to forget I'm not on the local machine, that I *have* to make sure to use a different wallpaper remotely and locally. And even then I have to stop and remind myself whether I'm remote or local. With Tiger, I can *never forget* that I'm on a laggy remote connection. My users would storm in and lynch me if I tried to saddle them with it.

What I get out of all of this is that on a 2 mbit connection with a 75ms ping time:

- NX is *far* superior for normal business desktop work. (Like night and day. There's no comparison.)
- For videos, Tiger is about the same speed (or perhaps slightly faster) and notably smoother for very small videos.
- Neither NX nor Tiger are usable at all for videos much beyond 320x240.
- FreeNX is getting simpler. And Neatx is about to take that simplification to the next level.

FWIW, I do use VNC to remotely administer the legacy windows clients.

Bad and complex architecture

Posted Jul 30, 2009 18:00 UTC (Thu) by astrand (guest, #4908) [Link]

Interesting to read your extensive tests.

""
...when we made the VNC->NX switch, we were 32 bit and running about 50 desktops on 4GB memory. So aout 82MB per user. (Surprised?)
""

Not really. There are many different use cases, and this memory usage is actually what we recommended a few years ago (we recommended about ~50 MiB per user). But since, the desktop and applications have started to grow. This is why we are now recommending 100-150 MiB instead. This is enough to cover a typical rich desktop with heavy applications such as OpenOffice, Firefox, Google Earth etc. But of course, for other users it may still be perfectly fine with less than that.

Regarding video: Does totem change the resolution to 320x240 before playing the video? If not, 1680x1050 is what's going to be used. I understand if this gets jerky on 2 Mbit. In general, video playback only works well on LANs.

We are regularly testing video with sound in 1024x768 on that works great, but on a LAN.

Bad and complex architecture

Posted Sep 14, 2009 12:21 UTC (Mon) by sushisan (guest, #60822) [Link]

My experince is totally different!!!

We have a client with 8 terminals only. For the migration we have a server with a Phenom X4 with 8Mb ram

We use freenx in the server (F11) and the nx client in the first time.

The bandwith usage is very good, even with a SLOOOOOOOOW internet conection.

But the memory usage is a disaster!!! The nxagent can't stop to raise the memory usage until start to swap the system with or without usage in the system (only with a connection active)!!!

I can't find any solution to this that do even when I switch off the cache.

Now we've migrated to Xvnc and work pretty good

Bad and complex architecture

Posted Jul 30, 2009 15:32 UTC (Thu) by sbergman27 (guest, #10767) [Link]

And I had intended to mention that NX is a complete remote solution in itself, including an esd sound server, samba-based client printer sharing, and samba-based file sharing. Whereas VNC is just video. Not that we make use of all that. But it sounds like your customers might. That narrows the complexity difference yet more.

Bad and complex architecture

Posted Jul 30, 2009 18:14 UTC (Thu) by astrand (guest, #4908) [Link]

Exactly, I'm glad that you are pointing this out. Many people just compare, say, the graphics performance and don't realize that it takes much more for a complete solution.

I'm trying not to "sell" ThinLinc too much in this forum, but since you brought this up: In ThinLinc, we are implementing access to local devices using completely separate protocols, all running on top of SSH. This allows us (just like NX) to use existing and open protocols. But unlike NX, we use the real upstream versions, instead of forks. This allows us to work close with the community.

I haven't checked what NX provides nowadays, but I'm quite sure that we actually have better support for local devices. For example, we are supporting:

* Sound (using PulseAudio, superior to ESD).
* Serial port redirection
* File access (using NFSv3/unfs3, much more lightweight than Samba)
* Local printing (no local configuration necessary)
* Smart card redirection and authentication

All of the above are supported both on Windows and Linux. We have clients for other platforms such as Solaris and Mac OS X (but not yet with full support for all types of local devices.)

Bad and complex architecture

Posted Jul 30, 2009 19:36 UTC (Thu) by sbergman27 (guest, #10767) [Link]

Out of curiosity, what are the licenses on the ThinLinc client and server?

Bad and complex architecture

Posted Jul 30, 2009 20:06 UTC (Thu) by astrand (guest, #4908) [Link]

The ThinLinc product contains many components and thus has multiple licenses. In short, the core "protocol handlers" are all open source while the control processes are proprietary, but with a free (free-as-in-beer) license for 10 users. For more information, see http://www.cendio.com/legal/.

Bad and complex architecture

Posted Jul 30, 2009 20:54 UTC (Thu) by sbergman27 (guest, #10767) [Link]

"""
I'm trying not to "sell" ThinLinc too much in this forum, but since you brought this up:
"""

Well, it was probably inevitable from the time that you, Peter ├ůstrand, "Chief Developer" for Cendio's ThinLinc product, a proprietary competitor to NX, started a thread on LWN.net entitled "Bad and complex architecture", trashing NX, and talking up TigerVNC more than its actual performance justifies, without really disclosing who you were until finally dropping a hint long after everyone else had moved on from this thread.

Shame on you. When we think Microsoft is doing that we call it "Astroturfing".

I have found our conversation enjoyable and enlightening, and my resulting research beneficial and educational. But I can't help feeling annoyed.

Bad and complex architecture

Posted Jul 30, 2009 21:54 UTC (Thu) by astrand (guest, #4908) [Link]

I'm sorry to hear that you feel "annoyed", it was certainly not my intent. I'm writing this in my spare time, as a private individual. Cendio is not paying my LWN subscription. I don't think that one needs to present themself before writing in this forum. Nor should it be necessary to include disclaimers of type "this is my personal opinion and not my employers".

Bad and complex architecture

Posted Jul 30, 2009 22:37 UTC (Thu) by sbergman27 (guest, #10767) [Link]

"""
I'm writing this in my spare time, as a private individual...
"""

... with a direct and substantial financial interest in discrediting the competition. And if you were to let people know about your direct and substantial financial interest up front you would have less credibility when doing it.

Who it is who pays for your LWN subscription, and whether it happens to be during business hours or not is completely beside the point.

And when such clear conflict of interest exists, it *is* customary to declare such.

disclaimers

Posted Jul 31, 2009 0:47 UTC (Fri) by xoddam (subscriber, #2322) [Link]

Well it certainly is customary to declare a pecuniary interest upfront, but I would not have thought that diminished one's credibility. Indeed it has been most enlightening on occasion when, for instance, openly-declared vmware hackers have weighed in on the subject of virtual machine internals in the context of a discussion of several competing free vm implementations.

Bad and complex architecture

Posted Jul 31, 2009 13:29 UTC (Fri) by sbergman27 (guest, #10767) [Link]

Agreed. Industry players commenting about the relative merits of their respective approaches is a good thing. Just not when it comes in the form of astroturfing. (├ůstrand-turfing?)

Bad and complex architecture

Posted Jul 31, 2009 16:26 UTC (Fri) by sbergman27 (guest, #10767) [Link]

The above was supposed to be a reply to xoddam, of course.

Bad and complex architecture

Posted Aug 7, 2009 13:31 UTC (Fri) by deleteme (guest, #49633) [Link]

A little harsh perhaps? I found the discussion very interesting.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds