Ferrari’s en vrachtwagens

In de wereld van het MKB komt het eigenlijk vrij zelden voor dat we het over latentie moeten hebben. De MKB-wereld is vrijwel universeel gericht op systeemdoorvoer en over het algemeen onbewust van latentie als een behoefte. Maar er zijn momenten waarop latentie belangrijk wordt en wanneer dat gebeurt, is het cruciaal dat we de wisselwerking tussen doorvoer en latentie begrijpen en wat “snelheid” voor ons betekent. Zodra we ons in de enterprise-ruimte begeven, zal latentie vaker als een zorg worden beschouwd, maar zelfs daar heerst doorvoer vrijwel altijd oppermachtig, in die mate dat begrippen van snelheid vrijwel universeel om doorvoer draaien en begrippen van latentie vaak worden genegeerd of vergeten.

Het begrijpen van de rol van latentie in een systeem kan ingewikkeld zijn, ook al is latentie zelf relatief eenvoudig te begrijpen.

Een mooie vergelijking tussen latentie en doorvoer die ik graag gebruik, is het idee van een Ferrari en een vrachtwagen. Ferrari’s zijn “snel” in de traditionele zin; ze hebben een hoog aantal “mijlen per uur.” Men zou kunnen zeggen dat ze ontworpen zijn voor snelheid. Maar is dat wel zo?

We beschouwen vrachtwagens over het algemeen als langzaam. Het zijn grote, logge beesten met een lage topsnelheid. Maar ze vervoeren een hoop spullen in één keer.

In computertermen denken we bij snelheid normaal gesproken aan vervoerscapaciteit – we denken in termen van “items” per seconde. In de termen van een Ferrari is tweehonderd mijl per uur rijden geweldig, maar hij kan misschien één doos per keer vervoeren. Een vrachtwagen kan slechts honderd mijl per uur rijden, maar kan in de buurt van duizend dozen per keer vervoeren. Wanneer we het over doorvoer of snelheid op een computer hebben, is dit meer waar we aan denken. In netwerktermen denken we aan gigabytes per seconde en houden we ons zelden bezig met de snelheid van een afzonderlijk pakket, aangezien een enkel pakket zelden van belang is. In rekentermen denken we aan ideeën zoals floating-pointbewerkingen per seconde, een soortgelijk concept. Niemand maalt er werkelijk om hoe lang een enkele FLOP (floating-pointbewerking) duurt, alleen hoeveel we er in één of tien seconden gedaan kunnen krijgen.

Dus wanneer we naar een Ferrari kijken, zouden we kunnen zeggen dat hij een nuttige snelheid heeft van tweehonderd doos-mijlen per uur. Dat wil zeggen dat een Ferrari voor elk uur werking één doos tot tweehonderd mijl kan verplaatsen. Een vrachtwagen heeft een nuttige snelheid van honderdduizend doos-mijlen per uur. In termen van het rondbrengen van pakketten is de doorvoer van de vrachtwagen met gemak vijfhonderd keer “sneller” dan die van de Ferrari.

Dus in termen van hoe we normaal gesproken over computers en netwerken denken, zou een vrachtwagen “snel” zijn en een Ferrari “langzaam.”

Maar er is ook latentie om rekening mee te houden. Ervan uitgaande dat onze lading klein is, bijvoorbeeld een brief of een kleine doos, kan een Ferrari die ene doos in slechts vijf uur over meer dan duizend mijl verplaatsen! Een vrachtwagen zou tien uur nodig hebben om diezelfde reis te maken (maar zou een GROOT aantal brieven tegelijk kunnen laten arriveren). Als wat we nodig hebben is om een bericht of een klein pakket zeer snel van de ene plaats naar de andere te krijgen, is de Ferrari de betere keuze omdat hij de helft van de latentie (vertraging) heeft tussen het moment waarop we de bezorging initiëren en het moment waarop het eerste pakket wordt bezorgd, in vergelijking met de vrachtwagen.

Zoals u zich kunt voorstellen, zijn vrachtwagens in de meeste gevallen veel praktischer omdat hun bezorgsnelheid zoveel hoger is. En, dit zijnde het geval, zien we de hele tijd grote vrachtwagens op de snelwegen en is het vóórkomen van Ferrari’s zeer laag – ook al kosten ze elk ongeveer evenveel om aan te schaffen (zeer ruw genomen). Maar in bijzondere gevallen is de Ferrari logischer. Alleen niet erg vaak.

Dit is een algemeen concept en het kan op talloze toepassingen van toepassing zijn. Het is van toepassing op cachingsystemen, geheugen, CPU, netwerken, kernels en schedulers van besturingssystemen, op auto’s en meer. Latentie en doorvoer zijn over het algemeen omgekeerd gerelateerd – we geven latentie op om doorvoer te verkrijgen. Voor de meeste bewerkingen is dit het meest zinvol. Maar soms is het zinvoller om af te stemmen op latentie.

Opslag is eigenlijk een vreemde eend in de bijt binnen de informatica, waar vrijwel alle aandacht voor opslagprestaties zich richt op IOPS, wat ruwweg een proxymeting voor latentie is, in plaats van op doorvoer, die wordt gemeten in “overgedragen data per seconde”. Zelden geven we om dit tweede getal, aangezien het vrijwel nooit de bron van opslagknelpunten is. Maar dit is de uitzondering, niet de regel.

Latentie en doorvoer kunnen enkele verrassende interacties hebben in de informaticawereld. Wanneer we het over netwerken hebben, meten we bijvoorbeeld doorgaans alleen doorvoer (Gb/s), maar geven we zelden veel om de latentie (normaal gesproken gemeten in milliseconden). Dit komt doorgaans doordat vrijwel alle netwerksystemen vergelijkbare latentiecijfers hebben en de meeste toepassingen zich vrijwel niet bekommeren om latentievertragingen. Het is alleen bij de zeldzame toepassing zoals VoIP over internationale verbindingen of satelliet waar latentie de gemiddelde persoon raakt, of die mensen soms kan verrassen wanneer ze iets ongebruikelijks proberen zoals iSCSI over een WAN-verbinding over lange afstand en latentie plotseling opduikt om hen te verrassen als een onvoorzien probleem.

Een van de plaatsen waar de interactie tussen latentie en doorvoer schokkend en interessant begint te worden, is wanneer we van elektrische of optische datanetwerken naar fysieke overstappen. Een beroemd citaat in de branche luidt:

Onderschat nooit de bandbreedte van een stationwagen vol tapes die over de snelweg raast.

Dit is een geweldige demonstratie van enorme bandbreedte met zeer hoge latentie. Door vijftig mijl door de stad te rijden, zou een enkele stationwagen of SUV honderden petabytes aan data kunnen vervoeren en datasnelheden halen waar 10GB/s-glasvezel niet eens in de buurt zou kunnen komen. Maar de tijd voordat het eerste datapakket arriveert, bedraagt ongeveer een uur. We rekenen dit soort netwerk vaak niet mee omdat we aannemen dat latentie begrensd moet zijn op onder de ongeveer 500ms. Maar dat is niet altijd het geval.

Australië haalde onlangs het nieuws toen er een test werd gedaan om te zien of een duif die een SD-kaart droeg, in termen van netwerkdoorvoer, de ISP van de regio kon overtreffen – en de duif bleek uiteindelijk sneller te zijn dan de ISP!

In termen van computerprestaties negeren we latentie vaak tot op het punt dat we ons er niet eens van bewust zijn als een context waarin prestaties besproken kunnen worden. Maar in kringen van lage-latentie-computing wordt er zeer zorgvuldig over nagedacht. De systeemdoorvoer wordt over het algemeen sterk verlaagd (het wordt gangbaar om systemen erop te richten slechts tien procent CPU-benutting te halen, terwijl meer traditionele systemen mikken op dichter bij negentig procent) met concepten zoals realtime-kernels, CPU-affiniteit, processor-pinning, cache-hitratio’s en verlaagde meting, die allemaal worden ingezet om te focussen op het verkrijgen van de meest onmiddellijke respons die mogelijk is uit een systeem, in plaats van te proberen de meest totale verwerking uit een systeem te halen.

Gangbare plaatsen waar lage latentie vanuit een computationeel perspectief gewenst is, zijn kritieke controllersystemen (zoals productiecontrollers, waar zelfs een milliseconde latentie problemen op de fabrieksvloer kan veroorzaken) of in financiële handelssystemen, waar enkele milliseconden vertraging ertoe kunnen leiden dat beleggingen van prijs zijn veranderd of dat producten reeds zijn verkocht en niet langer beschikbaar zijn. Snelheid, in termen van latentie, is vaak de doorslaggevende factor tussen geld verdienen of geld verliezen – zelfs een enkele milliseconde kan verlammend werken.

Technisch gezien moeten zelfs audio- en videoverwerkingssystemen latentiegevoelig zijn, maar de meeste moderne computersystemen hebben zoveel reserve aan verwerkingsoverhead en de latentie is over het algemeen laag genoeg dat de meeste systemen, zelfs VoIP-PBX’en en conferentiesystemen, tegenwoordig kunnen functioneren terwijl ze zich slechts zeer zelden bewust hoeven te zijn van latentiezorgen aan de verwerkingskant (zelfs netwerklatentie wordt steeds minder een zorg). De gemiddelde systeembeheerder of -engineer zou gemakkelijk een hele carrière kunnen doorlopen zonder ooit aan een systeem te hoeven werken dat latentiegevoelig is of waarvoor er niet zoveel beschikbare overhead is dat het enige latentiegevoeligheid verbergt.

Het definiëren van snelheid, of dat nu doorvoer, latentie of zelfs iets anders of een combinatie van de twee betekent, is iets wat zeer belangrijk is in alle aspecten van de IT en in het leven. Begrijpen hoe ze ons in verschillende situaties beïnvloeden en hoe ze op elkaar reageren, waarbij ze over het algemeen in een omgekeerd verband bestaan waarbij verbeteringen in doorvoer ten koste gaan van latentie of andersom, en leren deze naar behoefte in balans te brengen om de systemen waaraan we werken te verbeteren, is zeer waardevol.