Est-il possible de traiter des millions de datagrammes par seconde avec Windows?

J'étudie si je peux implémenter une application HPC sur Windows qui reçoit de petits datagrammes de multidiffusion UDP (principalement 100 à 400 octets) à un débit élevé, en utilisant une douzaine ou jusqu'à peut-être 200 groupes de multidiffusion (c'est-à-dire en utilisant MSI-X et RSS, je peux mise à l'échelle vers plusieurs cœurs), effectue un certain traitement par paquet, puis l'envoie. En envoyant via TCP, j'ai réussi à monter aussi loin que nécessaire (6,4 Gb / s) sans toucher un mur, mais la réception de datagrammes à des taux pps élevés s'est avérée être un problème.

Lors d'un test récent sur une machine NUMA de haute spécification avec une carte réseau Ethernet 10 Gb à 2 ports sur Windows 2012 R2, je n'ai pu recevoir que des centaines de milliers de datagrammes UDP par seconde (suppression anticipée, c'est-à-dire sans réellement traiter les données), pour supprimer les frais généraux de traitement de mon application de l'équation pour voir à quelle vitesse cela se fait) en utilisant des cœurs 2x12, et la partie noyau des 12 groupes de multidiffusion testés semblait être répartie sur 8 ou 10 cœurs d'un nœud NUMA (les files d'attente RSS maximales ont été définies à 16) - bien qu'avec une application .net, les applications natives devraient pouvoir aller plus vite.

Mais même Len Holgate n'a réussi à recevoir des paquets UDP qu'à 500 kpps dans ses tests RIO Windows hautes performances , en utilisant une charge utile UDP de 1024 octets.

Dans le livre blanc de QLogic (le système d'exploitation en cours de test n'est pas mentionné), les limites du «routage de paquets super petits multi-threads» (ce qui inclut à la fois la réception et l'envoi ultérieur?) Sont fixées à 5,7 Mpps . Dans les articles sur la mise en réseau Linux , les limites sont fixées à 1Mpps à 2Mpps par cœur (qui évoluerait plus ou moins linéairement), ou même à 15Mpps avec des solutions spéciales qui contournent le noyau.

Par exemple netmap

peut générer du trafic à un débit de ligne ( 14,88 Mpps ) sur une liaison 10 GigE avec un seul cœur fonctionnant à 900 Mhz. Cela équivaut à environ 60 à 65 cycles d'horloge par paquet et s'adapte bien aux cœurs et à la fréquence d'horloge (avec 4 cœurs, le débit de ligne est atteint à moins de 450 MHz). Des taux similaires sont atteints du côté réception .

Jusqu'où puis-je aller (les dernières versions de) Windows / Windows Server, en particulier en recevant la multidiffusion UDP comme décrit dans le premier paragraphe?

Modifier Il y a un article de blog cloudflare - et une section de commentaires intéressante - sur la façon de le faire sur Linux: comment recevoir un million de paquets par seconde , et il y a la page correspondante des commentaires des nouvelles des pirates .

Selon Microsoft, les tests en laboratoire ont montré que "sur un serveur particulier lors des premiers tests" de RIO , ils étaient capables de gérer

• 2Mpps sans perte dans Windows Server 2008R2, c'est-à-dire sans RIO
• 4Mpps sur (version préliminaire) Windows Server 8 à l'aide de RIO

Capture d'écran de cette vidéo (44:33):

Donc, la réponse à ma question Is it possible to process millions of datagrams per second with Windows?serait: Oui , et apparemment c'était même avant RIO, dans Windows Server 2008R2.

Mais en plus des chiffres officiels, en particulier sur les logiciels inédits, devant être pris avec une pincée de sel, avec uniquement les informations rares fournies dans cette présentation, de nombreuses questions sur le test, et donc sur la façon d'interpréter correctement les résultats, demeurent. Les plus pertinents étant:

1. Les chiffres pour l'envoi sont-ils? Recevoir? Ou peut-être pour le routage (c'est-à-dire recevoir + envoyer)?
2. Quelle taille de paquet? -> Probablement le plus bas possible, comme cela se fait généralement en essayant d'obtenir des chiffres pps
3. Combien de connexions (si TCP) / flux de paquets (si UDP) ? -> Probablement autant que nécessaire pour répartir la charge de travail afin que tous les cœurs présents puissent être utilisés
4. Quelle configuration de test? Spécifications et câblage de la machine et de la carte réseau

La première est cruciale, car les envois et les réceptions nécessitent différentes étapes et peuvent présenter des différences de performances substantielles. Pour les autres figures, nous pouvons probablement supposer que la taille de paquet la plus faible, avec au moins un flux de connexion / paquet par cœur, était utilisée sur une machine de haute spécification pour obtenir le maximum de chiffres Mpps possibles.

Edit Je suis juste tombé sur un document Intel sur le traitement de paquets haute performance sous Linux, et selon cela, le (Linux)

la plate-forme peut supporter un taux de transaction d'environ 2 millions de transactions par seconde

en utilisant la pile de mise en réseau Linux standard (sur un hôte physique avec 2 x 8 cœurs). Une transaction dans ce test de demande / réponse comprend à la fois

1. réception d'un paquet UDP
2. transmission ultérieure de ce paquet

(en utilisant le netserverf de netsperf). Le test exécutait 100 transactions en parallèle. Il y a beaucoup plus de détails dans le document, pour ceux qui sont intéressés. Je souhaite que nous ayons quelque chose comme ça pour Windows à comparer ... Quoi qu'il en soit, voici le tableau le plus pertinent pour ce test de demande / réponse:

tl; dr

Pour donner une réponse définitive, d'autres tests semblent nécessaires. Mais des preuves indirectes suggèrent que Linux est le système d'exploitation utilisé pratiquement exclusivement dans la communauté à latence ultra faible, qui traite également régulièrement les charges de travail Mpps. Cela ne signifie pas que c'est impossible avec Windows, mais Windows sera probablement à la traîne un peu, même s'il peut être possible d'obtenir des nombres Mpps. Mais cela nécessite des tests pour être vérifié, et par exemple pour déterminer à quel coût (CPU) ces chiffres peuvent être atteints.

NB Ce n'est pas une réponse que j'ai l'intention d'accepter. Il vise à donner à toute personne intéressée par une réponse à la question quelques indications sur notre position et sur les points à approfondir.

Len Holgate, qui selon Google semble être le seul à avoir testé RIO pour obtenir plus de performances du réseau Windows (et publié les résultats), vient de préciser dans un commentaire sur son blog qu'il utilisait un seul combo IP / Port pour l'envoi des paquets UDP.

En d'autres termes, ses résultats devraient être quelque peu comparables aux chiffres du noyau unique dans les tests sur Linux (bien qu'il utilise 8 threads - qui, sans avoir encore vérifié son code, semble néfaste pour les performances lors de la gestion d'un seul flux de paquets UDP et non faire tout traitement lourd des paquets, et il mentionne que peu de threads sont réellement utilisés, ce qui aurait du sens). C'est malgré lui en disant:

Je n'essayais pas si fort d'obtenir des performances maximales juste pour comparer les performances relatives entre les anciennes et les nouvelles API et je n'étais donc pas si minutieux dans mes tests.

Mais qu'est-ce qui abandonne la zone de confort (relative) de l'IOCP standard pour le monde RIO plus rude autre que "essayer dur"? Au moins en ce qui concerne un seul flux de paquets UDP.

Je suppose que ce qu'il veut dire - car il a essayé diverses approches de conception dans plusieurs tests de RIO - est qu'il n'a pas, par exemple, affiné les paramètres NIC pour extraire le dernier bit de performance. Ce qui, par exemple dans le cas de la taille de la mémoire tampon de réception, pourrait potentiellement avoir un impact positif énorme sur les performances de réception UDP et les chiffres de perte de paquets.

Cependant, le problème lorsque vous essayez de comparer directement ses résultats avec ceux d'autres tests Linux / Unix / BSD est le suivant: La plupart des tests, lorsque vous essayez de repousser la limite des "paquets par seconde", utilisent la plus petite taille de paquet / trame possible, c'est-à-dire un Ethernet trame de 64 octets. Len a testé des paquets de 1024 octets (-> une trame de 1070 octets), qui (en particulier pour No-Nagle UDP) peuvent vous obtenir des chiffres "bits par seconde" beaucoup plus élevés, mais ne peuvent pas pousser la limite pps aussi loin que possible avec des paquets plus petits . Il ne serait donc pas juste de comparer ces chiffres tels quels.

Pour résumer les résultats de ma quête dans Windows UDP, je reçois les performances jusqu'à présent:

• Personne n'utilise vraiment Windows pour développer des applications à latence ultra faible et / ou à haut débit, ces derniers utilisent Linux
• Presque tous les tests de performance et les rapports avec des résultats réels (c'est-à-dire pas une simple publicité de produit) sont de nos jours sur Linux ou BSD (merci Len d'être un pionnier et de nous avoir donné au moins un point de référence!)
• UDP (sockets standard) sous Windows est-il plus rapide / plus lent que sous Linux? Je ne peux pas encore le dire, je devrais faire mes propres tests
• L'UDP hautes performances (RIO vs netmap) sous Windows est-il plus rapide / plus lent que sous Linux? Linux gère facilement la vitesse de ligne complète de 10 Go avec un seul cœur à 900 MHz, Windows, dans le meilleur des cas, publié est capable d'aller jusqu'à 43% ou 492 kpps pour une grande taille de paquet UDP de 1024, c'est-à-dire que les chiffres en bps pour les petites tailles seront probablement significativement pire, bien que les chiffres pps augmenteront probablement (à moins que la gestion des interruptions ou un autre surcharge d'espace du noyau ne soit le facteur limitant).

Quant à savoir pourquoi ils utilisent Linux, cela doit être dû au fait que développer des solutions qui impliquent des modifications du noyau comme netmap ou RIO - nécessaires pour pousser les performances à la limite - est presque impossible avec un système fermé comme Windows, à moins que vos chèques de paie ne viennent de Redmond, ou vous avez un contrat spécial avec Microsoft. C'est pourquoi RIO est un produit MS.

Enfin, pour donner quelques exemples extrêmes de ce que j'ai découvert et qui se passait sous Linux:

Il y a déjà 15 ans, certains recevaient 680 kpp en utilisant un processeur Pentium III 800 mHz, un bus frontal 133 mHz sur une carte réseau 1 GbE. Edit : Ils utilisaient Click , un routeur en mode noyau qui contourne une grande partie de la pile réseau standard, c'est-à-dire qu'ils ont "triché".

En 2013, Argon Design a réussi à obtenir

tick pour échanger des latences aussi faibles que 35ns [nano secondes]

Btw, ils affirment également que

La grande majorité du code informatique existant à échanger aujourd'hui est écrite pour Linux sur des architectures de processeur x86.

et Argon utilisent le commutateur Arista 7124FX , qui (en plus d'un FPGA) a un système d'exploitation

construit sur un noyau Linux standard.

Vous aurez sûrement besoin de "mesurer" différentes configurations et différents scénarios. Cela peut être fait AFAIK avec deux équipements fournis par 2 entreprises. IXIA et Spirent . Ils offrent des générateurs de trafic basés sur du matériel capables de pomper le trafic à la vitesse de la ligne. Ils offrent un test de rampe où vous pouvez détecter la vitesse à laquelle votre système particulier pourrait s'effondrer. Les appareils sont chers mais vous pouvez les louer.