Perché il protocollo USB 3.0 è più lento di quanto ci aspettiamo?

Perché il protocollo USB 3.0 è più lento di quanto ci aspettiamo?

Perché i nostri dispositivi USB 3.0 non vanno oltre i 150 MB/s quando dovrebbero arrivare più o meno a 500? La tabella seguente pone le basi per le nostre osservazioni:

Con il protocollo USB i dati devono essere codificati per il trasferimento, e poi decodificati all'arrivo; in altre parole non possono viaggiare in "forma grezza". La codifica è un passaggio cruciale perché permette al ricevente di recuperare la frequenza (data clock), fondamentale per ridurre gli errori. Come molte altre interfacce (ad esempio la gigabit Ethernet ottica) il protocollo USB usa una codifica 8b/10b, che converte simboli a 8 bit in versioni a 10 bit, ottenendo un risultato noto come bilanciamento DC. La codifica 8b/10b offre le frequenti transizioni necessarie per recuperare la frequenza, ma riduce la velocità del 20%.

Ecco perché la velocità massima del protocollo USB 3.0 si ferma a 500 MB/s, ma ci sono altre variabili da prendere in considerazione.

Nelle specifiche dell'USB Implementers Forum (USB-IF) si legge infatti che (capitolo 4.4.11) "l'efficienza del SuperSpeed dipende da diversi fattori, compresa la codifica 8b/10b, la struttura dei pacchetti e relativo framing, controllo del flusso a livello dei collegamenti e overhead del protocollo. Una frequenza di segnale di 6 Gbps con codifica 8b/10 ha quindi un throughput grezzo pari a 500 MB/s. Se si prendono in considerazione controllo del flusso, packet framing, e overhead è realistico arrivare a 400 MB/s".

E così se ne vanno altri 100 MB/s, ma anche 400 sarebbero fantastici rispetto ai 40 MB/s che possiamo ottenere con l'USB 2.0. Ciò che abbiamo scoperto finora non spiega perché i numeri che vediamo nei test reali sono così bassi, però.

Possiamo cercare una prima risposta nel controller del dispositivo collegato. Nei grafici sopra si vede come il Thermaltake BlacX 5G può facilmente battere l'adattatore Apricorn SATA-to-SUB 3.0, anche se certi numeri sono possibili solo con un SSD ad alte prestazioni. Il BlacX 5G batte anche il sistema RAID esterno di Buffalo, e questo è ancora più sorprendente; è l'unico dispositivo dei tre menzionati che usa il controller ASM1051, il che non si sorprende del tutto perché fino a oggi abbiamo visto che i controller ASMedia sono quelli con le migliori prestazioni. Questo vantaggio da solo tuttavia non basta a superare i 300 MB/s.

Anche il controller dell'host (quello dentro al computer) può a sua volta influenzare le prestazioni. Abbiamo fatto i benchmark precedenti sulle porte USB 3.0 di una scheda madre AsRock Z77 Extreme 6, ma abbiamo anche ottenuto risultati contrastanti probabilmente legati alla realizzazione; il controller Etron arriva al massimo a 250 MB/s, ma su un'altra scheda si ferma a 200 MB/s. In generale la migliore stabilità e coerenza si trova nelle implementazioni native Platform Controller Hub (Intel) o Fusion Controller Hub (AMD).

L'ultima questione è l'inefficienza del protocollo. Tutte le forme di USB usano quattro tipi di trasferimenti: control, interrupt, isochronous e bulk. I primi due (control e interrupt) definiscono il modo in cui l'host comunica con i dispositivi, il terzo (isochronous o isocroco) serve per trasferire informazioni periodicamente e costantemente, e determina come un dispositivo può riservare parte della banda con latenza garantita. Il trasferimento isocrono è usato generalmente nei dispositivi audio e video come le schede di cattura, perché risolve il problema della perdita di dati (come i fotogrammi mancanti) che si presenta quando si collegano molti dispositivi USB. L'ultimo tipo di trasferimento (bulk) è quello su cui ci concentriamo oggi, perché è quello usato per trasferire dati da e verso dispositivi di archiviazione USB.

Questo trasporto di massa s'indica generalmente con l'acronimo BOT (bulk-only transport), e fu sviluppato nel 1998 per il protocollo USB 1.1 come protocollo che riceve ed elabora un solo comando alla volta. Era progettato espressamente per i pendrive, che all'epoca erano piccoli per capacità e relativamente lenti. Da questo punto di vista il protocollo BOT è simile a quello IDE, perché il command queuing non è presente dal lato host. Questo spiega anche perché le prestazioni via USB si appiattiscono quando si incrementa la queue depth.

Quando nel 2000 uscì il protocollo USB 2.0, il trasferimento BOT non cambiò, forse perché la strozzatura del BUS USB rendeva del tutto superfluo un aggiornamento. Guardandola con il senno di poi però forse quella scelta fu un errore, perché il suo impatto si sta facendo sentire pesantemente sull'USB 3.0; quest'ultima infatti non è più lenta dei dispositivi a cui è collegata come la versione precedente, ma è vero il contrario.