On Wed, 6 Jun 2012, Rob Taylor wrote:
> 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? 10 mbs to the ISP over fiber. > 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. There is a Fortigate between us and a vanilla Cisco router, but I don't think any traffic shaping is going on. Ping times are still good with large packets (1000 bytes). Dan Ritter mentioned that I shouldn't trust ping for dropped packets. Would the router prioritize ICMP over tcp, so that ping would be fine but tcp packets would be dropped? Maybe there is a tcp-ping? > > 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. We want to try NX, but it doesn't cooperate with our 2-factor authentication. > 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. We don't have many users, just users with big files to transfer, so I don't think a cache would have much effect. > > 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. I will look at Netwualizer. > > Let me know what you discover. > Will do, if we figure it out. dan feenberg nber _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
