On Mon, 27 Sep 2004 12:06:46 +0200, Dag Sverre Seljebotn <[EMAIL PROTECTED]> wrote:
Thanks for the response! > Theory (I don't know anything about VNC but here I go): VNC has slow refreshes > because it is optimized for low-bandwidth..ie, high latency is better than > using much bandwidth, so it can take the time to compress the command stream. > X doesn't compress, and so it is quicker in response but in this case it > probably saturates your network link. X is a resource hungry protocol in this > case: Those TIFFs you are looking on are uncompressed on the server, then > sent uncompressed over the network... That's what I thought, which is why prior to deploying VNC on the same server, I was pushing for LTSP because of the supposed network performance improvement. TightVNC deploys is usable on our LAN with dial-up access (33.6Kbps) -- not the best but its usable. > This is just a theory, but I would try it out. Best way I think would be to > get one of the clients a direct uplink to the server (install a third NIC in > the server for instance), and see if that client performs better than the > rest of them. (Well, first you should do a (watch "uptime; free") so that you > are sure it isn't swapping kicking in for instance, in which case the > solution is more memory... it must still hold all those images uncompressed > in memory). I did something almost similar, since physical configuration prevents me from putting a PC in the server room or installing a cable physically connectnig the server and the PC. Instead, the second NIC of the server is connected to another 10/100Mbps switch (high backplane and large switching fabric) with only the other PC connected to the same switch. Latency will be introduced in this setup, but its at least closer to real-world deploys. The performance of said client is marginally improved. I've been running SAR and SNMP+MRTG, and network usage on the server end seems "normal." To give you an idea: 5 Users: 2.8Mbps (avg. 5 min-sample), 3.4Mbps (peak 5 min) 10 Users: 3.6Mbps, 4.4Mbps (peak) 20 Users: 4.2Mbps, 5.8Mbps (peak) 40 Users: 5.6Mbps, 6.9Mbps (peak) That's still far from what the switch is able to push (about 48Mbps). > If this is the problem, I see three solutions: > Option a) - I don't see why admistering local apps with 100 clients is worse > than with one. If you are using LTSP, you just set it up once and it would > work on all the clients. This would help because the compressed TIFFs would > be sent over the network, not the uncompressed ones. Worse because of the setup. Unfortunately for me, I'm supporting a plethora of clients. So nothing is standard. From ancient network cards to possibly unsupported graphics cards to stubborn PS/2 or Serial mouse devices not working. Getting an app to run locally takes a little bit more effort because I have to make sure that they have enough RAM and their video cards are supported. In a deployment of 100PCs (ranging from Pentium Classics to Celeron 233s), that can be a headache. In a deployment of 5000+ (which is our target), it will be a nightmare. The only downside (in my case) with doing large scale local-side computing is that I will definitely need to improve the network. The nature of the application is dealing with thousands of small (4KB-200KB) files. NFS traffic as it is now is high. I've considered using NFS over TCP (in addition to the NFS optimizations), but NFS over TCP requires a little bit more CPU overhead. > Option b) - Upgrade the network to gigabit (what's the point of gigabit cards > if you use 100Mbps switches anyway?) except the last switch before the > clients, which could for instance be a 8-port 100Mbps switch with a gigabit > uplink. Gigabit ethernet is cheap these days (at least with the lower-range > switches... if you run a big 24-port switch you're worse off). This is one thing I'm considering, but before I can push for Gigabit, I have to define the limitations of our current setup. As you've probably guessed already, we're making do with a lot of "dated" equipment -- which is one reason why LTSP is gaining some momentum -- giving life to old hardware. :-) > Option c) - Run NX. NX is X, but it is compressed so network load is much > lower. http://www.nomachine.com/ made it, and you can buy it from them, but > it is an open source product and if you search for "FreeNX" you should be > able to find a free version. There would be a need to find out how to run a > FreeNX client in LTSP in this case (if people haven't already done it), and > if you do it I'd really like to hear about your experiences as I'm thinking > about setting it up myself. Thanks for the suggestion. I'll be sure to check this out. > Both a) and c) can of course be combined with b) for further gain, though I > don't really see a point of doing a) and c) at the same time. Personally I'd > try b) first if you have the money, then do c) because it is more universal > than a) (it would have an effect on all apps, not just one). > Thanks again for the suggestions! -- Gino LV. Ledesma // Quote: "They redundantly repeated themselves over and over again incessantly without end ad infinitum" -- ibid. http://www.pinoymac.org/ ------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _____________________________________________________________________ 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
