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 .
la source
Réponses:
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
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:
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)
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
(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:
la source
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:
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:
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
Btw, ils affirment également que
et Argon utilisent le commutateur Arista 7124FX , qui (en plus d'un FPGA) a un système d'exploitation
la source
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.
la source