Ferrarier och lastbilssläp

När man arbetar i SMB-världen är det faktiskt ganska sällsynt att vi behöver tala om latens. SMB-världen är så gott som universellt fokuserad på systemets genomströmning och i allmänhet omedveten om latens som ett behov. Men det finns tillfällen då latens blir viktigt och när det gör det är det avgörande att vi förstår samspelet mellan genomströmning och latens och just vad “hastighet” betyder för oss. När vi väl börjar röra oss in i företagsutrymmet kommer latens oftare att betraktas som en angelägenhet, men även där härskar genomströmning nästan alltid suveränt, till den grad att begrepp om hastighet så gott som universellt kretsar kring genomströmning och begrepp om latens ofta ignoreras eller glöms bort.

Att förstå latensens roll i ett system kan vara komplicerat, även om latens i sig är relativt enkel att förstå.

En utmärkt jämförelse mellan latens och genomströmning som jag gillar att använda är idén om en Ferrari och ett lastbilssläp. Ferrarier är “snabba” i traditionell mening, de har ett högt antal “miles per timme”. Man skulle kunna säga att de är konstruerade för hastighet. Men är de det?

Vi betraktar i allmänhet lastbilssläp som långsamma. De är stora och otympliga bjässar med en låg topphastighet. Men de fraktar en massa saker på en gång.

I datatermer tänker vi normalt på hastighet som fraktkapacitet – vi tänker i termer av “objekt” per sekund. I en Ferraris termer är det fantastiskt att åka tvåhundra miles per timme, men den kan kanske frakta en låda i taget. Ett lastbilssläp kan bara åka hundra miles per timme men kan frakta närmare tusen lådor i taget. När vi talar om genomströmning eller hastighet på en dator är det mer detta vi tänker på. I nätverkstermer tänker vi på gigabyte per sekund och är sällan bekymrade över hastigheten hos ett enskilt paket eftersom ett enskilt paket sällan är viktigt. I beräkningstermer tänker vi på idéer som flyttalsoperationer per sekund, ett liknande begrepp. Ingen bryr sig egentligen om hur lång tid en enskild FLOP (flyttalsoperation) tar, bara hur många vi kan få gjorda på en eller tio sekunder.

Så när vi tittar på en Ferrari skulle vi kunna säga att den har en användbar hastighet av tvåhundra låd-miles per timme. Det innebär att för varje timmes drift kan en Ferrari förflytta en låda upp till tvåhundra miles. Ett lastbilssläp har en användbar hastighet av hundratusen låd-miles per timme. När det gäller att flytta omkring paket är ett lastbilssläps genomströmning med lätthet femhundra gånger “snabbare” än en Ferraris.

Så i termer av hur vi normalt tänker på datorer och nätverk skulle ett lastbilssläp vara “snabbt” och en Ferrari skulle vara “långsam”.

Men det finns även latens att överväga. Förutsatt att vår last är liten, säg ett brev eller en liten låda, kan en Ferrari förflytta den lådan över tusen miles på bara fem timmar! Ett lastbilssläp skulle ta tio timmar att göra samma resa (men skulle kunna ha EN MASSA brev som alla anländer på en gång). Om det vi behöver är att få ett meddelande eller ett litet paket från en plats till en annan mycket snabbt är Ferrarin det bättre valet eftersom den har hälften så stor latens (fördröjning) från det att vi initierar leveransen tills det första paketet levereras än vad lastbilssläpet har.

Som du kan föreställa dig är lastbilssläp i de flesta fall vida mer praktiska eftersom deras leveranshastighet är så mycket högre. Och eftersom det förhåller sig så ser vi faktiskt stora lastbilar på motorvägarna hela tiden och förekomstfrekvensen av Ferrarier är mycket låg – trots att var och en kostar ungefär lika mycket att köpa (mycket grovt räknat). Men i särskilda fall är Ferrarin mer logisk. Bara inte särskilt ofta.

Detta är ett generellt begrepp och kan tillämpas på flera olika tillämpningar. Det gäller cachningssystem, minne, CPU, nätverk, operativsystemskärnor och schemaläggare, bilar och mer. Latens och genomströmning är i allmänhet omvänt relaterade – vi ger upp latens för att uppnå genomströmning. För de flesta operationer är detta mest logiskt. Men ibland är det mer logiskt att trimma för latens.

Lagring är faktiskt en udda fågel inom databehandling där så gott som allt fokus på lagringsprestanda kretsar kring IOPS, vilket är ungefär ett indirekt mått på latens, i stället för genomströmning som mäts i ”överförd data per sekund”. Sällan bryr vi oss om denna andra siffra eftersom den så gott som aldrig är källan till lagringsflaskhalsar. Men detta är undantaget, inte regeln.

Latens och genomströmning kan ha några överraskande interaktioner i databehandlingsvärlden. När vi talar om nätverk, till exempel, mäter vi vanligtvis endast genomströmning (Gb/s) men bryr oss sällan särskilt mycket om latensen (normalt mätt i millisekunder). Vanligtvis beror detta på att så gott som alla nätverkssystem har liknande latenssiffror och de flesta tillämpningar är i stort sett obekymrade över latensfördröjningar. Det är endast i den sällsynta tillämpningen som VoIP över internationella länkar eller satellit där latens påverkar den genomsnittliga personen eller ibland kan överraska människor när de försöker sig på något ovanligt som iSCSI över en lång WAN-anslutning och plötsligt dyker latens upp för att överraska dem som ett oförutsett problem.

En av de platser där interaktionen mellan latens och genomströmning börjar bli chockerande och intressant är när vi går från elektriska eller optiska datanätverk till fysiska sådana. Ett berömt citat i branschen lyder:

Underskatta aldrig bandbredden hos en herrgårdsvagn full av band som rusar fram längs motorvägen.

Detta är en utmärkt demonstration av enorm bandbredd med mycket hög latens. Genom att köra femtio miles tvärs över staden skulle en enda herrgårdsvagn eller SUV kunna frakta hundratals petabyte data och nå datahastigheter som 10 GB/s fiber inte ens skulle komma i närheten av. Men tiden för det första datapaketet att anlända är ungefär en timme. Vi avfärdar ofta den här typen av nätverk eftersom vi antar att latens måste vara begränsad till under ungefär 500 ms. Men så är inte alltid fallet.

Australien hamnade nyligen i nyheterna när de utförde ett test för att se om en duva som bar ett SD-kort kunde, i termer av nätverksgenomströmning, överträffa regionens internetleverantör – och duvan slutade med att vara snabbare än internetleverantören!

I termer av databehandlingsprestanda ignorerar vi ofta latens till den grad att vi inte ens är medvetna om den som ett sammanhang inom vilket prestanda kan diskuteras. Men i kretsar för databehandling med låg latens beaktas den mycket noggrant. Systemets genomströmning reduceras i allmänhet kraftigt (det blir vanligt att rikta in system på att endast nå tio procents CPU-utnyttjande när mer traditionella system riktar in sig på närmare nittio procent) med begrepp som realtidskärnor, CPU-affinitet, processorlåsning, cacheträffkvoter och sänkt mätning som alla används för att fokusera på att uppnå den mest omedelbara respons som är möjlig från ett system snarare än att försöka få ut mest total bearbetning ur ett system.

Vanliga platser där låg latens ur ett beräkningsperspektiv är önskvärd är i kritiska styrsystem (såsom tillverkningsstyrsystem där till och med en millisekunds latens kan orsaka problem på fabriksgolvet) eller i finansiella handelssystem där några millisekunders fördröjning kan medföra att investeringar har ändrats i pris eller att produkter redan har sålts och inte längre är tillgängliga. Hastighet, i termer av latens, är ofta den avgörande faktorn mellan att tjäna pengar eller förlora pengar – till och med en enda millisekund kan vara förödande.

Tekniskt sett måste även ljud- och videobehandlingssystem vara latenskänsliga men de flesta moderna databehandlingssystem har så mycket bearbetningsöverskott att avvara och latensen är i allmänhet tillräckligt låg för att de flesta system, även VoIP-PBX:er och konferenssystem, kan fungera idag med endast mycket sällan ett behov av att vara medvetna om latensangelägenheter på bearbetningssidan (även nätverkslatens blir mer och mer ovanlig som en angelägenhet). Den genomsnittliga systemadministratören eller ingenjören kan lätt klara av att gå igenom en hel karriär utan att någonsin behöva arbeta på ett system som är latenskänsligt eller för vilket det inte finns så mycket tillgängligt överskott att det döljer all latenskänslighet.

Att definiera hastighet, vare sig det betyder genomströmning, latens eller till och med något annat eller någon kombination av de två, är något som är mycket viktigt i alla aspekter av IT och i livet. Att förstå hur de påverkar oss i olika situationer och hur de reagerar på varandra, med dem i allmänhet existerande i en indirekt relation där förbättringar i genomströmning kommer till en kostnad för latens eller vice versa, och att lära sig balansera dessa efter behov för att förbättra de system som vi arbetar på är mycket värdefullt.