Convertir des Kio en Go

Un kibioctet vaut exactement 1 024 octets. Le nom a été introduit en 1998 pour que « kilooctet » puisse de nouveau valoir 1 000 — l’habitude n’a jamais tout à fait cédé.

Un gigaoctet vaut un milliard d’octets, au sens décimal qu’emploient les fabricants de disques, les forfaits mobiles et les tailles de vidéo.

Le facteur vaut 0,000001, et à peu près personne ne le trimballe. Arrondi à 0,000001, il s'écarte de 0,39 % — invisible sur de petits nombres, et devenu une unité entière vers 1 000 KiB.

C'est ce chiffre-là qu'il faut connaître avant d'arrondir : pas l'erreur elle-même, mais l'endroit où elle cesse d'être négligeable. En dessous, le facteur court est le bon choix ; au-dessus, servez-vous du champ ci-dessus, qui n'arrondit qu'au moment d'afficher.

Un KiB vaut 1 024 fois l'unité du dessous ; un kB, 1 000. Sur cette page, c'est l'écart entre 0 GB et 0 GB — 2,4 % — et il grandit à chaque palier : négligeable sur une photo, visible sur un disque dur.

Le mystère de l'espace disque manquant tient tout entier là-dedans, et sur cette page il vaut 2,4 %. Un disque vendu en kB contient exactement ce qui est annoncé ; Windows divise ensuite par 1 024 au lieu de 1 000, garde le nom décimal, et affiche 0 GB là où la boîte annonçait 0 GB. macOS compte ces tailles en unités décimales depuis 10.6, d'où le même disque qui paraît de deux tailles sur deux machines — rien n'a disparu et personne n'arrondit : les mêmes octets portent deux noms.

Le côté mesure d’un système web compte en unités binaires parce que les outils qui le produisent le font. Une taille d’objet moyenne vient d’un listage de fichiers, d’un rapport de build ou d’un résumé de compartiment de stockage, et tous divisent par 1 024. Le côté commercial compte en gigaoctets décimaux, parce que c’est ainsi que le transfert a été vendu bien avant que quiconque ait à distinguer les deux, et l’écart est la raison pour laquelle cette conversion existe.

Un objet n’est pas affecté par la différence et un mois de trafic l’est. Un million de requêtes avec une moyenne de 250 Kio fait 256 000 000 000 d’octets, ce qui fait 256 Go. Chercher mille au lieu de 1 024 donne 250 Go, une sous-estimation de six gigaoctets qui s’échelonne exactement avec le trafic : doublez les requêtes et le manque double aussi, et c’est l’écart qui devient visible à la première réconciliation de facture.

L’ordre fiable est de garder tout en octets aussi longtemps que possible. Prenez la taille par objet en kibioctets, multipliez par 1 024 pour avoir des octets, multipliez par le nombre, et seulement ensuite divisez par un milliard. Chaque étape avant la dernière est de l’arithmétique entière et exacte, et la division finale est le seul endroit où une décision d’arrondi doit être prise, ce qui rend l’audit immédiat.

Faire l’inverse — convertir chaque objet en gigaoctets et additionner les résultats — introduit une erreur d’arrondi par item, et le nombre d’items est précisément la quantité qui rend le total grand. Un tableur construit de cette façon peut être à plusieurs pour cent près pour des raisons invisibles dans chaque ligne individuelle, ce qui rend la divergence extrêmement difficile à trouver plus tard, et c’est la leçon qu’aucune cellule isolée n’enseigne mais que la réconciliation de facture finit par imposer.

Les journaux d’accès enregistrent des octets, et non des kibioctets, ce qui est la seule bonne nouvelle dans ce calcul. Le champ octets envoyés est un compte brut par requête, donc sommer la colonne et diviser par un milliard donne des gigaoctets décimaux sans aucune question d’unité. Là où le nombre arrive déjà résumé en Kio — un tableau de bord, un rapport, un message d’un collègue — la conversion doit être appliquée et il vaut la peine de demander ce que le résumé a arrondi, parce que la réponse est rarement à la précision que le résumé prétend.

L’autre chose qu’un journal vous dira qu’une moyenne ne peut pas, c’est la forme de la distribution. Une taille d’objet moyenne de 250 Kio pourrait être dix mille petites réponses et une poignée de très grandes, et une prévision bâtie sur la moyenne aura raison en total et tort sur chaque conséquence opérationnelle — comportement du cache, nombre de connexions, effet d’une limite de taille. Le total est la partie facile, et la distribution est ce qui rend la prévision utile ou dangereuse.

La charge utile n’est pas le transfert. Les en-têtes de réponse ajoutent plusieurs centaines d’octets à chaque requête et sont envoyés que le corps soit en cache ou non, la négociation de protocole coûte des octets sur chaque nouvelle connexion, les redirections transfèrent deux fois, et les requêtes échouées qui ont été réessayées sont comptées pour chaque tentative. Sur un parc de petits objets, cette surcharge peut être une fraction sérieuse du total, et rien de tout cela n’apparaît dans la taille d’objet qu’un listage de stockage rapporte.

Cela mérite d’être énoncé à côté de la correction d’unités parce que les deux tirent dans le même sens et sont faciles à confondre. Si un fournisseur rapporte plus d’usage que le calcul ne le prévoyait, l’écart d’unités en explique 2,4 pour cent et pas davantage. Tout ce qui va au-delà est du trafic que le modèle n’a pas comptabilisé, et le chercher dans l’arithmétique plutôt que dans le motif de requêtes gaspille l’après-midi, parce que la conversion est exacte et que le trafic est en réalité plus large que l’hypothèse.

Prenez la taille d’objet moyenne en kibioctets, multipliez par 1 024 pour les octets, multipliez par le nombre de requêtes attendu, et divisez par un milliard. Dix millions de requêtes à 100 Kio font 1 024 000 000 000 d’octets, ce qui fait 1 024 Go, ou 1,024 To. Ce dernier chiffre est un repère de bon sens utile en lui-même : dix millions d’objets de cent kibioctets font presque exactement un téraoctet décimal, et c’est le point de contrôle que la plupart des prévisions peuvent être validées contre en quelques secondes.

Puis appliquez l’incertitude honnêtement. Une prévision qui est précise à quatre chiffres significatifs sur les unités et vague à un facteur deux sur le nombre de requêtes n’a pas été rendue plus précise par la conversion. Énoncez le total comme une fourchette pilotée par l’estimation de trafic, et utilisez le facteur exact pour qu’au moins l’arithmétique n’ajoute pas d’erreur de son propre fait, parce qu’une prévision dont l’incertitude n’est pas visible invite quelqu’un à la traiter comme une mesure et à commander en conséquence.

La réconciliation fonctionne mieux en octets des deux côtés. Convertissez les gigaoctets facturés par le fournisseur en octets en multipliant par un milliard, sommez vos propres comptes d’octets journalisés, et comparez les deux entiers. Toute différence a alors une cause qui mérite d’être nommée plutôt que d’être perdue dans une comparaison entre deux chiffres arrondis aux unités non déclarées, et c’est la procédure qui ferme l’écart sans dispute.

Une divergence d’environ 2,4 pour cent pointe vers l’écart kibioctet-versus-kilooctet quelque part dans la chaîne, d’habitude dans un résumé qui a été produit par un outil binaire et lu comme décimal. Une divergence de 7,4 pour cent pointe vers la même erreur faite un cran de préfixe plus haut. Reconnaître la taille de l’écart est souvent plus rapide que de tracer où il s’est produit, parce que la taille de l’écart vous dit à quel cran regarder en premier.

Deux compteurs différents tournent sur les mêmes objets. Le stockage est facturé à la capacité tenue dans le temps, d’habitude en gigaoctets-mois au prorata de l’heure, donc un objet qui existe tout le mois coûte sa pleine taille et un supprimé le quinze coûte la moitié. Le transfert est facturé au gigaoctet déplacé, donc le même objet ne coûte rien jusqu’à ce que quelqu’un le demande, et coûte alors sa taille à chaque requête qui n’est pas servie depuis un cache, et les deux compteurs méritent d’être regardés.

Les deux compteurs s’expriment en gigaoctets décimaux, ce qui veut au moins dire qu’une conversion couvre les deux. Ce qui diffère est ce que la taille en kibioctets doit être multipliée par : nombre d’objets pour le stockage, nombre de requêtes pour le transfert. Une bibliothèque d’un million d’objets de 250 Kio fait « 256 Go de stockage » chaque mois indépendamment du trafic, et de rien à plusieurs téraoctets d’egress selon la fréquence à laquelle elle est lue, et c’est l’asymétrie qui mérite d’être connue avant de budgéter.

Les quotas de boîtes aux lettres, les allowances de stockage par utilisateur et les limites de réponse d’API sont fréquemment définis en unités binaires par le logiciel qui les applique et communiqués aux utilisateurs en termes décimaux, ou l’inverse. Une allowance de 15 Go appliquée comme 15 Gio donne à chaque utilisateur 1,11 Go de plus que ce que la documentation promet, sur l’ensemble des utilisateurs, et personne ne se plaint — c’est pourquoi cela passe inaperçu pendant des années.

La version qui génère des plaintes est l’inverse. Une allowance annoncée comme 15 Go et appliquée comme 15 000 000 000 d’octets semblera courte à tout utilisateur dont le client rapporte l’usage en gibioctets, parce que ses 14 Gio de courrier font 15,03 Go et ont déjà dépassé. La correction n’est pas plus de capacité ; c’est énoncer l’unité au même endroit que le chiffre, parce que la conversion qui n’est pas faite à l’affichage finit par être faite à la facture, et c’est toujours dans le mauvais sens.