HDX.next cuts bandwidth by up to 60%. You read that right: sixty percent!

If you’ve read any of my other posts, you probably know I spend a lot of my time looking at how we can continue to optimize our display remoting technology. A large part of this involves data gathering for key metrics like CPU, memory, and network bandwidth, just to name a few. This data, along with the in-depth analysis that follows, is vital in helping me understand what’s going on under the covers and stimulates new ideas that turn into new algorithms, or perhaps tweaks to existing ones.

Bandwidth usage is one metric to which I pay close attention. A lower bandwidth profile usually means lower costs, especially if you’re on a 4G/LTE or pay-for-capacity network. Another way to think about it is being able to get more users on the same size pipe. Either way, using less is a great thing from a cost perspective. And on a constricted pipe, it can also improve the user experience, since we don’t need to send as much data for the same screen updates.

Normally, if I’m looking to make bandwidth improvements, I’d be quite happy with a 5% reduction release-on-release and zero-change in the other metrics.

10%, and it becomes something to shout about, especially if everything else stays the same.

Any higher, and there’s usually a trade-off: better compression often means more CPU and/or memory. Basically, the more we try and squeeze the data, the more likely it is for users to be squeezed off the box. And ultimately, that’s question we _always_ ask ourselves when looking to improve graphics: how do the changes affect server scalability? There’s no point trying to save bandwidth if it means your users – or indeed your wallet – have to suffer.

So, if I now told you we’ve managed to achieve a bandwidth reduction of up to 60% (yes, sixty) for typical desktop workloads, you might think that:

(a) I’m talking nonsense – 60% is just crazy and I’ve got my figures wrong, especially after all I’ve just been saying;

(b) The graphics are so heavily compressed they must look like they’re being generated by a BBC Micro (or a ZX for those in the Spectrum camp);

or,

(c) IT now have to buy 2x more hardware to handle the users who can no longer fit on the same server.

In case you were thinking any of those, well, the short answer is: (a) no, (b) no and (c) you guessed it, no. Let me clarify:

Up to 60% reduction in bandwidth for typical desktop workloads

AND no loss in image quality

AND — you’ll like this one —  the same, if not MORE, users on the same box!

Put this bandwidth reduction together with Adaptive Transport (also reaching General Availability in our upcoming release) and you have a one-two knockout punch: less data to send plus an enlightened transport layer that gets the data to the other end faster. While maintaining image quality. And potentially better scalability.

Scalability unaffected, and in some cases improved

That last one was probably the most surprising result for me. In making the improvements to bandwidth, I knew I had also made some significant CPU savings, but I didn’t think it’d actually make a measurable difference to server scalability since there are always other factors at play in a multi-user system and the HDX Graphics component is only a very small part of this. This was something the Scalability team here at Citrix found when testing the changes at scale.

I’ll share a couple of their charts showing total bandwidth usage throughout the entire LoginVSI “TaskWorker” workload run (more details of this test here). Both charts show how bandwidth usage (i.e., the amount of data the server is transmitting) increases as more users log on over time, with and without the improvements, on exactly the same hardware.

Firstly, Windows Server 2012R2:

And next, Windows Server 2016:

In both cases, the orange line (HDX.next) sits comfortably below the blue line (HDX in 7.12). With Server 2016, LoginVSI reported 6% more users before the system became saturated, making it a double win: more users on the same box AND much lower bandwidth. We also tested XenDesktop on Windows 10.1 and saw a 28% reduction in overall bandwidth without impacting server scalability.

Now, the good news: these improvements are scheduled to be in the very next release of XenApp and XenDesktop. Everything will be enabled by default too, so no need to fiddle with policies or registry settings.

No Receiver changes needed

In 2016 and 2017, HDX has been completely redesigned to meet the demands of a cloud-normal enterprise. This improvement only builds up on other recent benefits such as Adaptive Display encoding with H.264, hardware acceleration for H.264 on both client and server, adaptive transport, HTML5 video redirection, Skype optimizations, and more. As icing on the cake, for this latest enhancement, you don’t even need to upgrade your Receivers! These changes are FULLY backwards compatible – how cool is that? (Sorry, inner geek in me showing, I think it’s pretty cool :)).

Looking forward to hearing your feedback!