Hi Daniel. When you say WAN link, are you referring to a network link between two offices at your company, or do you mean your Internet connection? Also, what speed is this link? When you say WAN, I think T1, T3, etc... Can you monitor your gear with SNMP or command line to see what performance stats on the gear are? Can you throw in a linux box running ntop to see the traffic coming and going? Can you do ttcp test just over the link itself?
Some network gear can queue smaller "interactive" packets ahead of larger bulk transfer packets, to give better response to some applications in heavily loaded situations. Most of the following suggestions are ways to reduce load/optimize the use on the link. X-windows is not the most network lite protocol out there. I've seen it work well on a lan, but very poorly over a slow/high latency link. If you can, have the users try using VNC, or freenx. Both create a virtual X desktop on the target machine, and just shows you a mirror of it on your desktop which you can disconnect from and reconnect to at will. (They are the gui equivalents of screen or tmux) The benefit of that is that instead of getting X updates, your client gets smaller raster updates(like rdp), which works better over slow links. VNC is not encrypted by default, so keep that in mind if it's going to go over an untrusted link. For web traffic, you could setup a squid proxy on a spare machine on the lan side of the link. This can share common web traffic among clients. Year ago when I worked at a company that only had a T1, we did this and it worked quite well. We had to configure the client machines to use the proxy, (but there are automated ways to do that now and you can do it transparently). At the time, windows updates worked really with squid, as the first client primed the squid cache with the files, and all the other clients got them at lan speeds. If you control both sides of the WAN link, (it's not just a pipe to the internet) You could possibly look at link compression, depending on the equipment and the speed of the link. I did it years ago over a t1, and it was ok. Got maybe 2:1 compression. You can also look at some WAN accelerators, from companies like riverbed. They optimize chatty protocols, perform caching, and compress the traffic to get more out of the link for you. Not cheap though. If you have a windows server 2008R2, you can look at using BranchCache, which does some of the same things. http://www.microsoft.com/en-us/server-cloud/windows-server/branchcache.aspx You might also be able to tweak some setting on your WAN gear to prioritize the traffic that you consider important, or at least ensure fairness. If your wan gear can't do that, then you can also at traffic shaping gear, which can optimize/prioritize the flow of traffic over the link. On a network mailing list that I am on, people have mentioned liking Netequalizer, which is a inexpensive transparent traffic shaper. It tries to make sure that people don't hog the link by default. Let me know what you discover. rgt On Wed 06 Jun 2012 07:43:56 PM EDT, Daniel Feenberg wrote: > > We have maxed out our WAN link, and users are complaining of slow access > to websites and x-windows interaction. Yet when I ping sites on the > internet I see no lost packets, and ping times for relatively close hosts > are consistently 20 - 30 milliseconds. Large packets are about the same. > Ping times to our ISP's router at their POP are 2-4 milliseconds. I see no > dropped pings to real hosts. Sometimes the ISP router drops a ping but I > understand that may be due to ICMP limiting. > > I have difficulty reconciling these facts. If pings are fast and packets > are not dropped, why do users see problems? I can confirm things seem > slow. Is this the dreaded "buffer bloat" problem so recently hyped? Is > there anything I can do here to aleviate it while waiting for more > bandwidth? > > Thanks > Daniel Feenberg > NBER > > _______________________________________________ > bblisa mailing list > [email protected] > http://www.bblisa.org/mailman/listinfo/bblisa _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
