Ferrari e autoarticolati

Lavorando nel mondo delle PMI, in realtà è piuttosto raro che si debba parlare di latenza. Il mondo delle PMI è quasi universalmente concentrato sul throughput dei sistemi e generalmente inconsapevole della latenza come esigenza. Ma vi sono momenti in cui la latenza diventa importante e quando ciò accade è fondamentale comprendere l'interazione tra throughput e latenza e che cosa significhi davvero per noi la “velocità”. Una volta che ci spostiamo nello spazio enterprise, la latenza sarà più spesso considerata una preoccupazione, ma anche lì il throughput regna quasi sempre sovrano, al punto che i concetti di velocità ruotano quasi universalmente attorno al throughput e i concetti di latenza vengono spesso ignorati o dimenticati.

Comprendere il ruolo della latenza in un sistema può essere complicato, anche se la latenza in sé è relativamente semplice da capire.

Un ottimo confronto tra latenza e throughput che mi piace utilizzare è l'idea di una Ferrari e di un autoarticolato. Le Ferrari sono “veloci” nel senso tradizionale, hanno un elevato numero di “miglia orarie”. Si potrebbe dire che sono progettate per la velocità. Ma è davvero così?

Generalmente consideriamo gli autoarticolati lenti. Sono bestioni grandi e goffi con una bassa velocità massima. Ma trasportano molta roba in una volta sola.

In termini informatici normalmente pensiamo alla velocità come alla capacità di trasporto: ragioniamo in termini di “elementi” al secondo. Nel caso di una Ferrari, andare a duecento miglia orarie è fantastico, ma può trasportare forse una scatola alla volta. Un autoarticolato può andare solo a cento miglia orarie ma può trasportare quasi mille scatole alla volta. Quando parliamo di throughput o velocità su un computer, è più a questo che pensiamo. In termini di rete pensiamo ai gigabyte al secondo e raramente ci preoccupiamo della velocità di un singolo pacchetto, dato che un singolo pacchetto è raramente importante. In termini computazionali pensiamo a idee come le operazioni in virgola mobile al secondo, un concetto simile. A nessuno importa davvero quanto tempo richieda un singolo FLOP (operazione in virgola mobile), ma solo quanti riusciamo a portarne a termine in uno o dieci secondi.

Quindi, guardando una Ferrari, potremmo dire che ha una velocità utile di duecento scatole-miglia all'ora. Cioè, per ogni ora di funzionamento, una Ferrari può spostare una scatola fino a duecento miglia. Un autoarticolato ha una velocità utile di centomila scatole-miglia all'ora. In termini di spostamento di pacchi, il throughput dell'autoarticolato è facilmente cinquecento volte “più veloce” di quello della Ferrari.

Quindi, in termini di come normalmente pensiamo ai computer e alle reti, un autoarticolato sarebbe “veloce” e una Ferrari sarebbe “lenta”.

Ma c'è anche la latenza da considerare. Supponendo che il nostro carico sia minuscolo, diciamo una lettera o una piccola scatola, una Ferrari può spostare quell'unica scatola per oltre mille miglia in appena cinque ore! Un autoarticolato impiegherebbe dieci ore per compiere lo stesso viaggio (ma potrebbe avere MOLTE lettere che arrivano tutte insieme). Se ciò di cui abbiamo bisogno è far arrivare un messaggio o un piccolo pacco da un luogo a un altro molto rapidamente, la Ferrari è la scelta migliore perché ha metà della latenza (ritardo), dal momento in cui avviamo la consegna fino a quando il primo pacco viene consegnato, rispetto all'autoarticolato.

Come potete immaginare, nella maggior parte dei casi gli autoarticolati sono enormemente più pratici perché la loro velocità di consegna è molto più elevata. E, stando così le cose, vediamo effettivamente grandi camion sulle autostrade in continuazione, mentre la frequenza con cui si incontrano Ferrari è molto bassa, anche se ciascuno costa all'incirca lo stesso prezzo d'acquisto (molto approssimativamente). Ma in casi particolari, la Ferrari ha più senso. Solo non molto spesso.

Questo è un concetto di carattere generale e può applicarsi a numerose applicazioni. Si applica ai sistemi di caching, alla memoria, alla CPU, al networking, ai kernel e agli scheduler dei sistemi operativi, alle automobili e altro ancora. Latenza e throughput sono generalmente inversamente correlati: rinunciamo alla latenza per ottenere throughput. Per la maggior parte delle operazioni questo ha più senso. Ma a volte ha più senso ottimizzare per la latenza.

Lo storage è in realtà un caso anomalo nell'informatica, dove quasi tutta l'attenzione sulle prestazioni dello storage ruota attorno agli IOPS, che sono grossomodo una misura indiretta della latenza, anziché attorno al throughput, che si misura in “dati trasferiti al secondo”. Raramente ci interessa questo secondo numero, dato che non è quasi mai la fonte dei colli di bottiglia dello storage. Ma questa è l'eccezione, non la regola.

Latenza e throughput possono avere alcune interazioni sorprendenti nel mondo dell'informatica. Quando parliamo di reti, ad esempio, in genere misuriamo solo il throughput (Gb/s) ma raramente ci preoccupiamo molto della latenza (normalmente misurata in millisecondi). Tipicamente questo accade perché quasi tutti i sistemi di networking hanno valori di latenza simili e la maggior parte delle applicazioni è praticamente indifferente ai ritardi di latenza. È solo la rara applicazione come il VoIP su collegamenti internazionali o satellitari che fa sì che la latenza influenzi la persona media, oppure che può talvolta cogliere di sorpresa quando si tenta qualcosa di insolito come iSCSI su una connessione WAN a lunga distanza e all'improvviso la latenza salta fuori a sorprendere come un problema imprevisto.

Uno dei contesti in cui l'interazione tra latenza e throughput comincia a diventare sorprendente e interessante è quando passiamo dalle reti dati elettriche o ottiche a quelle fisiche. Una famosa citazione del settore è:

Non sottovalutate mai la larghezza di banda di una station wagon piena di nastri che sfreccia lungo l'autostrada.

Questa è un'ottima dimostrazione di un'enorme larghezza di banda con una latenza molto elevata. Percorrendo cinquanta miglia attraverso la città, una singola station wagon o un SUV potrebbe trasportare centinaia di petabyte di dati, raggiungendo velocità di trasferimento dati che la fibra a 10GB/s non potrebbe nemmeno avvicinare. Ma il tempo di arrivo del primo pacchetto di dati è di circa un'ora. Spesso scartiamo questo tipo di rete perché diamo per scontato che la latenza debba essere limitata a meno di circa 500 ms. Ma non è sempre così.

L'Australia è recentemente finita sui giornali quando ha condotto un test per vedere se un piccione che trasportava una scheda SD potesse, in termini di throughput di rete, superare l'ISP della regione, e il piccione si è rivelato più veloce dell'ISP!

In termini di prestazioni informatiche spesso ignoriamo la latenza al punto da non esserne nemmeno consapevoli come contesto in cui discutere le prestazioni. Ma negli ambienti dell'informatica a bassa latenza viene considerata con grande attenzione. Il throughput del sistema viene generalmente ridotto in misura considerevole (diventa comune puntare a sistemi che raggiungano solo il dieci per cento di utilizzo della CPU, quando i sistemi più tradizionali puntano a un valore più vicino al novanta per cento), con concetti come kernel real time, CPU affinity, processor pinning, cache hit ratio e misurazioni ridotte, tutti impiegati per concentrarsi sull'ottenere dal sistema la risposta più immediata possibile, anziché cercare di ottenere dal sistema il massimo della capacità di elaborazione totale.

Gli ambiti comuni in cui si desidera una bassa latenza da una prospettiva computazionale sono i sistemi di controllo critici (come i controller di produzione, dove anche un solo millisecondo di latenza può causare problemi sul piano di fabbrica) oppure i sistemi di trading finanziario, dove pochi millisecondi di ritardo possono far sì che gli investimenti abbiano cambiato prezzo o che i prodotti siano già stati venduti e non più disponibili. La velocità, in termini di latenza, è spesso il fattore decisivo tra guadagnare o perdere denaro: anche un singolo millisecondo può essere paralizzante.

Tecnicamente, anche i sistemi di elaborazione audio e video devono essere sensibili alla latenza, ma la maggior parte dei sistemi informatici moderni dispone di così tanta capacità di elaborazione in eccesso e la latenza è generalmente abbastanza bassa che la maggior parte dei sistemi, persino i PBX VoIP e i sistemi di conferenza, può funzionare oggi avendo solo molto raramente bisogno di tener conto delle questioni di latenza sul lato dell'elaborazione (persino la latenza di rete sta diventando una preoccupazione sempre meno comune). L'amministratore di sistema o l'ingegnere medio potrebbe facilmente attraversare un'intera carriera senza dover mai lavorare su un sistema sensibile alla latenza o per il quale non vi sia così tanta capacità disponibile da nascondere qualsiasi sensibilità alla latenza.

Definire la velocità, che ciò significhi throughput, latenza o anche qualcos'altro o una combinazione dei due, è qualcosa di molto importante in tutti gli aspetti dell'IT e della vita. Comprendere come ci influenzano in situazioni diverse e come reagiscono l'una con l'altra, esistendo generalmente in una relazione indiretta in cui i miglioramenti del throughput hanno un costo in termini di latenza o viceversa, e imparare a bilanciarli secondo necessità per migliorare i sistemi su cui lavoriamo è molto prezioso.