Accueil > View > optimisation View pour la performance vidéo
Avr/13270

perf_video_viewNous avions déjà abordé le sujet de l’optimisation de VMware View dans un contexte WAN, mais à l’opposé pour certain usage spécifique il peut être nécessaire de faire de l’optimisation pour avoir de bonne performance pour lire des vidéos.

Cet exercice n’est jamais facile car ici on n’est pas dans le meilleur cas d’utilisation du VDI et que c’est un équilibre complexe entre la bande passante et le rendu utilisateur. L’objet de cet article est donc de recenser l’ensemble des bonnes pratiques et des paramètres de tuning pour améliorer le rendu vidéo.

 

Avant de commencer sur les recommandations d’optimisation, il est bon de faire un rappel sur les 3 principaux mécanismes (ou options) permettant d’améliorer le rendu tout en conservant une bande passante acceptable:

  • Text Codec : codec utilisé pour la compression du texte. Il permet de délivrer un contenu texte sans dégradation perceptible par l’utilisateur. Le taux de compression est amélioré par 2 sur les fontes Adobe LCD et ClearType. Le gain en bande passante est de l’ordre de 10 à 20 %.
  • Client-side caching: mise en cache coté client du contenu statique fréquemment utilisé. Lors de déplacement (de fenêtre ou un défilement), le protocole envoie l’adresse et l’emplacement du contenu et non le contenu lui même. Le gain de bande passante est de l’ordre de 30 à 40 %.
  • Disable BTL: désactivation de la transmission de pixels pour la reconstruction d’image jusqu’à la perfection. Cette baisse de qualité est quasiment imperceptible pour les utilisateurs et surtout pas utile pour de la vidéo. Le gain de bande passante est de l’ordre de 10 à 15 %.

L’utilisation de ces mécanismes et donc le rendu varie en fonctions des périphériques utilisé pour ce connecté à un poste de travail virtuel. Le tableau ci-dessous résume la compatibilité entre ces fonctions et les types de client ainsi que la gain en bande-passante attendu en cumulant ces mécanismes:

Soft Client Desktop(Windows, Mac, Linux) Soft Client iDevice(iOS, Android) 1st Gen Zero-Client(Tera1) 2nd Gen Zero-Client(Tera2)
Text CODEC Yes Yes No Yes
Client-side cache Yes No No Yes
Disable BTL Yes Yes Yes Yes
Expected Bandwith Reduction 50-75% 20-30% 10-20% 50-75%

Les recommandations de dimensionnement de la VM desktop:

  • Pour des vidéo en 480px, 1 vCPU est suffisant; en 720px, il faut 2 vCPU; au dela et en plein écran, il peut y avoir des impacts de performance.
  • L’utilisation d’une carte APEX 2800 permet d’offloader le codage des pixels coté serveur. Ce qui veut dire diminuer la consommation CPU des VMs desktop et aussi augmentnter le taux de consolidation VMs desktop / Hôte ESX.
  • La configuration d’une VM desktop pour de bonne perf vidéo est la suivante: OS Windows 7, 2 Go de vRAM, virtual hardware 8/9, carte réseau VMXNET3.
  • Pour la 3D en émulation software, VM en virtual hardware 8 ou 9 / OS Windows 7 ou 8 / Application compatible DirectX 9 ou Open GL 2.1 / maximum 2 écrans en 1920 x 1200, avec une config View 5.1/5.2
  • Pour la 3D avec carte physique partagé sVGA, les cartes supportées Nvidia sont Quadro 4000/5000/6000, Tesla M270Q, VGX 1/2 (Kepler) avec une config vSphere 5.1, virtual hardware 9 et View 5.2
  • respecter le guide d’optimisation pour le VM desktop pour Windows XP / 7 / 8
  • Pour les VMs desktop utilisant une carte réseau VMXNET3, il est recommandé (cf. cette KB Microsoft) de modifier la clé de registre « HKLM/System/CurrentControlSet/Services/Afd/Parameters/FastSendDatagramThreshold » à la valeur 1500

 

Quand l’on parle de performance vidéo, c’est souvent seulement pour LAN, dans un contexte WAN on parlera plutot de rendu vidéo acceptable. Mais il est quand même bon de faire un rappel sur les bonnes-pratiques pour le protocole PCoIP sur le WAN:

  • PCoIP est un protocole temps réel. Ce qui signifie que si mettez en mise en place de QoS/CoS, il faut classifier le traffic PCoIP comme « real-time interactive » (presque comme la VoIP). Au dessus du trafic TPC classique non-temps réel mais en dessous de la VoIP. Généralement, on réserve 10% pour la VoIP et ensuite on donne 80% au PCoIP (soit environ 76,5%) et environ 13,5% pour tout le reste. Il faut aussi s’assurer que l’association QoS/CoS est préservé tout au long du WAN.
  • Préférer l’utilisation de Security Server pour les accès distant. Sinon en VPN, préférer les solutions basées sur du SSL (utiliser IPSEC, L2TP/IPSEC, GRE ou DTLS). Mais surtout de solution VPN qui fait de l’encapsulation du traffic PCoIP (UDP) en TCP.
  • S’assurer que le protocole PCoIP est bypassé sur les périphériques d’accélération WAN et qu’il est bypassé ou trusted sur les solutions IDS/IPS.
  • Préférer les circuits WAN a bande passante fixe plutôt que les circuit « burstable ». Sinon en circuits « burstable », s’assurer que le CIR est assez haut pour tout le trafic priorité (dont l’ensemble du traffic PCoIP). Les opérateurs ont l’habitude de classifier les paquets « burst » en faible priorité.
  • Utiliser WRED comme mécanisme pour éviter la congestion, en temporisant aléatoirement les paquets moins prioritaire ca laisse le temps au PCoIP de s’auto-adapter. Par contre, ne pas configurer WRED sur les interfaces physiques car il risque d’outrepasser les politiques QoS.
  • Ne pas être dans des cas de latences RTT supérieur à 250ms, et même inférieur à 100ms pour des applications 3D (ou pour une meilleur fluidité de la vidéo).
  • Ne pas utiliser de load-balancing par paquet, sinon l’ordre aléatoire de réception des paquets risque de provoquer une perception de packet droppé par le protocole PCoIP (et donc diminition de la bande passante). S’assurer que l’affinité ou le « stickiness » de session sont activé.

 

En fonction des cas d’usages, il est nécessaire d’ajuster la configuration PCoIP pour une cible spécifique. La modification des paramètres PCoIP se fait par GPO à partir le modèle d’administration pcoip.adm (dans c:/Program File/VMware/VMware View/Server/Extras/GroupPolicyFiles sur le Connection Server) ou directement dans la base de registre (HKLM/SOFTWARE/Polices/Teradici/PCoIP/pcoip_admin_defaults/) de la VM desktop.

Voici les paramètres PCoIP à prendre en compte pour optimiser le rendu vidéo:

  • Désactiver le BTL car majoritairement inutile pour de la vidéo. Mettre Turn-off Build-to-Lossless à « activé » et cocher la case « J’accepte de désactiver la fonctionnalité BTL« . Alors que dans la base de registre il faut mettre le paramètre « pcoip.enable_built_to_lossless » à « 0 » pour le désactiver.
  • Client-side cache (configure PCoIP client image cache side policy / pcoip.image_cache_size_mb) activable, valeur par défaut bonne à 250Mo (min 50 / max 450). Attention si le client n’a pas assez de mémoire (ex: ThinClient) cela risque de provoquer des coupure de sessions.
  • pas de Maximum PCoIP session bandwith (defaut 90000Kbps)
  • PCoIP session bandwith floor (0 Kbps) est la bande passante minimum acceptable en cas de congestion. Ne pas avoir peur de le laisser à 0, cela signifie que c’est le protocole qui va lui même définir sa valeur actuel en fonction des conditions réseau.
  • PCoIP session MTU (pcoip.mtu_size) il est souvent nécessaire de diminuer cette valeur pour l’ajuster en fonction de la fragmentation provoquer par le VPN.
  • PCoIP Minimum Image Quality est la compression maximal acceptable en cas de congestion réseau. Une qualité minium entre 30 et 50 permet d’augmenter le FPS pour compenser la baisse de qualité d’image. Une qualité supérieur à 50 risque de provoquer des sauts d’image mais force une meilleur qualité d’image. Le seuil de qualité d’image minimum doit bien entendu être inférieur à la qualité maximum initiale.
  • PCoIP Maximum Initial Quality est la qualité immédiatement (qualité de la première image) envoyé en cas de rafraichissement de l’écran. Une valeur plus élévé provoques des piques de consommation de bande passante. Si vous pensez que la bande passante est la cause, diminuer la MaxInitQual pour améliorer la performance vidéo. On de conserver une valeur supérieur à 70 pour un usage média.
  • PCoIP Maximum Frame Rate (par défaut 30) est la fréquence maximale de rafraichissement de l’affichage en cas de changement. Dans la majorité des cas un FPS max entre 18 à 20 est correct avec un faible impact sur le rendu utilisateur. En revanche pour le rendu vidéo, il faut augmenter ces valeurs pour accentuer la fluidité, surtout ne pas descendre en dessous de la valeur 15 FPS max pour les médias.
  • Bien entendu ne pas désactiver Enable Audio in PCoIP. Par contre, quand il n’y a pas besoin, le désactiver évite d’envoyer du son vide.
  • PCoIP session audio bandwith limit, ne pas mettre cette valeur en dessous de 50Kbps sinon il risque de ne pas y a avoir de son.
  • PCoIP Maximum Link Rate (en bytes/s) est la valeur maximum de la bande passante consommée par une session. La valeur 0 signifie aucune limitation. Cette valeur dépend beaucoup de la bande passante disponible par utilisateur. Sur des faibles liens, on recommande 10%.
  • PCoIP Bandwith Floor (en bytes/s) est la limite basse de bande passante réserver par une session (0 étant sans réservation). Ce paramètre augmente la réactivité du protocole car l’utilisateur n’a pas à attendre que la bande passante devienne disponible pour un besoin accru ponctuel comme par exemple l’ouverture d’une vidéo. Il est important d’avoir bien calculé ce paramètre par rapport au nombre de session et à la bande passante disponible, sinon on risque rapidement de saturé le lien. Quand il y a des pertes de paquet, il faut configurer ce paramètre.

 

Et enfin, pour synthèse, toujours se rappeler que c’est un système de balance entre la bande-passante et le rendu utilisateur. Très souvent les problèmes PCoIP ne viennent pas du protocole mais du contexte, donc toujours commencer par vérifier le réseau et que le modèle de VM est bien optimiser. D’ailleurs pour vérifier simplement les conditions réseau, je vous recommande la partie « PCoIP Session Health » de l’outil PCoIP Config Utility.

 

Quelques ressources intéressantes pour approfondir le sujet:

  1. Pas encore de commentaire
  1. Pas encore de trackbacks