How low can we go with HDX?

Greetings again! If you’ve read any of my previous blogs, you’ll know that I love talking about all things graphics. Indeed, that’s where I spend most of my time, often collaborating with the wider team on how we can go quicker and do things more efficiently.

Most recently, I decided to focus my efforts further “downstream,” at the point where HDX combines all of the virtual channel data (graphics, audio, drive mapping, USB, etc.) into a single stream. Not only do we stuff everything into a single pipe, we compress it at the same time. Think of it as a compactor. Or a bulk compressor. Or whatever squashy thing you like. The point is, HDX does some very clever compression here, and it’s been untouched for years because it’s so darn good.

It’s taken me more than six months to come up with something better. Better isn’t simply a higher compression ratio — that’s easy. Here, better means achieving a higher compression ratio, but not taking forever to do so. Any increase in time spent compressing severely impacts user interactivity and scalability, and that goes against the very grain of HDX.

At this point, you’re probably wondering, “How much better is it?” And, “What’s changed to make it better?”

I can’t help you with the second question (for obvious reasons), but I can with the first, and I’m excited (yes, this stuff really gets me going) to be able to share some of the initial results I’m seeing.

The test was simple: compress a huge ~500MB XML file and record the compressed size. Here’s how long it took:

I’ve highlighted the two rows of particular interest: the prototype compressed the file a further 18 percent! Granted, it took longer (relatively), but in absolute terms, it’s a small increase that shouldn’t make a significant difference in real-world scenarios. That said, I am still optimizing and hope to reduce this gap a little more.

Purely as reference points, I captured data using third-party compression utilities to see how we fared. Surprisingly well, actually *smug mode enabled* (any Red Dwarf fans out there?). I haven’t included decompression times, but take my word: Both the prototype and current HDX (de)compressors are quicker than the rest, and more importantly, on par with each other.

This is all well and good, but what does this mean for Citrix Virtual Apps and Desktops sessions? To find out, I integrated the prototype into HDX and have done two tests so far. I’m seeing a consistent 10 percent reduction in bandwidth in a LoginVSI run with < 0.1 percent increase in overall system CPU cycles.

Comparing us to the major players out there, we are so far ahead in terms of bandwidth consumption it’s almost unreal. My VP once joked, “Muhammad, you’re going to drive down the bandwidth to zero one day.” Even I’m starting to believe him, although I am aware it is technically impossible! 🙂

To convince myself this wasn’t just an improvement in graphics, I decided to do an in-session file transfer from a remote drive to a locally mapped drive in WAN conditions. I figured this might be a typical use case going forward with the move to the cloud. To transfer the same 500MB file took 10 seconds less (64.7s vs 54.9s) with the new algorithm. That means less waiting around so you can be more productive; I can’t wait to get this into the product! Our closest rival comes in at 79.1s and at more than double the bandwidth.

We’re constantly pushing boundaries in HDX, and we never stop challenging ourselves. Staying still simply isn’t good enough. And let’s face it, that would just be downright boring! We’re in the business of delighting our end-users and making them more productive. This very simple concept sits at the core of HDX and the way we work here, at Citrix.

Citrix Tech Bytes – Created by Citrix Experts, made for Citrix Technologists! Learn from passionate Citrix Experts and gain technical insights into the latest Citrix Technologies.

Click here for more Tech Bytes and subscribe.

Want specific Tech Bytes? Let us know! tech-content-feedback@citrix.com.