Ferraris et semi-remorques

Dans le monde des PME, il est en réalité assez rare que nous ayons besoin de parler de latence. Le monde des PME est presque universellement axé sur le débit des systèmes et généralement peu conscient de la latence en tant que besoin. Mais il y a des moments où la latence devient importante et, lorsque c'est le cas, il est essentiel que nous comprenions l'interaction entre le débit et la latence et ce que la “vitesse” signifie réellement pour nous. Une fois que nous commençons à évoluer dans l'espace de l'entreprise, la latence sera plus souvent considérée comme une préoccupation, mais même là, le débit règne presque toujours en maître, au point que les notions de vitesse tournent presque universellement autour du débit et que les notions de latence sont souvent ignorées ou oubliées.

Comprendre le rôle de la latence dans un système peut être compliqué, même si la latence elle-même est relativement simple à comprendre.

Une excellente comparaison entre la latence et le débit que j'aime utiliser est l'image d'une Ferrari et d'une semi-remorque. Les Ferraris sont “rapides” au sens traditionnel : elles ont un grand nombre de “milles à l'heure”. On pourrait dire qu'elles sont conçues pour la vitesse. Mais le sont-elles ?

Nous considérons généralement les semi-remorques comme lentes. Ce sont de grosses bêtes pataudes dont la vitesse de pointe est faible. Mais elles transportent une grande quantité de marchandises à la fois.

En termes informatiques, nous concevons normalement la vitesse comme une capacité de transport – nous raisonnons en termes d'“éléments” par seconde. Pour ce qui est d'une Ferrari, rouler à deux cents milles à l'heure est formidable, mais elle ne peut transporter qu'une seule boîte à la fois, peut-être. Une semi-remorque ne peut rouler qu'à cent milles à l'heure, mais elle peut transporter près de mille boîtes à la fois. Lorsque nous parlons de débit ou de vitesse sur un ordinateur, c'est davantage à cela que nous pensons. En termes de réseau, nous pensons en gigaoctets par seconde et nous nous préoccupons rarement de la vitesse d'un paquet individuel, car un paquet unique a rarement de l'importance. En termes de calcul, nous pensons à des notions comme les opérations en virgule flottante par seconde, un concept similaire. Personne ne se soucie réellement du temps que prend un seul FLOP (opération en virgule flottante), mais seulement du nombre que nous pouvons en exécuter en une ou dix secondes.

Ainsi, en examinant une Ferrari, nous pourrions dire qu'elle a une vitesse utile de deux cents boîtes-milles à l'heure. Cela signifie que, pour chaque heure de fonctionnement, une Ferrari peut déplacer une boîte sur une distance allant jusqu'à deux cents milles. Une semi-remorque a une vitesse utile de cent mille boîtes-milles à l'heure. En termes de déplacement de colis, le débit de la semi-remorque est facilement cinq cents fois “plus rapide” que celui de la Ferrari.

Donc, selon la manière dont nous concevons habituellement les ordinateurs et les réseaux, une semi-remorque serait “rapide” et une Ferrari serait “lente”.

Mais il y a aussi la latence à prendre en compte. En supposant que notre charge utile soit minuscule, disons une lettre ou une petite boîte, une Ferrari peut déplacer cette unique boîte sur plus de mille milles en seulement cinq heures ! Une semi-remorque mettrait dix heures à accomplir ce même trajet (mais elle pourrait avoir BEAUCOUP de lettres arrivant toutes en même temps). Si ce dont nous avons besoin est d'acheminer un message ou un petit colis d'un endroit à un autre très rapidement, la Ferrari est le meilleur choix, car elle présente la moitié de la latence (du délai) entre le moment où nous lançons la livraison et celui où le premier colis est livré par rapport à la semi-remorque.

Comme vous pouvez l'imaginer, dans la plupart des cas, les semi-remorques sont infiniment plus pratiques, car leur vitesse de livraison est tellement plus élevée. Et, cela étant, nous voyons effectivement de gros camions sur les autoroutes en permanence, tandis que le taux d'apparition des Ferraris est très faible – même si chacun coûte à peu près le même montant à l'achat (très grossièrement). Mais dans des cas particuliers, la Ferrari a davantage de sens. Simplement pas très souvent.

Il s'agit d'un concept général qui peut s'appliquer à de nombreuses applications. Il s'applique aux systèmes de cache, à la mémoire, au processeur, au réseau, aux noyaux et aux ordonnanceurs des systèmes d'exploitation, aux voitures et plus encore. La latence et le débit sont généralement inversement liés – nous renonçons à la latence afin d'obtenir du débit. Pour la plupart des opérations, c'est ce qui a le plus de sens. Mais il arrive parfois qu'il soit plus judicieux d'optimiser pour la latence.

Le stockage est en réalité un cas atypique dans l'informatique, où la quasi-totalité de l'attention portée aux performances de stockage se concentre sur les IOPS, qui constituent à peu près une mesure indirecte de la latence, plutôt que sur le débit, lequel se mesure en « données transférées par seconde ». Il est rare que nous nous soucions de ce second nombre, car il n'est presque jamais à l'origine des goulets d'étranglement du stockage. Mais c'est là l'exception, et non la règle.

La latence et le débit peuvent présenter des interactions surprenantes dans le monde informatique. Lorsque nous parlons de réseaux, par exemple, nous ne mesurons généralement que le débit (Gb/s), mais nous nous soucions rarement beaucoup de la latence (normalement mesurée en millisecondes). Cela tient généralement au fait que la quasi-totalité des systèmes de réseau présentent des valeurs de latence similaires et que la plupart des applications sont à peu près indifférentes aux délais de latence. Ce n'est que dans de rares applications comme la VoIP sur des liaisons internationales ou le satellite que la latence affecte le citoyen moyen, ou qu'elle peut parfois surprendre les gens lorsqu'ils tentent quelque chose d'inhabituel, comme l'iSCSI sur une connexion WAN de longue distance, et que la latence surgit soudainement pour les surprendre comme un problème imprévu.

L'un des cas où l'interaction de la latence et du débit commence à devenir étonnante et intéressante survient lorsque nous passons des réseaux de données électriques ou optiques à des réseaux physiques. Une célèbre citation dans l'industrie est :

Ne sous-estimez jamais la bande passante d'un break rempli de bandes magnétiques fonçant sur l'autoroute.

Voilà une excellente démonstration d'une bande passante énorme assortie d'une très forte latence. En parcourant cinquante milles à travers la ville, un seul break ou SUV pourrait transporter des centaines de pétaoctets de données, atteignant des débits que de la fibre à 10 Gb/s ne pourrait approcher de loin. Mais le temps d'arrivée du premier paquet de données est d'environ une heure. Nous écartons souvent ce type de réseau parce que nous supposons que la latence doit être plafonnée à moins de 500 ms environ. Mais ce n'est pas toujours le cas.

L'Australie a récemment fait l'actualité en réalisant un test pour voir si un pigeon transportant une carte SD pouvait, en termes de débit réseau, surpasser le FAI de la région — et le pigeon s'est finalement révélé plus rapide que le FAI !

En matière de performances informatiques, nous ignorons souvent la latence au point de ne même pas en être conscients comme d'un cadre dans lequel discuter de la performance. Mais dans les cercles de l'informatique à faible latence, elle est prise en compte avec grand soin. Le débit des systèmes est généralement fortement réduit (il devient courant de cibler des systèmes ne dépassant que dix pour cent d'utilisation du processeur, alors que des systèmes plus traditionnels visent plutôt quatre-vingt-dix pour cent) avec des concepts comme les noyaux temps réel, l'affinité processeur, l'épinglage de processeur (processor pinning), les taux de succès de cache (cache hit ratios) et l'abaissement des mesures, tous employés pour se concentrer sur l'obtention de la réponse la plus immédiate possible d'un système plutôt que de chercher à en tirer le traitement total maximal.

Les cas courants où une faible latence du point de vue computationnel est recherchée se rencontrent dans les systèmes de contrôle critiques (tels que les contrôleurs de fabrication, où ne serait-ce qu'une milliseconde de latence peut causer des problèmes sur le plancher de l'usine) ou dans les systèmes de trading financier, où quelques millisecondes de délai peuvent faire que des placements aient changé de prix ou que des produits aient déjà été vendus et ne soient plus disponibles. La vitesse, en termes de latence, est souvent le facteur décisif entre gagner de l'argent ou en perdre — ne serait-ce qu'une seule milliseconde peut être paralysante.

Techniquement, même les systèmes de traitement audio et vidéo doivent être sensibles à la latence, mais la plupart des systèmes informatiques modernes disposent de tellement de marge de traitement excédentaire, et la latence est généralement suffisamment faible, que la plupart des systèmes, même les PBX VoIP et les systèmes de conférence, peuvent fonctionner aujourd'hui en n'ayant que très rarement besoin de se préoccuper des questions de latence côté traitement (même la latence réseau devient une préoccupation de moins en moins fréquente). L'administrateur ou l'ingénieur système moyen pourrait aisément mener toute une carrière sans jamais avoir besoin de travailler sur un système sensible à la latence ou pour lequel la marge disponible ne serait pas suffisamment importante pour masquer toute sensibilité à la latence.

Définir la vitesse, qu'il s'agisse du débit, de la latence, voire d'autre chose ou d'une combinaison des deux, est quelque chose de très important dans tous les aspects de l'informatique et de la vie. Comprendre comment ces éléments nous affectent dans différentes situations et comment ils réagissent l'un à l'autre, en existant généralement dans une relation indirecte où les améliorations du débit se font au détriment de la latence ou inversement, et apprendre à les équilibrer selon les besoins afin d'améliorer les systèmes sur lesquels nous travaillons, est extrêmement précieux.