I read the Wikipedia article and I searched "virtualgl ltsp". It looks good! I believe that virtualgl is not being used in ltsp. Am I correct?
Is this something a mere user like me can add? (I'm a chemist, and I can spell "computer graphics.") If not, is it likely to be added by someone more qualified any time soon? Can I help accelerate that process? On Tue, Mar 5, 2013 at 12:49 PM, Jakob Unterwurzacher <jakob...@gmail.com> wrote: > Hi Lachele! > > Opengl commands are sent over the network and executed by the client. Even > on gigabit, the latency is probably very high compared to local execution. > > Virtualgl promises to solve that problem - and its wikipedia article is a > good read on the topic! > > Best regards, > Jakob > > Am 05.03.2013 17:00 schrieb "Lachele Foley" <lf.l...@gmail.com>: > >> In a response to Jim a day or so ago, I gave reasons why localapps >> can't solve all our problems. To recap that, a brief example: The >> programs that generate our graphics can, for the large systems we >> treat, fill the 3-4 GB of RAM available on a client. While we could >> potentially move some things to our clients, that won't solve all our >> troubles. I used the video (youtube) example because it is something >> simple that most people do every day. We are actually pretty >> unconcerned about being able to view videos over the internet. >> >> You mention network latency... I might not have the tools I need to >> properly assess things, but if I open atop on both client and server >> and run an extended part of one of our benchmarks (not a video), the >> ethernet load remains solidly below 10%. So, for our normal >> benchmark, best I can tell, ethernet is not an issue. >> >> Even if I stray from our usual benchmarking and give it a more serious >> workout (same software and system), the load only pushes 85%. In that >> situation, the client has one CPU running at 50% load, and the server >> reports the process as taking about 32% of a CPU. Other info from >> atop: packets from server to client: 710,000-720,000. From client >> back to server: 170,000-175,000. The speed between them is ~0.85 >> Gbps (hence, I presume, the 85% load). The default Ubuntu atop >> install doesn't come with a "kernel patch" for networking, so that's >> all I can get without a custom install. >> >> If I start a full-screen video on hulu (filling as much as it can of a >> wide format 24 inch monitor), then the ethernet load goes up to 90+%. >> I can accept that streaming video is more/different work than >> rendering molecular graphics. I just know we need something better >> than what we have. >> >> >> >> On Tue, Mar 5, 2013 at 8:01 AM, Richard Kweskin <rkwesk_l...@hellug.gr> >> wrote: >> > Quoting James McQuillan: >> > >> >> Lachele, >> >> >> >> I'll try and explain how the graphics works in a thin client >> >> environment. >> > >> > snip >> > >> >> I've been focusing most of my rather limited time on running things on >> >> the >> >> thin client. To me, everything is moving towards being web-based and >> >> the >> >> thin client is becoming a platform for running a web browser. Running >> >> the >> >> browser locally makes some things much better. Sound and video perform >> >> very well this way. But, it brings new challenges, like printing. If >> >> run >> >> the browser on the thin client, you need to also have a printing >> >> sub-system >> >> installed like CUPS. >> >> Also, where's the users home directory? Probably on the server, which >> >> means you need to use NFS or sshfs to have access to it. >> >> >> >> I should note that what I've just described in the last paragraph is >> >> really >> >> just a fat client. >> >> >> >> If you've got powerful enough thin clients, moving the processing down >> >> to >> >> the thin client can really boost the number of thin clients that a >> >> single >> >> server can support. basically, the server is just a boot server. A >> >> decent >> >> server should be able to handle hundreds of thin clients. >> >> >> >> I hope my rather long-winded explanation helps. >> >> >> >> Jim McQuillan >> > >> > What if these powerful clients ran the browsers locally (and indeed >> > any other app that is laboring under network latency.) That way the >> > client still remains thin and resources from the server are available >> > when needed, rather than running the clients whole hog fat. Of course >> > experimenting one way or another takes time. Perhaps start with just >> > two or three clients and experiment with altering just their >> > configurations. >> > >> > Richard >> > >> > >> > >> > ------------------------------------------------------------------------------ >> > Everyone hates slow websites. So do we. >> > Make your web apps faster with AppDynamics >> > Download AppDynamics Lite for free today: >> > http://p.sf.net/sfu/appdyn_d2d_feb >> > _____________________________________________________________________ >> > Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: >> > https://lists.sourceforge.net/lists/listinfo/ltsp-discuss >> > For additional LTSP help, try #ltsp channel on irc.freenode.net >> >> >> >> -- >> :-) Lachele >> Lachele Foley >> CCRC/UGA >> Athens, GA USA >> >> >> ------------------------------------------------------------------------------ >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://p.sf.net/sfu/appdyn_d2d_feb >> _____________________________________________________________________ >> Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: >> https://lists.sourceforge.net/lists/listinfo/ltsp-discuss >> For additional LTSP help, try #ltsp channel on irc.freenode.net > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://p.sf.net/sfu/appdyn_d2d_feb > _____________________________________________________________________ > Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: > https://lists.sourceforge.net/lists/listinfo/ltsp-discuss > For additional LTSP help, try #ltsp channel on irc.freenode.net > -- :-) Lachele Lachele Foley CCRC/UGA Athens, GA USA ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _____________________________________________________________________ Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto: https://lists.sourceforge.net/lists/listinfo/ltsp-discuss For additional LTSP help, try #ltsp channel on irc.freenode.net
