Tempi di serializzazione e serializzazione in Ethernet 40G / 10G e 100G / 25G

Recentemente sono stato coinvolto in discussioni sui requisiti di latenza più bassa per una rete Leaf / Spine (o CLOS) per ospitare una piattaforma OpenStack.

Gli architetti di sistema stanno cercando il RTT più basso possibile per le loro transazioni (archiviazione a blocchi e scenari RDMA futuri), e l'affermazione era che 100G / 25G offriva ritardi di serializzazione notevolmente ridotti rispetto a 40G / 10G. Tutte le persone coinvolte sono consapevoli del fatto che ci sono molti più fattori nel gioco end-to-end (ognuno dei quali può danneggiare o aiutare RTT) rispetto ai soli NIC e ritardi nella serializzazione delle porte. Tuttavia, l'argomento dei ritardi di serializzazione continua a emergere, in quanto sono una cosa che è difficile da ottimizzare senza colmare una lacuna tecnologica forse molto costosa.

Un po 'troppo semplificato (tralasciando gli schemi di codifica), il tempo di serializzazione può essere calcolato come numero di bit / bit rate , che consente di iniziare a ~ 1,2μs per 10G (vedere anche wiki.geant.org ).

For a 1518 byte frame with 12'144bits,
at 10G (assuming 10*10^9 bits/s), this will give us ~1.2μs
at 25G (assuming 25*10^9 bits/s), this would be reduced to ~0.48μs 
at 40G (assuming 40*10^9 bits/s), one might expect to see ~0.3μs
at 100G (assuming 100*10^9 bits/s), one might expect to see ~0.12μs

Ora per la parte interessante. A livello fisico, 40 G viene comunemente eseguito come 4 corsie da 10 G e 100 G come 4 corsie da 25 G. A seconda della variante QSFP + o QSFP28, a volte questo viene fatto con 4 coppie di fili di fibra, a volte viene diviso da lambda su una singola coppia di fibre, in cui il modulo QSFP esegue da solo alcune xWDM. So che ci sono specifiche per 1x 40G o o 2x 50G o anche 1x 100G corsie, ma lasciamo da parte quelle per il momento.

Per stimare i ritardi di serializzazione nel contesto di 40G o 100G a più corsie, è necessario sapere come le schede NIC 100G e 40G e le porte degli switch effettivamente "distribuiscono i bit ai (set di) fili", per così dire. Cosa si sta facendo qui?

È un po 'come Etherchannel / LAG? La scheda NIC / switchports invia frame di un "flusso" (leggi: stesso risultato di hashing di qualsiasi algoritmo di hashing utilizzato in quale ambito del frame) attraverso un dato canale? In tal caso, prevediamo ritardi di serializzazione come 10G e 25G, rispettivamente. Ma essenzialmente, ciò renderebbe un collegamento 40G solo un LAG di 4x10G, riducendo il throughput di flusso singolo a 1x10G.

È qualcosa di simile a un round robin bit-saggio? Ogni bit è round-robin distribuito sui 4 (sotto) canali? Ciò potrebbe effettivamente comportare minori ritardi di serializzazione a causa della parallelizzazione, ma solleva alcune domande sulla consegna in-order.

È qualcosa di simile al round robin per quanto riguarda il frame? Interi frame ethernet (o altri pezzi di bit di dimensioni adeguate) vengono inviati sui 4 canali, distribuiti in modo round robin?

Qualcos'altro, come ...

Grazie per i tuoi commenti e suggerimenti.

La parte che fa la divisione su più corsie è chiamata Sublayer di codifica fisica nello standard IEEE 802.3ba. Questa presentazione di Gary Nicholl offre una buona panoramica.

La breve spiegazione è che i dati sono divisi in più corsie in blocchi di 64 bit ciascuno ( codificati sul filo come 66 bit per il recupero del clock). Pertanto, non appena la dimensione del pacchetto supera N * 64 bit (= 32 byte per 4 corsie), può utilizzare completamente tutte le corsie. Ci sarà qualche ritardo nella codifica, ma questo è probabilmente specifico dell'implementazione.

Questo diagramma proviene dalla presentazione collegata sopra:

Stai pensando troppo.

Il numero di corsie utilizzate non ha importanza. Sia che si trasporti 50 Gbit / s su 1, 2 o 5 corsie, il ritardo di serializzazione è di 20 ps / bit. Quindi, otterrai 5 bit ogni 100 ps, ​​indipendentemente dalle corsie utilizzate. La suddivisione dei dati in corsie e la ricombinazione avvengono nel sottostrato PCS ed è invisibile anche al di sopra del livello fisico. Indipendentemente dalla tua situazione, non importa se un PHY 100G serializza 10 bit in sequenza su una singola corsia (10 ps ciascuno, 100 ps in totale) o in parallelo su 10 corsie (100 ps ciascuno, 100 ps in totale) - a meno che tu ' stai costruendo quel PHY.

Naturalmente, 100 Gbit / s ha la metà del ritardo di 50 Gbit / s e così via, quindi più velocemente si serializza (sopra il livello fisico), più velocemente viene trasmesso un frame.

Se sei interessato alla serializzazione interna nell'interfaccia, dovresti esaminare la variante MII utilizzata per la classe di velocità. Tuttavia, questa serializzazione avviene al volo o in parallelo con la serializzazione MDI effettiva: richiede un minuto, ma dipende dall'hardware effettivo e probabilmente impossibile da prevedere (qualcosa di 2-5 ps sarebbe sia la mia ipotesi per 100 Gbit / s). Non mi preoccuperei davvero di questo in quanto vi sono fattori molto più grandi coinvolti. 10 ps è l'ordine di latenza di trasmissione che otterresti da altri 2 millimetri di cavo (!).

L'uso di quattro corsie da 10 Gbit / s ciascuna per 40 Gbit / s NON è lo stesso dell'aggregazione di quattro collegamenti da 10 Gbit / s. Un collegamento a 40 Gbit / s - indipendentemente dal numero di corsie - può trasportare un singolo flusso a 40 Gbit / s che i collegamenti LAGged a 10 Gbit / s non possono. Inoltre, il ritardo di serializzazione di 40G è solo 1/4 di quello di 10G.