Latency effects everything we do … … no wait!

I’ve run into latency issues over the last 20 years, and in short, they’ve been

  • X-Modem
  • IBM SNA
  • Citrix
  • Windows Vista

X-modem

… was created in August 1977 to allow file transfers between Bulletin Board Systems.  Developed by Ward Christensen.  A simple protocol by design, which was it’s beauty and it’s downfall.  Didn’t work so well over satellite links with a latency of 300ms.  Relaxed X-modem was the workaround.

IBM SNA

… has a heartbeat of 2 seconds.  Miss the heartbeat and the link dies.  Which is what was happening in the remote community of Gove, in the Northern Territory.  Because of WAN congestion, and a tropospheric WAN link, mainframe terminals in Gove would drop out.  Reconfiguring the Gove Cisco switch to provide a local SNA heartbeat solved the problem.

Citrix

… curse of an idea I tell you.  In August 2003, Citrix sessions were dropping out at a remote site.  Citrix is very intolerant of WAN congestion (20ms).  So are the users who lose their Citrix sessions.  Given that a picture tells a thousand words, here’s what the network capture told us:

network_traffic 

The RED lines indicate traffic inbound to the client site.
The BLUE lines are outbound traffic.
Both measured at the Cisco switch, so it didn’t tell us what the local LAN was doing.

The inbound red traffic indicated that our desktop management toolset was heavily utilising the line, after hours in particular (desktop patching).  The outbound blue traffic didn’t tell us much from the graph.  Further investigation, with a network sniffer, showed that 70 Citrix clients were communicating with a (remote) Citrix Server farm.  Now each Citrix client uses about 20k/s bandwidth, so 70 clients across a 128k WAN link just didn’t fit.  The answer was for the customer to increase the size of the WAN link, which they did.

Vista

I had drafted why the Vista file copy routine was broken, due I think, to latency issues, but Mark Russinovich explains it so much better, here.