Sérialisation et temps de sérialisation en Ethernet 40G / 10G et 100G / 25G

15

J'ai récemment participé à des discussions sur les exigences de latence la plus faible pour un réseau Leaf / Spine (ou CLOS) pour héberger une plate-forme OpenStack.

Les architectes système s'efforcent d'obtenir le RTT le plus bas possible pour leurs transactions (stockage de blocs et futurs scénarios RDMA), et l'affirmation était que le 100G / 25G offrait des délais de sérialisation considérablement réduits par rapport au 40G / 10G. Toutes les personnes impliquées sont conscientes qu'il y a beaucoup plus de facteurs dans le jeu de bout en bout (qui peuvent blesser ou aider RTT) que les NIC et les délais de sérialisation des ports de commutation. Pourtant, le sujet des retards de sérialisation revient sans cesse, car ils sont une chose qui est difficile à optimiser sans sauter un fossé technologique éventuellement très coûteux.

Un peu trop simplifié (en laissant de côté les schémas de codage), le temps de sérialisation peut être calculé en nombre de bits / débit binaire , ce qui nous permet de commencer à ~ 1,2 μs pour 10G (voir également 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

Maintenant pour la partie intéressante. Au niveau de la couche physique, 40G se fait généralement en 4 voies de 10G et 100G en 4 voies de 25G. Selon la variante QSFP + ou QSFP28, cela se fait parfois avec 4 paires de brins de fibres, parfois il est divisé par lambdas sur une seule paire de fibres, où le module QSFP fait du xWDM seul. Je sais qu'il existe des spécifications pour 1x 40G ou 2x 50G ou même 1x 100G, mais laissons cela de côté pour le moment.

Pour estimer les retards de sérialisation dans le contexte de 40G ou 100G à plusieurs voies, il faut savoir comment les NIC 100G et 40G et les ports de commutation "distribuent les bits au (jeu de) fil (s)", pour ainsi dire. Que fait-on ici?

Est-ce un peu comme Etherchannel / LAG? Le NIC / switchports envoie des trames d'un "flux" (lire: même résultat de hachage de n'importe quel algorithme de hachage utilisé sur quelle étendue de la trame) à travers un canal donné? Dans ce cas, nous nous attendons à des délais de sérialisation tels que 10G et 25G, respectivement. Mais essentiellement, cela ferait une liaison 40G juste un LAG de 4x10G, réduisant le débit à flux unique à 1x10G.

Est-ce quelque chose comme un tournoi à la ronde par bits? Chaque bit est réparti sur les 4 canaux (sous) canaux? Cela peut en fait entraîner des délais de sérialisation plus faibles en raison de la parallélisation, mais soulève quelques questions sur la livraison dans l'ordre.

Est-ce quelque chose comme un tournoi à la ronde par cadre? Des trames Ethernet entières (ou d'autres morceaux de taille appropriée) sont envoyées sur les 4 canaux, distribués à la manière d'un round robin?

Est-ce autre chose, comme ...

Merci pour vos commentaires et conseils.

Marc 'netztier' Luethi
la source

Réponses:

14

La partie qui effectue la division en plusieurs voies est appelée sous-couche de codage physique dans la norme IEEE 802.3ba. Cette présentation de Gary Nicholl en donne un bon aperçu.

La courte explication est que les données sont divisées en plusieurs voies en blocs de 64 bits chacune ( codées sur fil en 66 bits pour la récupération d'horloge). Par conséquent, dès que la taille du paquet dépasse N * 64 bits (= 32 octets pour 4 voies), il peut utiliser pleinement toutes les voies. Il y aura un certain retard dans l'encodage, mais c'est probablement spécifique à l'implémentation.

Ce diagramme provient de la présentation liée ci-dessus: Fonction de sous-couche de codage physique

jpa
la source
1
"Il y aura un certain retard dans l'encodage" , uh oh. Maintenant, vous avez ouvert une autre boîte de vers! Quel est le délai? Cela affecte-t-il le délai global des paquets? Etc ...
pipe
1
Ah, merci pour ça. D'après ce que je comprends, ces «mots» sont les «morceaux de bits de taille appropriée», comme je l'ai mis dans mon message d'origine. Est-ce que cela se rapproche?
Marc 'netztier' Luethi
1
@ Marc'netztier'Luethi Exactement.
jpa
@pipe Ouais. Heureusement, "toutes les personnes impliquées savent qu'il y a beaucoup plus de facteurs" :)
jpa
2
@pipe bien, je pense que nous allons laisser cela de côté. Tous les défis soulevés à partir de maintenant, je répondrai par "tant que vous envoyez suffisamment de données à la fois (32 octets) pour permettre au NIC / Port de faire un round-robin sur les quatre voies, vous obtiendrez le délai de sérialisation plus court / parallélisé vous en voulez tellement ". Bien sûr, toute trame Ethernet à moitié cuite avec un en-tête IP et aucune charge utile franchira déjà cette limite. Par conséquent: peu importe.
Marc 'netztier' Luethi
16

Vous pensez trop.

Le nombre de voies utilisées n'a pas vraiment d'importance. Que vous transportiez 50 Gbit / s sur 1, 2 ou 5 voies, le délai de sérialisation est de 20 ps / bit. Ainsi, vous obtiendrez 5 bits tous les 100 ps, ​​quelles que soient les voies utilisées. La division des données en voies et la recombinaison a lieu dans la sous-couche PCS et est invisible même au-dessus de la couche physique. Quelle que soit votre situation, peu importe si un 100G PHY sérialise 10 bits séquentiellement sur une seule voie (10 ps chacun, 100 ps au total) ou en parallèle sur 10 voies (100 ps chacun, 100 ps au total) - sauf si vous '' re construction de cette PHY.

Naturellement, 100 Gbit / s a ​​la moitié du retard de 50 Gbit / s et ainsi de suite, donc plus vous sérialisez rapidement (au-dessus de la couche physique), plus une trame est transmise rapidement.

Si vous êtes intéressé par la sérialisation interne dans l'interface, vous devez regarder la variante MII qui est utilisée pour la classe de vitesse. Cependant, cette sérialisation a lieu à la volée ou en parallèle avec la sérialisation MDI réelle - cela prend une minute, mais cela dépend du matériel réel et probablement impossible à prévoir (quelque chose le long de 2-5 ps serait soyez ma conjecture pour 100 Gbit / s). Je ne m'inquiéterais pas vraiment à ce sujet car il y a des facteurs beaucoup plus importants impliqués. 10 ps est l'ordre de latence de transmission que vous obtiendriez à partir de 2 millimètres supplémentaires (!) De câble.

L'utilisation de quatre voies de 10 Gbit / s chacune pour 40 Gbit / s n'est PAS la même chose que l'agrégation de quatre liaisons à 10 Gbit / s. Une liaison à 40 Gbit / s - quel que soit le nombre de voies - peut transporter un seul flux à 40 Gbit / s, ce que les liaisons LAGged à 10 Gbit / s ne peuvent pas transporter. De plus, le délai de sérialisation de 40G n'est que 1/4 de celui de 10G.

Zac67
la source
3
Merci pour votre commentaire. Vous dites donc qu'à travers 10/25/40 / 100G, la règle générale du nombre de bits par trame / débit binaire = le délai de sérialisation reste valide, quel que soit le nombre de voies utilisées par la couche physique donnée (donner ou prendre quelques différences marginales)?
Marc 'netztier' Luethi
6
Oui. L'Ethernet à plusieurs voies est très différent des liaisons agrégées à cet égard.
Zac67