Motivazione

Con una velocità di segnalazione di 480 MBit / s i dispositivi USB 2.0 dovrebbero essere in grado di trasmettere dati fino a 60 MB / s. Tuttavia, i dispositivi di oggi sembrano essere limitati a 30-42 MB / s durante la lettura di [ Wiki: USB ]. Questo è un overhead del 30 percento.

L'USB 2.0 è uno standard di fatto per i dispositivi esterni da oltre 10 anni. Una delle applicazioni più importanti per l'interfaccia USB sin dall'inizio è stata la memorizzazione portatile. Sfortunatamente USB 2.0 è stato rapidamente un collo di bottiglia che limita la velocità a queste applicazioni impegnative in termini di larghezza di banda, un HDD di oggi è in grado, ad esempio, di oltre 90 MB / s in lettura sequenziale. Considerando la lunga presenza sul mercato e la costante necessità di una maggiore larghezza di banda, dovremmo aspettarci che l'ecosistema USB 2.0 sia stato ottimizzato nel corso degli anni e abbia raggiunto prestazioni di lettura vicine al limite teorico.

Qual è la massima larghezza di banda teorica nel nostro caso? Ogni protocollo ha un overhead incluso USB e secondo lo standard USB 2.0 ufficiale è 53.248 MB / s [ 2 , Tabella 5-10]. Ciò significa che teoricamente i dispositivi USB 2.0 di oggi potrebbero essere il 25 percento più veloci.

Analisi

Per avvicinarsi alla radice di questo problema, la seguente analisi dimostrerà cosa sta succedendo sul bus durante la lettura di dati sequenziali da un dispositivo di archiviazione. Il protocollo è suddiviso strato per strato e siamo particolarmente interessati alla domanda sul perché 53.248 MB / s sia il numero massimo teorico per i dispositivi a monte di massa. Infine, parleremo dei limiti dell'analisi che potrebbero darci alcuni suggerimenti di costi generali aggiuntivi.

Gli appunti

In tutta questa domanda vengono utilizzati solo i prefissi decimali.

Un host USB 2.0 è in grado di gestire più dispositivi (tramite hub) e più endpoint per dispositivo. Gli endpoint possono operare in diverse modalità di trasferimento. Limiteremo la nostra analisi a un singolo dispositivo collegato direttamente all'host e in grado di inviare continuamente pacchetti completi su un endpoint di massa a monte in modalità ad alta velocità.

Framing

La comunicazione USB ad alta velocità è sincronizzata in una struttura a frame fisso. Ogni frame è lungo 125 us e inizia con un pacchetto Start-Of-Frame (SOF) ed è limitato da e sequenza End-Of-Frame (EOF). Ogni pacchetto inizia con SYNC e termina con e End-Of-Packet (EOF). Quelle sequenze sono state aggiunte ai diagrammi per chiarezza. EOP ha dimensioni variabili e dipende dai dati dei pacchetti, per SOF è sempre di 5 byte.

Apri l'immagine in una nuova scheda per vedere una versione più grande.

Le transazioni

USB è un protocollo guidato da master e ogni transazione viene avviata dall'host. La fascia oraria tra SOF ed EOF può essere utilizzata per le transazioni USB. Tuttavia, i tempi per SOF ed EOF sono molto rigidi e l'host avvia solo transazioni che possono essere completate completamente nel periodo di tempo libero.

La transazione a cui siamo interessati è una transazione IN in blocco di successo. La transazione inizia con un pacchetto tocken IN, quindi gli host attendono un pacchetto di dati DATA0 / DATA1 e confermano la trasmissione con un pacchetto di handshake ACK. L'EOP per tutti questi pacchetti è compreso tra 1 e 8 bit a seconda dei dati dei pacchetti, qui abbiamo ipotizzato il caso peggiore.

Tra ciascuno di questi tre pacchetti dobbiamo considerare i tempi di attesa. Questi sono tra l'ultimo bit del pacchetto IN dell'host e il primo bit del pacchetto DATA0 del dispositivo e tra l'ultimo bit del pacchetto DATA0 e il primo bit del pacchetto ACK. Non dobbiamo considerare ulteriori ritardi poiché l'host può iniziare a inviare il successivo IN subito dopo aver inviato un ACK. Il tempo di trasmissione del cavo è definito come massimo 18 ns.

Un trasferimento di massa può inviare fino a 512 byte per transazione IN. E l'host proverà a emettere quante più transazioni possibili tra i delimitatori di frame. Sebbene il trasferimento di massa abbia una bassa priorità, può richiedere tutto il tempo disponibile in uno slot quando non vi sono altre transazioni in sospeso.

Per garantire il corretto ripristino del clock, gli standard definiscono un riempimento di bit di chiamata di metodo. Quando il pacchetto richiederebbe una sequenza molto lunga della stessa uscita, viene aggiunto un fianco aggiuntivo. Ciò garantisce un fianco dopo un massimo di 6 bit. Nel peggiore dei casi, ciò aumenterebbe la dimensione totale del pacchetto di 7/6. L'EOP non è soggetto a ripieni di bit.

Apri l'immagine in una nuova scheda per vedere una versione più grande.

Calcoli della larghezza di banda

Una transazione IN in blocco ha un overhead di 24 byte e un payload di 512 byte. Questo è un totale di 536 byte. Il periodo di tempo tra è largo 7487 byte. Senza la necessità di ripieni di bit, c'è spazio per 13.968 pacchetti. Con 8000 Micro-frame al secondo possiamo leggere i dati con 13 * 512 * 8000 B / s = 53.248 MB / s

Per dati totalmente casuali ci aspettiamo che il bit stuffing sia necessario in una delle 2 ** 6 = 64 sequenze di 6 bit consecutivi. Questo è un aumento di (63 * 6 + 7) / (64 * 6). Moltiplicando tutti i byte soggetti a riempimento di bit per quei numeri si ottiene una lunghezza totale della transazione di (19 + 512) * (63 * 6 + 7) / (64 * 6) + 5 = 537,38 byte. Il risultato è 13.932 pacchetti per Micro-Frame.

C'è un altro caso speciale mancante da questi calcoli. Lo standard definisce un tempo di risposta massimo del dispositivo di 192 bit volte [ 2 , capitolo 7.1.19.2]. Questo deve essere considerato quando si decide se l'ultimo pacchetto si adatta ancora al frame nel caso in cui il dispositivo abbia bisogno del tempo di risposta completo. Potremmo spiegarlo usando una finestra di 7439 byte. La larghezza di banda risultante è identica.

Cos'è rimasto

• Il rilevamento e il ripristino degli errori non sono stati coperti. Forse gli errori sono abbastanza frequenti o l'errore nel recupero richiede abbastanza tempo per avere un impatto sulle prestazioni medie.

• Abbiamo assunto la reazione istantanea dell'host e del dispositivo dopo i pacchetti e le transazioni. Personalmente non vedo alcuna necessità di grandi compiti di elaborazione alla fine di pacchetti o transazioni su entrambi i lati e quindi non riesco a pensare a nessun motivo per cui l'host o il dispositivo non dovrebbero essere in grado di rispondere istantaneamente con implementazioni hardware sufficientemente ottimizzate. Soprattutto durante il normale funzionamento, la maggior parte del lavoro di contabilità e di rilevamento degli errori potrebbe essere svolto durante la transazione e i pacchetti e la transazione successivi potrebbero essere messi in coda.

• Non sono stati presi in considerazione trasferimenti per altri endpoint o comunicazioni aggiuntive. Forse il protocollo standard per i dispositivi di archiviazione richiede una comunicazione continua sul canale laterale che consuma tempo prezioso nello slot.

• Potrebbe esserci un sovraccarico di protocollo aggiuntivo per i dispositivi di archiviazione per il driver del dispositivo o il livello del file system. (payload del pacchetto == dati di archiviazione?)

Domanda

• Perché le implementazioni odierne non sono in grado di eseguire lo streaming a 53 MB / s?

• Dov'è il collo di bottiglia nelle implementazioni di oggi?

E un potenziale seguito: perché nessuno ha cercato di eliminare un simile collo di bottiglia?

Riferimenti

[1] Specifiche USB 2.0 ufficiali

[2] Specchio pdf veloce della specifica

Ad un certo punto della mia vita, gestivo il business USB per grandi aziende semi. Il miglior risultato che ricordo è stato il controller SATA NEC in grado di spingere il throughput di dati effettivo a 320 Mbps per l'archiviazione di massa, probabilmente le unità SATA attuali sono in grado di farlo o leggermente più. Stava usando BOT (alcuni protocolli di archiviazione di massa funzionano su USB).

Posso dare una risposta tecnica dettagliata ma immagino che tu possa dedurti. Quello che devi vedere è che, questo è il gioco dell'ecosistema, qualsiasi miglioramento significativo richiederebbe a qualcuno come Microsoft di cambiare il proprio stack, ottimizzare ecc, che non accadrà. L'interoperabilità è molto più importante della velocità. Poiché gli stack esistenti coprono attentamente gli errori di rotazione dei dispositivi là fuori perché quando le specifiche USB2 escono probabilmente i dispositivi iniziali non confermano davvero le specifiche che, dal momento che le specifiche erano difettose, il sistema di certificazione era difettoso ecc. Ecc. Se costruisci un sistema per la produzione di birra fatta in casa usando Linux o driver host USB personalizzati per MS e un controller di dispositivo veloce, puoi probabilmente avvicinarti ai limiti teorici.

In termini di streaming, l'ISO dovrebbe essere molto veloce ma i controller non lo implementano molto bene, poiché il 95% delle app utilizza il trasferimento di massa.

Come bonus aggiuntivo, ad esempio, se vai a costruire un hub IC oggi, se segui le specifiche fino al punto, praticamente venderai zero chips. Se conosci tutti i bug presenti sul mercato e ti assicuri che il tuo hub IC possa tollerarli, probabilmente puoi entrare nel mercato. Sono ancora stupito oggi, quanto bene funziona USB dato il numero di software e chip difettosi là fuori.

Questo è un argomento molto vecchio, ma non ha ancora una risposta. Questo è il mio tentativo:

Perché le implementazioni odierne non sono in grado di eseguire lo streaming a 53 MB / s?

I calcoli sono quasi corretti, ma stai dimenticando un paio di cose nel numero di byte disponibili tra i marker di frame:

1. Ogni microframe ha due soglie chiamate EOF1 ed EOF2. Nessuna attività del bus deve verificarsi in / dopo EOF1. Il posizionamento di questo punto è una cosa complicata, ma la posizione tipica è 560 bit volte prima del SOF successivo. Un host deve pianificare le sue transazioni in modo tale che qualsiasi possibile risposta dal canale non raggiunga questa soglia. Che consuma circa 70 byte su 7487 byte calcolati.

2. Assumi "dati casuali". Questo è completamente infondato, i dati possono essere qualsiasi cosa. Pertanto, l'host deve pianificare le transazioni per il payload nel caso peggiore, con un overhead massimo di riempimento bit, 512 * 7/6 = ~ 600 byte. Più 24 byte di spese generali di transazione, come hai giustamente calcolato. Questo dà (7487-70) / 624 = 11,88 transazioni per micro-frame.

3. L'host è tenuto a riservare circa il 10% delle larghezze di banda per le transazioni di controllo per qualsiasi altra attività, quindi otteniamo circa 10,7 transazioni.

4. Il controller host ha anche una certa latenza durante la gestione dell'elenco collegato, quindi c'è un ulteriore divario tra le transazioni.

5. Il dispositivo può trovarsi a 5 hub / hop lontano dalla radice e il ritardo di risposta può arrivare fino a 1700 ns, che consuma altri 106 byte di ciascun budget di transazione. In una stima approssimativa, effettua solo 10,16 transazioni per uFrame, senza contare la larghezza di banda riservata.

L'host non può effettuare una riprogrammazione adattiva basata sull'arrivo effettivo della transazione all'interno di uFrame, sarebbe proibitivo dal punto di vista del software, quindi il driver utilizza la pianificazione più conservativa, fino a 9 transazioni in blocco per uFrame, che ammonta a 36 Mbyte / secondo. Questo è ciò che può offrire un'ottima pen drive USB.

Alcuni pazzi benchmark artificiali possono arrivare a 11 transazioni per uFrame, il che rende 44 MBps. E questo è il massimo assoluto per il protocollo USB HS.

Dov'è il collo di bottiglia nelle implementazioni di oggi?

Come si può vedere sopra, non c'è un collo di bottiglia, tutto lo spazio di bit-time grezzo viene consumato dal sovraccarico del protocollo.