Sinds Windows 2012R2 is Microsoft meer gebruik gaan maken van DirectX voor de grafische opbouw van de desktop, daar waar ze eerder GDI/GDI+ API calls gebruikten. Dit was te merken aan het ICA protocol, wat zwaar geoptimaliseerd was voor GDI en onder Windows 2012R2 een hogere bandbreedte tot gevolg had.

Halverwege dit jaar waren we bij een van onze klanten bezig met een implementatie van XenApp 7.6 op Windows 2012 R2. Helaas had deze klant ook een aantal lage bandbreedte lokaties. De smalste lijnen waren 256kbit en daar moesten ongeveer 7 sessie overheen lopen, wat neerkomt op ongeveer 35 kbit/s per sessie. We hadden de h264 (SuperCodec) compressie al uitgeschakeld omdat deze een veel te hoge bandbreedte veroorzaakte en een hoop optimalisatie toegepast binnen de policies, maar we kregen de lijn niet onder de 150kbit/s. Gemiddeld kwamen we uit rond de 170 kbit/s. De 35 kbit/s leek nooit haalbaar te zijn.

Na wat gebel met Citrix besloten we Project Snowball te omarmen, een project dat zich richtte op optimalisatie van Thinwire binnen het ICA protocol en wat we sinds Feature Pack 3 nu Thinwire Plus noemen. Deze zou de bandbreedte weer moeten verlagen naar een niveau wat eerder onder Windows 2008R2 haalbaar was.

Na installeren van de beta op de testservers bleek dat we de servers moesten dwingen om de compatibiliteitsmodus te kiezen. Een keuze moment, want om dit te doen moesten we de SuperCodec in zijn geheel uitschakelen voor de server voor alle gebruikers die daar op zitten. Daarmee dwing je elke sessie om Thinwire te gebruiken, ook daar waar de lijnen bandbreedte genoeg hebben en de SuperCodec wel gebruikt kan worden. Dit gebeurd door de volgende registry key door te voeren:

• HKLM\Software\Citrix\Graphics
  • Name: encoder
  • Type: reg_dword
  • Value: 0

Daarnaast werd ook in de policy de Progressive Compression Level naar Medium gezet, zoals in de richtlijnen voor Thinwire Plus stond aangegeven.

De eerste resultaten waren super. Direct na het installeren van Thinwire Plus daalde de gemiddelde bandbreedte al met 50% naar 83 kbit/s.

 

Na verdere tuning van alle onderdelen was het zelfs mogelijk om nog verder naar beneden te gaan. Daarvoor moesten wel enkele extreme maatregelen genomen worden voor de mensen op lage bandbreedte. De onderstaande instellingen werden gemaakt om de bandbreedte verder te reduceren. In het oog valt de target framerate die naar 15fps is gezet en het gebruik van 16bit kleuren werd doorgevoerd. Als laatste is een beperking per sessie van bandbreedte opgelegd van maximum 150 kbps.

• Maximum allowed color depth: 16 bits per level. (reductie van 10-15% aan bandbreedte, alleen voor hele server in te schakelen)
• Allow Visual Lossless compression: Disabled
• Audio over UDP: Disabled
• Client audio redirection: Disabled
• Client microfoon redirection: Disabled
• Desktop Composition Redirection: Disabled (voorkomt dat DCR de voorkeur krijgt boven Enhanced ThinWire)
• Desktop Wallpaper: Disabled (zorgt voor egale achtergrond kleur)
• Extra color compression: Enabled (reductie bandbreedte, verhoogde server cpu)
• Extra color space threshold: 8192 kbs (default)
• Heavyweight Compression: Enabled
• Lossy Compression Level: High
• Lossy compression threshold: 2147483647 Kbps (default)
• Menu animation: Prohibited (reductie bandbreedte door geen gebruik menu animaties)
• Minimum Image Quality: Low (altijd extra compressie toepassen boven scherper beeld)
• Moving image compression: Enabled
• Optimization for Windows Media redirection over WAN: Disabled (voorkomt WMV over de WAN richting de client)
• Overall Session bandwidth limit: 150 Kbps (maximum bandbreedte per sessie)
• Progressive compression level: medium (verplicht voor de enhanced thinwire)
• Progressive compression threshold: 2147883647 Kbps (default)
• Target frame rate: 15 fps
• Target minimum frame rate: 10 fps (default)

Na doorvoeren van deze policy kwam in de testsituatie het gemiddelde op 16 kbit/s. Een waarde die we in het begin absoluut niet dachten te gaan halen. In de gebruikerstesten kwam naar voren dat er nog goed gewerkt kon worden op de omgeving, ondanks alle beperkingen die we in de policy hadden opgelegd.

Na alles doorgevoerd te hebben in de productie omgeving zien we dat een gemiddelde sessie nu rond de 30 kbit/s gebruikt. Iets meer dan in de testomgeving, maar zeker geen waarden waar we over klagen. De gebruikers kunnen er goed mee werken en zijn tevreden.

Overigens kwamen we er bij testen achter dat bij een passthrough applicatie (waarbij gebruikers eerst verbinden naar een gepubliceerde desktop en daarna een gepubliceerde applicatie op een andere server starten), de Thinwire Plus configuratie op beide servers actief moet zijn. Als we dat niet deden zagen we het bandbreedte verbruik naar de client weer flink toenemen.

(al mijn collega’s bedankt voor het aanleveren van de performance metingen!)

 

Note: De registrykey is vermoedelijk niet meer nodig. Na het updaten van de Citrix Group Policies is het mogelijk om deze instelling binnen een GPO te maken. Zie daarvoor ook https://www.citrix.com/blogs/2015/10/09/a-big-leap-in-ica-protocol-innovation-for-citrix/