☰

Im Whitepaper des Anbieters steht: 5 Mpps, kein Problem. Bei 120 kpps stoße ich schon an meine Grenzen. Wo ist der Engpass?

tag-icon • tag-icon networking performance windows-server-2012-r2 udp
Im Whitepaper des Anbieters steht: 5 Mpps, kein Problem. Bei 120 kpps stoße ich schon an meine Grenzen. Wo ist der Engpass?

HPsWhitepaper zu ihren QLogic (ehemals Broadcom) NetXtreme II-Adaptern, zu dem auch die von mir getestete Netzwerkkarte gehört, gibt an (Seite 7), dass die Leistung kleiner Pakete bis zu 256 Byte/Paket über 5.000.000 Pakete/Sek. liegt.

Bei meinen Tests mit einer App, bei der ich die gesamte Verarbeitung außer dem reinen UDP-Empfangsteil deaktiviert habe, komme ich nur auf 120.000 Pakete/Sek. Die Pakete sind gleichmäßig auf 12 Multicast-Gruppen verteilt.

Mir ist aufgefallen, dass esein Kern(von jeweils 12 Kernen auf den 2 Sockeln), deren Last allmählich zunimmt, wenn ich die UDP-Sendegeschwindigkeit erhöhe undliegt bei ca. 120.000. Aber ich weiß nicht, was dieser Kern macht und warum. Es ist kein Single-Thread-Engpass in meiner App, denn es spielt keine Rolle, ob ich eine einzelne Instanz der App für alle Multicast-Gruppen ausführe oder 12 Instanzen, die jeweils 1 Multicast-Gruppe verarbeiten. Der Engpass ist also nicht meine Empfänger-App.

MSI ist aktiviert (überprüft durch dieAnsicht „Ressourcen nach Typ“ im Gerätemanager) und RSS ist auch in den NIC-Einstellungen aktiviert, mit 8 Warteschlangen. Was hängt also an diesem einen Kern? Alle NIC-Offloading-Funktionen sind derzeit aktiviert, aber das Ausschalten hat nicht geholfen.

Wo also könnte der Engpass sein?

Systemdetails:

  • ProLiant BL460c Gen9
  • Intel Xeon E5-2670 v3 (2 x 12 Kerne)
  • HP FlexFabric 10 Gb 2-Port 536FLB NIC
  • Windows 2012 R2

Antwort1

Auch RSS ist in den NIC-Einstellungen mit 8 Warteschlangen aktiviert.

Was leider nicht bedeutete, dass RSS eingesetzt wurde, denn

netsh int tcp show global

zeigte:

TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State : disabled

Nach dem Ausführen (übrigens ohne Neustart)

netsh int tcp set global rss=enabled

RSS funktioniert jetzt und die Last, die früher auf diesem einen schlechten Kern lastete, wird jetzt gleichmäßig auf viele Kerne auf einem der beiden NUMA-Knoten verteilt.

Ich habe nicht überprüft, ob ich damit die angekündigten Mpps-Lasten bewältigen könnte, aber die Obergrenze war ausreichend hoch, um den erforderlichen Maßstab zu setzen.

verwandte Informationen