High latency network connection – simulation of bad UX

We all know, that all network applications where user experience (UX) is critical requires low network latency.

We also know, that Citrix works very well on high latency WAN links. It provides many features, that keeps user satisfied by UX. In the past we had “Local Text Echo” and “SpeedScreen”. Right now we have “HDX SuperCodec” and recently Citrix announced “Framehawk” technology for HDX.

OK, let’s say, that we want to verify, if our XA/XD customization works correctly in high latency WAN links. But we are connected to Data Center usually with at least 100MBps link (with <1ms RTT). So what can we do? We can switch to GSM modem, but nowadays we mobile providers connects us by LTE technology. I had this problem 2 month ago – how to simulate high latency link. In my case I wanted to test network file transfer using SMB protocol in WAN environment.

I found great tool – it’s called clumsy. Short description about those tool and it’s options (from clumsy website):

Leveraging the awesome WinDivert library, clumsy stops living network packets and capture them, lag/drop/tamper/.. the packets on demand, then send them away. Whether you want to track down weird bugs related to broken network, or evaluate your application on poor connections, clumsy will come in handy:

  • No installation.
  • No need for proxy setup or code change in your application.
  • System wide network capturing means it works on any application.
  • Support not only HTTP, any protocol based on TCP/IP is supported.
  • Works even if you’re offline (ie, connecting from localhost to localhost).
  • Your application keeps running, while clumsy can start and stop anytime.
  • Interactive controll how bad the network can be, with enough visual feedback to tell you what’s going on.



I decided to use this tool, to verify UX in XenApp environment. I started clumsy (to verify if it works) and set Lag to 200ms. Remember, when you set Lag for both Inboud and Outbound traffic, that you will get 400ms latency. Remember to start clumsy as an administrator.


OK, so now the XenApp test.
On screenshot below you can see two graphs with ICA performance countes. Upper – shows “Latency – Last Recorded” counter. Lower – show “Output Session LineSpeed”. In first case, I set latency to 500ms (red circle). Citrix detected, that line speed is very low and UX was terrible. What is interested – session compression level didn’t changed (with comparsion to low latency netrowk). After that I stopped clumsy, and my latency back to normal (1-3ms) – it’s blue circle. XenApp recalculated the line speed, and shows almost real value.


Clumsy – more information from it’s website:

clumsy will choose which packets to capture by given filter, in which in can specify whether it’s inbound or outbound, tcp or udp, socket port or ip, or a logical combination of many of those criterias. When started clumsy will only capture packets based on the filter, leaving others untouched.

After packets are captured, you can choose to enable provided functions to worsen perspective network condition:

  1. Lag, hold the packets for a short period of time to emulate network lagging.
  2. Drop, randomly discard packets.
  3. Throttle, block traffic for a given time frame, then send them in a single batch.
  4. Duplicate, send cloned packets right after to the original one.
  5. Out of order, re-arrange the order of packets.
  6. Tamper, nudge bits of packet’s content.

And here are links: download & manual.

Post author

Leave a Reply