Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for November 27, 2013
ACPI for ARM?
LWN.net Weekly Edition for November 21, 2013
GNU virtual private Ethernet
Device trees II: The harder parts
Google releases Neatx NX server
Posted Jul 24, 2009 22:38 UTC (Fri) by dlang (✭ supporter ✭, #313)
on signficant thing that NX does is to provide a local server to act as a proxy for these sorts of things, if it knows the answers already it provides them without having to actually go and ask the display.
'fixing the X protocol' to do the same thing would end up looking very similar, a local daemon that local applications think is their display, that then remembers the answers from prior requests.
you can't eliminate these calls without eliminating backwards compatibility, and so far nobody has been willing to do that.
Posted Jul 26, 2009 4:10 UTC (Sun) by sbergman27 (guest, #10767)
True. Watching an X session over a dial up modem (external, with tx/rx lights) is quite interesting. Not only are there a lot of round trips, but it appears that everything happens in serial fashion with only one request or response in the pipe at any given time. In the modem's LEDs you can clearly see "request, response, request, response, request, response...".
Many people think that X needs bandwidth. It actually isn't such a bandwidth hog. Others correctly point out the round trip issue. But rarely have I heard anyone comment upon the serialized nature of the protocol. And that looks like the real performance killer to me. At least over any sort of WAN. At Ethernet latencies it's likely not a problem at all.
Posted Jul 26, 2009 9:28 UTC (Sun) by njs (guest, #40338)
That's why relatively crude protocols like VNC can completely outclass X -- sure, now you're stuffing giant blocks of pixels down the network pipe and taking way more bandwidth, but those giant blocks of pixels have no dependencies -- so instead of waiting around all the time, you can just saturate the pipe. (rsync uses a similar strategy; see also pipelined SMTP, IMAP, HTTP, ...)
Posted Jul 26, 2009 17:38 UTC (Sun) by elanthis (guest, #6227)
Posted Jul 26, 2009 18:58 UTC (Sun) by sbergman27 (guest, #10767)
Posted Jul 27, 2009 9:34 UTC (Mon) by PO8 (guest, #41661)
Very bad idea
Posted Jul 27, 2009 12:31 UTC (Mon) by khim (subscriber, #9252)
A proxying solution like NX can perhaps help to tackle the
problem with less effort than optimizing the X client side, serving as a
stopgap until everybody's latency is so low that no one cares
Latency will never go away. That's just fact of life. Speed of light is
300'000km/sec and Earth 40'000km thus minimum possible worst-case latency is
130ms. In reality it can be somewhat reduced by using few datacenters (like
Google does), but it can not be reduced to make remote usage of X server "in
the cloud" possible...
Posted Jul 27, 2009 23:16 UTC (Mon) by marcH (subscriber, #57642)
... in vacuum. In fiber or electrical cables, it is typical 200,000. That's 5 milliseconds per 1000km. Multiply by two to get the round trip time, and multiply once again by (typically) two to account for buffering in processing in active network nodes.
Posted Jul 31, 2009 23:24 UTC (Fri) by sbergman27 (guest, #10767)
Posted Aug 1, 2009 9:59 UTC (Sat) by modernjazz (guest, #4185)
Sorry, bad math
Posted Aug 2, 2009 4:40 UTC (Sun) by khim (subscriber, #9252)
Why run a 40,000km cable when you could just run a 3 foot cable
the opposite direction?
If you'll use 3 feet cable you'll be 20'000km from destination. You get
40'000km when two points are antipodes: it does not matter which way you'll
go it's 20'000km one way and then 20'000km another way - direction is
irrelevant. The only way to reduce distance is to burrow a hole and the
depeest hole known to a man (less then 15km) does not shrink the distance all
Posted Aug 6, 2009 16:32 UTC (Thu) by phanser (guest, #60087)
Posted Aug 9, 2009 12:12 UTC (Sun) by khim (subscriber, #9252)
The device capable of burrowing straigh through Earth? I know few
guys who'll pay BIG BUCKS for such thing - where are selleing it?
And if you are not selling then the only way to go to the antipode is
along the Earth surface - so yes, 40'000km (give or take) is shortest path
Posted Aug 13, 2009 19:46 UTC (Thu) by hummassa (subscriber, #307)
The distance between antipodes is half that - 20000km ALONG THE EARTH SURFACE. It would be ~12000km thru the center of the Earth.
Posted Aug 13, 2009 19:58 UTC (Thu) by johill (subscriber, #25196)
Posted Jul 29, 2009 8:54 UTC (Wed) by michaeljt (subscriber, #39183)
Posted Jul 29, 2009 17:59 UTC (Wed) by dlang (✭ supporter ✭, #313)
the vast majority of people only use X on a local machine and never touch the network
this is especially true for developers.
it's also true that most people have no problem with the bloat of current desktop software because they run on recent machines that are fast and have lots of ram.
in both cases this doesn't mean that there isn't a problem, and that fixing the problem wouldn't improve things for everyone with drastic improvements for some users (possibly drastic enough to open an entire new category of use), bit just means that unless it's pointed out to people and they are encouraged to _try_ the use-cases that have problems they will never notice them.
personally I suspect that the linux desktop bloat had some impact on the weak showing of linux on netbooks. most linux distros and desktop environments really want more resources than a netbook has. Linux can run fine on that sort of hardware (I know, I used much lesser hardware for many years), but the current crop of desktop environments really don't care about resource use.
Posted Jul 29, 2009 19:38 UTC (Wed) by michaeljt (subscriber, #39183)
Posted Jul 29, 2009 20:46 UTC (Wed) by dlang (✭ supporter ✭, #313)
if you add a fraction of a second latency you shouldn't notice it for most things, but if you see points in your code start taking significantly more time they are dong many serialized round trips.
Posted Jul 24, 2009 23:20 UTC (Fri) by ejr (subscriber, #51652)
However, to many the critters have left the barn on X over the network. DRM. Fonts. There's enough pain to make people hesitate.
Posted Jul 25, 2009 12:36 UTC (Sat) by nix (subscriber, #2304)
Posted Jul 26, 2009 13:31 UTC (Sun) by sbergman27 (guest, #10767)
Can't you just:
Xorg -query myserver.localdomain -fs tcp/myserver.localdomain:7100
and make sure xfs is running on myserver (and listening on tcp:7100) and have all the server's installed fonts available everywhere? One shouldn't have to upgrade a thin client once it is in place. Only the server.
Posted Aug 11, 2009 15:41 UTC (Tue) by Lurchi (guest, #38509)
So you install the fonts on the terminal server (once) and the program
will render the same on every client.
Posted Jul 27, 2009 15:31 UTC (Mon) by ejr (subscriber, #51652)
The font problem isn't technical, it's licensing. If you want more than bitmaps in the US, you need the appropriate license for the font. Elsewhere, the font needs licensed regardless of use pre- or post-rendering. There are good, free fonts now, but I'm sure you know apps that aren't agreeable to using anything but their pre-defined, proprietary fonts. Again, these issues could be managed, but they're a pain. Just configuring font matching is enough of a pain, anyways (not a dig, it's a difficult problem).
A VNC-like proxy sidesteps most of these. An NX proxy, well, it still runs into problems with heavy graphics (scientific visualizations, how I use it), but it does make network use feasible again.
Posted Jul 25, 2009 3:31 UTC (Sat) by dkite (guest, #4577)
It may be that fixing the protocol within the X community wasn't possible.
After all it wasn't the only thing needing fixing, and xorg was forked to
make the necessary reworking possible.
Nx is very quick and responsive. It did a very nice job with resolutions
making my netbook work very well over a slow link to my desktop machine.
I wonder if google is going to offer a virtual desktop service for their
netbook OS? I was poking around setting such a thing up for myself but ran
into the not finished parts of the free nx server.
What's the point?
Posted Jul 25, 2009 5:03 UTC (Sat) by khim (subscriber, #9252)
I mean: what can they offer to Chrome OS users? Typical Linux desktop?
2007 showed that users are not interested in that. It looks like
typical internal projects: engineers are familiar with Linux and I guess use
Linux in Google a lot, so it makes sanse to offer them virtualized Linux with
Neatx. As for Chrome OS... this is OS for "mere mortals", right? They have no
use for that stuff - uless it's Windows-based virtual computer. And
the last thing Google wants is to promore Windows further.
This being said I'm pretty sure someone will provide such service.
But for that they'll need some free client ported to NaCl and right now Neatx
only works with proprietary client... oops?
Posted Jul 25, 2009 8:15 UTC (Sat) by man_ls (guest, #15091)
Why will you need manual intervention?
Posted Jul 25, 2009 9:00 UTC (Sat) by khim (subscriber, #9252)
Manual intervention does not look like a Google thing, but for a
price -- who knows.
Hmm... Why do you need the NX for that?
You can throw away the whole thing and your data will still be available in
the cloud. All data on the netbook itself are just a cache for the data in
the cloud. Sure if your last two weeks spent in the wilderness are
extemely valuable - you'll be able to find someone who'll replain
the Chrome OS for a price, but for most users... just click "reinstall"
button - local data will be wiped and clean, updated version of OS will be
available in a few minutes...
And if your OS is broken beyond the ability to synchronize... the chances
are high it's broken beyond the ability to work with NX too...
Posted Jul 26, 2009 14:57 UTC (Sun) by dkite (guest, #4577)
I've used the spreadsheet a bit. I have a couple that are very simple and
work fine, and one that is multipage and a bit complex. It doesn't.
They were trying to use existing installed base browsers to expand their
application suite. The server based idea works well for some things, but
the browser is a poor ui for complicated apps.
What if you opened google chrome and got a remote X spreadsheet running
Posted Jul 27, 2009 18:42 UTC (Mon) by jzbiciak (✭ supporter ✭, #5246)
I suspect offering GNOME or KDE aren't the targets. Offering something built around some of the same core infrastructure (X, Linux) that GNOME and KDE built on seems entirely reasonable and likely.
Bad and complex architecture
Posted Jul 25, 2009 8:37 UTC (Sat) by astrand (guest, #4908)
VNC, on the other hand, is a much more cleaner solution, where you have only one Xserver (Xvnc), running on the server side. The protocol is truly thin. The performance is not dependent on well behaved applications. Since the protocol is so minimal, implementing clients is easy. And with the recent TurboVNC/TigerVNC developments, you can achieve amazing performance which allows usage of 3D-heavy or video applications.
Posted Jul 25, 2009 12:21 UTC (Sat) by sbergman27 (guest, #10767)
Better than it used to be, maybe. But not "amazing" enough. Our desktops at branch offices are delivered by FreeNX. It performs quite well. I just did a mini-evaluation of TigerVNC based on your recommendation, and there is no way my users would find the performance acceptable for their daily use. Even the best VNC clients/servers today are too laggy for that.
NX *is* more complicated than I would like, which is why I jumped to try Tiger after reading your post. But Tiger is obviously not the solution.
Posted Jul 25, 2009 12:55 UTC (Sat) by nix (subscriber, #2304)
Posted Jul 25, 2009 16:52 UTC (Sat) by lab (subscriber, #51153)
How does technology like pure X or NX fare with these type of apps?
Posted Jul 25, 2009 17:12 UTC (Sat) by astrand (guest, #4908)
From a technical viewpoint, Xvnc does (by default) pixel-by-pixel comparisons on the framebuffer. So unless you have explicitly disabled this (-CompareFB=0), or have some strange client, I really don't understand why you are experiencing this behaviour.
It's better to have half a cake then no cake at all
Posted Jul 27, 2009 6:02 UTC (Mon) by khim (subscriber, #9252)
Every time I've tested NX, I tried a Java based application and
confirmed the bad performance.
Don't use such applications then. Sure, badly-written applications are
unusable with NX - and most Java-based applications are pigs in regard to any
and all resources. But with VNC all applications are equally
Posted Jul 25, 2009 17:20 UTC (Sat) by astrand (guest, #4908)
For many (or even "most" in my context) customers/cases, the VNC bandwidth requirement is no problem. I can say this after delivering VNC based solutions to customers for the last 7 seven years.
What kind of bandwidth do you have?
Posted Jul 25, 2009 18:23 UTC (Sat) by sbergman27 (guest, #10767)
Oh, come on. The only instance in which VNC *might* outperform NX is on a LAN. And my bet would still be on NX there. We used RealVNC and then TightVNC over T1 connections for some months and we found them to be quite unacceptable for performance, and even worse (far worse) for display quality. This is for general business desktop use. Web, email, OO.o, lots of PDF viewing, often parts manuals with lots of scanned images. Some IE under Wine (unfortunately). We throw a lot at our remote displays and NX shines where VNC chokes. The mini-eval I just ran on TigerVNC reported 2047kb. It was better than when we used VNC several years ago. The video quality was good, as it immediately selected a sufficient color depth. But the performance was markedly inferior to a side by side NX session.
Regarding well vs poorly behaved apps... if there is an app that chokes NX but not VNC, I have yet to see it. Tiger/Turbo may, indeed, do well on 3D over a LAN. But my business desktop clients have generally opted against providing Doom 3 to the thin clients. Out of curiosity, what customers do you have who are interested in FPS, and what are they doing?
Posted Jul 26, 2009 18:01 UTC (Sun) by astrand (guest, #4908)
When you say "2047kb", are you referring to the "kbit/s" measurement available in the client? This is not a good measurement of how much bandwidth VNC "require".
Out of curiosity, what customers do you have who are interested in FPS, and what are they doing?
Video playback (Youtube, mplayer), custom OpenGL applications for CAD/CAM/visualisation, Catia etc.
Posted Jul 27, 2009 14:22 UTC (Mon) by sbergman27 (guest, #10767)
I'm saying that 2047kb was the bandwidth that TigerVNC reported that it had to work with over that connection, which should presumably be the same that NX had to work with over that same connection. And for business desktop use, VNC was pretty clunky and unresponsive compared to NX. As we have no legitimate business need for video on our business desktops, we don't allow it. So I don't have a base of experience as to how well or poorly NX performs relative to *vnc for that use.
BTW, I tried TigerVNC rather than TurboVNC specifically to avoid the excuse that VNC sever/client Q still uses the old 3.X protocols. Tiger uses V4.
Posted Jul 25, 2009 19:29 UTC (Sat) by nix (subscriber, #2304)
(Mind you, I've never tried NX on either of these.)
Posted Jul 25, 2009 19:54 UTC (Sat) by sbergman27 (guest, #10767)
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.
Posted Jul 25, 2009 22:42 UTC (Sat) by nix (subscriber, #2304)
Posted Jul 26, 2009 18:11 UTC (Sun) by astrand (guest, #4908)
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.
Posted Jul 27, 2009 17:57 UTC (Mon) by sbergman27 (guest, #10767)
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.
Posted Jul 27, 2009 19:37 UTC (Mon) by astrand (guest, #4908)
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.
Posted Jul 30, 2009 4:34 UTC (Thu) by sbergman27 (guest, #10767)
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.
Posted Jul 30, 2009 7:35 UTC (Thu) by astrand (guest, #4908)
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.
Posted Jul 30, 2009 15:11 UTC (Thu) by sbergman27 (guest, #10767)
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:
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.
Posted Jul 30, 2009 18:00 UTC (Thu) by astrand (guest, #4908)
...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.
Posted Sep 14, 2009 12:21 UTC (Mon) by sushisan (guest, #60822)
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
Posted Jul 30, 2009 15:32 UTC (Thu) by sbergman27 (guest, #10767)
Posted Jul 30, 2009 18:14 UTC (Thu) by astrand (guest, #4908)
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.)
Posted Jul 30, 2009 19:36 UTC (Thu) by sbergman27 (guest, #10767)
Posted Jul 30, 2009 20:06 UTC (Thu) by astrand (guest, #4908)
Posted Jul 30, 2009 20:54 UTC (Thu) by sbergman27 (guest, #10767)
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.
Posted Jul 30, 2009 21:54 UTC (Thu) by astrand (guest, #4908)
Posted Jul 30, 2009 22:37 UTC (Thu) by sbergman27 (guest, #10767)
... 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.
Posted Jul 31, 2009 0:47 UTC (Fri) by xoddam (subscriber, #2322)
Posted Jul 31, 2009 13:29 UTC (Fri) by sbergman27 (guest, #10767)
Posted Jul 31, 2009 16:26 UTC (Fri) by sbergman27 (guest, #10767)
Posted Aug 7, 2009 13:31 UTC (Fri) by deleteme (guest, #49633)
Posted Jul 26, 2009 8:30 UTC (Sun) by tialaramex (subscriber, #21167)
Years ago I watched someone play my copy of GLQuake from their machine over GLX quite comfortably. It wasn't quite as fast as a local copy of the game, but it was very playable. The VNC solution, in addition to chewing all the CPU on both machines and _still_ requiring a fast OpenGL implementation on the machine running the game, would have also chewed up all the network bandwidth, and I'm not convinced it would even have been playable.
My own OpenGL software is much less pretty than Quake, but it has practical reasons to be used over a network. Runs fine, but in VNC it would definitely incur more or less fullscreen refreshes at 60Hz. That's a LOT more bandwidth and CPU than a few thousand vertices every so often and a set of transform matrices per frame.
Maybe you have a special definition of "outperform" but for me if you needed many times more resources to get the same result, that is less rather than more performance.
Posted Jul 26, 2009 14:06 UTC (Sun) by mjg59 (subscriber, #23239)
Posted Jul 26, 2009 18:18 UTC (Sun) by astrand (guest, #4908)
If you want to use VirtualGL with VNC, however, you'll need an accelerated implementation (TurboVNC/TigerVNC/Sun Shared Visualization/ThinLinc) to get good performance.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds