Thinwire vs Framehawk – from a 1800ms latency perspective

I have just returned back home from another great CUGTech event arranged by Citrix User Group Norway.
The conference took place on a cruise ship going from Oslo, Norway to Kiel, Germany and I thought what is a better place than a boat in the North Sea with a unstable satellite connection to test and have a session with Framehawk.
After all, Framehawk is created to handle latency and packet loss to give the user a smooth user experience even under these conditions.

Citrix acquired Framehawk in January 2014 and it was released in June 2015 as a standalone installation as part of Citrix XenDesktop 7.6 Feature Pack 2.
With the release of Feature Pack 3 it became a part of the VDA.

To read more about the Framehawk technology I recommend the following blog posts by Derek Thorslund and Mayunk Jain:
https://www.citrix.com/blogs/2015/06/30/our-first-release-of-framehawk-technologies/
https://www.citrix.com/blogs/2015/08/17/got-framehawk-weve-got-remote-access-tips-and-tricks/

I have also published a blog post describing the installation, configuration, tips and also some useful information regarding what is not supported as of today.
You can read it here.

So, back to the cruise ship…..

Since we were going to be on a ship with a very unstable internet connection I decided to set up an environment on my “portable datasenter” running a XD 7.6 FP3 environment on VMware WS in a closed network with the host.
And I have done enough demos to know that it is a big chance that something will fail when during the presentation so I also recorded a bunch of videos where I had 2 sessions running side by side. One with and one without framehawk (and use of video codec was turned off in policies to force Thinwire Compatibility Mode)

I decided to run a video called Infinityworm in a browser inside the XenApp sessions that is pushing the protocols to the extent since it is a large amount of pixels that needs to be replaced in a short amount of time.
The reason I choose this method was to see when either of the protocols would be the preferred choice under these extreme conditions.

One thing to have in mind is that Framehawk is more demanding regarding bandwith, CPU and compatibility than Thinwire, but how would Thinwire Compatibility Mode hold up against Framehawk?

Before departure I spoke with a good friend of mine called Marius Sandbu (@msandbu) who said that I could use his lab in Oslo during the session to show of a real life scenario.

At the end of day two on the conference it was time for my session.
I had listened to great sessions presented by really good speakers like Douglas Brown, Jarian Gibson, Marius Sandbu, Daniel Wedel, HÃ¥vard Bruvold, Thomas Poppelgaard and Magnar Johnsen and felt that I had to close the conference with a great session so I crossed my fingers and toes while establishing a connection to the datacentre in Oslo.

I got connected and looked at the latency…. 1800ms!!! Perfect conditions while pushing it to the extreme right? I started up a webpage in the session and was surprised of how quick the response actually was despite this high latency. So I navigated to www.vg.no that is a newspaper in Norway that has a great amount of high graphics on their landing page. It came up pretty quick and I was able to scroll down the page and it was under the conditions a great experience.

But there was something that wasn’t right. Every time I had done this type of scrolling test with Framehawk I would always get some “black strips” on the page when scrolling ,which would disappear as soon as I stopped.
They were not appearing so I decided to verify that Framehawk actually was in use…. And you guessed right. It was NOT activated.

So I was running a “traditional ICA session” without Framehawk over 1800ms latency and was so satisfied with the experience that I thought Framehawk was running!
This shows the how good Thinwire actually are. I also believe that Netscaler did some optimization of the ICA traffic.

I decided that I would keep this session running and start the presentation by showing the audience how I was able to use XenApp on the boat over a satellite connection without telling them that we weren’t running Framehawk.

The presentation went really well, and we played around with different values using the “portable datasenter” simulating latency and packet loss and as you probably can imagine I now had even more data to back up my conclusions that Framehawk is more useful when we have packet loss than only with latency.

So how did I come to that conclusion to begin with?

Well, as I said earlier I built an environment and tested out many combinations of latency and each latency was tested with 0, 5 and 10% packet loss

While comparing only latency it was first at 600ms where I felt that it would be worth changing to Framehawk when running the video.

I have posted a video below that shows a few of my tests. I disconnected the sessions between every change in the wan emulator.
It is important to note that the infintyworm video used in this test is only to show cadence.

My opinion at this time is that if we are only experiencing latency we might be well off with Thinwire (at least on 2012R2 or windows 8/10 where we have Thinwire Compatibility Mode) but as soon as we have more than 3% packet loss we would need Framehawk to get a smoother user experience.

In my test where I compared only latency we could see a marginal improvement with Framehawk first at 600ms. But this was a running a video, which means a traditional user who sits in outlook, word etc would still only need Thinwire during those conditions and save bandwith, and CPU usage. After all, I have just done that with a 1800ms latency.

When it came to packet loss, I saw an improvement while running the video already at 100ms latency with 5% packet loss, then again with 1ms latency and 5% packet loss Thinwire was actually a better experience as you can see in the video below

This is a new technology in the HDX stack, and there will be improvements in the future

Note: Stephen Vilke, Director of Citrix Media Lab in San Francisco, advises that the infiniteworm test app written by his team is actually a test of cadence. The worm should roll all the way through the center, every time.

 

 

 

 

No comments yet.

Leave a Comment

Blue Captcha Image
Refresh

*