Intel em(4) vs. Broadcom bce(4)

[rMarkus]

Ich hätte bei der Killer-Nic mehr Empörung hier erwartet und auf keinen Fall, dass irgendwer glaubt, dass man das Ding das ernsthatft unter FreeBSD einsetzen will.

Damit wollte ich die eigentlich Diskussion wiederbeleben, was auch gelungen ist.

Um wieder auf das ursprüngliche Thema zurückzukommen:

Die Milchmädchenrechnung, dass die CDU-Last der Netzwerkkarten heute keine Rolle mehr spielt, weil die CPUs stark genug sind, möchte ich folgende Punkte entgegenstellen:

1. Schlechte Netzwerkkarten feuern sehr viele Interrupts, die das Betriebssystem sofort behandeln muss und die aktuelle Arbeit durch einen Kontextswitch beenden muss. Hier bleiben z.B. dann viele Teile der Zeitscheibe ungenutzt und der Kontextswitch erzeugt starken Overhead (gerade bei FreeBSD). DIe CPU-Stärke hilft da wenig.
2. Eine einfache Reduktion von Interrupts steigert die Latanz, was die Interaktivitaet und bei vielen Protokollen auch den Durchsatz verringert. Hier sind clevere Mechanismen gefragt. Ausserdem muss vermieden werden, dass die Puffer (bei besseren Karten meist Ringpuffer im RAM) nicht überlaufen.
3. Ringpuffer sind schon eine eigenschaft besserer Karten, wobei es da auch Unterschiede gibt, ob es mehrere Ringpuffer gibt, ob die Ringpuffer die Daten oder nur Zeiger auf die Daten (und wenige Informationen) enthalten und so Umkopieren und Umkonvertieren im Kernel vermieden werden. Das grosse Ziel ist immer Zero-Copy.
4. Bei schlechten Netzwerkkarten muss die CPU RAM umkopieren oder sogar per Port-IO Daten kopieren. Die Dauer ist bestimmt durch die RAM- oder noch schlimmer IO-Geschwindigkeit und so lange blockiert die CPU. Eine schnelle CPU wartet hier genauso lange wie eine langsame.
5. IP-Offload entlastet tatsaechlich die CPU und schnelle CPUs macht das weniger aus. Hier muss man aber trotzdem unterscheiden, dass die CPU das immer vor dem Senden oder nach dem Empfangen machen muss. Wenn die Netzwerkkarte das übernimmt, dann passiert beides währendessen, d.h. die Gesamtzeit zum Bearbeiten eines Paketes ist in jedem Fall kuerzer.
   [*}IP-Offload kann zum Vermeiden von Umkopieren benutzt werden, da sonst die Daten zusammen mit Header usw. in einem neuen Puffer zusammenkopiert werden müssen, bevor es die Netzwerkkarte absenden kann.
6. Schlechte Treiber/Netzwerkkarten legen alle CPUs/Kerne lahm. Das war bis FreeBSD 4 sogar immer so. D.h. solange er im Kernelmode war, ruhten alle anderen Kerne. Je nach Möglichkeit der Netzwerkkartenhardware kann man das weiter reduzieren. Aktuell verteilt sogar eine Netzwerkkarte die Last auf mehrere Kerne (RSS). (Soweit ich das weiss, nutzt FreeBSD das nicht sondern geht einen anderen Weg (ithreads?).)
7. Negativ bei Netzwerkkarten ist oft, dass sie aligned Puffer brauchen. Das scheint aber leider irgendwie immer zu sein.

[Azazyel]

Zitat von rMarkus

Ich hätte bei der Killer-Nic mehr Empörung hier erwartet und auf keinen Fall, dass irgendwer glaubt, dass man das Ding das ernsthatft unter FreeBSD einsetzen will.

Es gab hier schon zuviele Anfragen wegen Metin 2, als das wir noch irgendwie Empörung empfinden könnten.

Zitat von rMarkus

Die Milchmädchenrechnung, dass die CDU-Last der Netzwerkkarten heute keine Rolle mehr spielt, weil die CPUs stark genug sind, möchte ich folgende Punkte entgegenstellen:

Deine Einwände treffen auf "schlechte Netzwerkkarten" vollkommen zu, allerdings sind für den Heimgebrauch selbst die Realtek-NICs inzwischen gut genug, um keinen nennenswerten Einfluss auf die Systemleistung zu haben.

Im Server-Bereich wird von vornherein besseres Material verbaut, dort wirst du keine NIC mit den genannten Schwächen mehr finden. Im High-End-Bereich spielen die Kosten für eine ordentliche NIC eh keine Rolle mehr.

Zitat von rMarkus

Schlechte Treiber/Netzwerkkarten legen alle CPUs/Kerne lahm. Das war bis FreeBSD 4 sogar immer so.

FreeBSD 4 ist vor mehr als 12 Jahren erschienen.

Zitat von rMarkus

Negativ bei Netzwerkkarten ist oft, dass sie aligned Puffer brauchen. Das scheint aber leider irgendwie immer zu sein.

Mein letzte systemnahe Programmierung ist eine ganze Weile her, aber ich kann mich düster an üble Probleme mit DMA erinnern, wenn die Puffer nicht aligned waren. Dafür gibt's aber doch memalign() und valloc(), wo ist das Problem?!

[Yamagi]

Bei der Diskussion um Geschwindkeit, bzw. CPU-Last von Netzwerkkarten, ist der wichtigste Punkt noch nicht genannt: Die Treiber. Damit meine ich nicht Treiber-Bugs und ähnliche Probleme, gerade Intel hat da in der Vergangenheit ja mehrmals tief ins Klo gegriffen, sondern wie gut die Treiber hinsichtlich Performance geschrieben sind.
Man kann die beste Netzwerkhardware unbrauchbar machen, wenn der Treiber schlecht programmiert ist und / oder veraltete Konstrukte nutzt. Umgekehrt kann man selbst schlechte Hardware interessant bekommen, wenn die Treiber okay sind. Mal als ein Beispiel age(4). Als ich ca. 2008 das "Glück" hatte einen Kunden mit einer Menge Maschinen mit age(4) zu übernehmen, hätte ich kotzen können. Dieser Chip triefte vor Hardware-Bugs (z.B. führte das Nutzen von 64-Bit DMA zu Hauptspeicherkorruption), zudem war er grottenlahm. Selbst mit Jumbo-Frames nur ~20mb/s bei hoher CPU-Last. Privat hatte ich einen baugleichen Chip daher durch eine em(4)-Karte ersetzt, dort ging es aber nicht. Also setzten wir uns hin und begannen den Treiber zu überarbeiten:
- Es wurde korrektes, modernes IRQ-Handling per MSI / MSI-X implementiert
- Das BUSDMA-Interface wurde überarbeitet und korrekt mit den rx- und tx-rings integriert.
- Task-Queues schaden auch nie.
- Es wurden diverse Hardware-Features und Workarounds um Hardware-Bugs von Linux portiert.
- Nutze Zero-Copying wo möglich.
Hinterher lief der Treiber wesentlich runder und obwohl an sich unterlegen, musste der Chip sich nicht mehr vor den großen Intel-Karten verstecken. Die Änderungen an miibus(4) in 9.0 brachten noch einmal einen deutlichen Geschwindkeitsschub. Auf einem Phenom II 940 komme ich ohne Jumbo-Frames auf ~90mb/s über eine Gigabit-Verbindung, ohne messbare CPU-Last zu erzeugen. Das ist nahezu optimal und auch wenn deutlich teureren Karten kaum zu toppen. Ich würde zwar age(4) niemals in einem Server einsetzen, wenn es sich vermeiden lässt, aber es zeigt, dass der Treiber wesentlich mehr ins Gewicht fällt als die Hardware. Die Hardware muss es lediglich ermöglichen einen guten Treiber zu implementieren.

[rMarkus]

Richtig Yamagi, der Treiber spielt eine sehr grosse Rolle.

Treiber:
Von der Hardware alleine wäre lt. Papier sicher die HP NC382T (bce(4)) auf dem ersten Platz und erst dahinter dann die Intel 1000 ET (igb(4)) und dann die Intel 1000 PT (em(4)).

Die bce(4) scheinen urspruenglich von Broadcom selbst zu kommen und wurden dann vom FreeBSD-Team gepflegt aber nicht weiter staerker optimiert.

Die Intel-Treiber kommen nach meiner Kenntnis von Intel und dem FreeBSD-Team gemeinsam und werden ständig von beiden Seiten gepflegt und optimiert.

Meine Tests:
Alle Karten habe ich jetzt mal durchgetestet mit größeren Bacula-Recover und alle sind unter FreeBSD unproblematisch.

Die Recover-Tests sind zwar keine richtigen sauberen Tests, aber ich meine, dass die igb(4) gut einen Kern ausgelastet hat während die igb(4) immer deutlich im einstelligen Prozentsatz blieb.

Entscheidung?

Gerade habe ich eher die Tendenz die em(4) durch die igb(4) zu ersetzen, weil sie moderner ist. Anderseits ist die igb(4) deutlich seltener, weil es nur zwei Varianten gibt, während es von der em(4) seit 10 Jahren immer neue Modelle gibt.

Was meint ihr, ist der Treiber igb(4) mit dem em(4) von der Qualität vergleichbar?

[rMarkus]

Ich habe mal Bilder von den Kandidaten gemacht:

[Yamagi]

Ich würde sagen, dass sich igb und em nichts nehmen. Das ist beides der "e1000"-Treiber, lediglich mit anderen Hardware-Backends gebaut. Mir ist nicht einmal klar, wieso es überhaupt zwei getrennte Treiber sind. Sieht man auch in den Makefiles gut:
em: http://svnweb.freebsd.org/base/head/...00&view=markup
igb: http://svnweb.freebsd.org/base/head/...00&view=markup

[rMarkus]

Danke Yamagi.

Dann ist meine Entscheidung, dass ich beim Entreffen des fabrikneuen Exemplars der "Intel Pro 1000 ET Server Dual Port Adapter" igb(4) diese statt der em(4) einbaue.


Danke für Eure Hilfe.

[rMarkus]

Gerade sehe ich, dass es schon für die "Intel 1000 ET" einen Nachfolger gibt: "Intel i350" aka "Intel 1000 VT" gibt.

Bisher habe ich folgendes dazu gefunden:


Hardware:
Wenn man die (Marketing-) Datenblätter vergleicht, dann ist der Unterschied nur, dass die VT 5.0 GT/s PCIe 2.0 statt 2.5 GT/s PCIe 2.0 beherrscht.
Intel 1000 ET
Intel i350 / 1000 VT


In Wirklichkeit wird da der Unterschied aber vermutlich größer sein.


FreeBSD:

• Wird ebenfalls von igb(4) unterstützt, aber erst ab FreeBSD 9.0
• Treiber hatte mindestens anfänglich Probleme mit der Karte

[rMarkus]

Die i350 kann im Gegensatz zur 1000 ET noch Direct Memory Access (DMA) Coalescing, was aber nur zum Energiesparen der (Memory-Controller der) CPU nutzt und unter Stromspartechnologie verbucht ist.

Andere Vorteile z.B. auf die Speicherbelastung scheint es nicht zu haben.

Als Nachteil steigt die Netzwerklatenz noch mal.

[Yamagi]

Eventuell interessiert dich dieses Changeset: http://svnweb.freebsd.org/base?view=...evision=235210 Sollte den Durchsatz bei mehreren igb(4) im System leicht erhöhen.

[rMarkus]

Interessante Änderung, aber mich wundert etwas, dass das nur bei mehreren Interfaces funktioniert.

DIe Hardware der Netzwerkkarte unterstützt zumindest RSS (Receive Side Scaling) und müsste mit nur einem Port die Last auf mehrere Kerne verlagern.

PS: Ich kann grob eine Steigerung bei scp von knapp 10% von em(4) zu igb(4) beobachten. Das hätte ich jetzt nicht erwartet.

[MuffiXXL]

Ich habe mit em so meine Erfahrungen im Tor-Betrieb gesammelt, zugegebenermaßen eine etwas eigensinnige Workload, aber meine Schlussfolgerung ist eher, dass der Treiber Schrott ist. Ich habe das auch länglich mit Leuten auf FreeBSD-Performance@ diskutiert, und da stimmte man mit zu, dass der Treiber an einigen Stellen sehr suboptimal ist.

Leider hatte ich bisher noch keine Chance das ganze mal mit igb oder e1000e zu testen, jedoch würde ich da mehr erwarten.

Für eine "normale" Workload wie Samba o.ä. ist aber auch em vollkommen ausreichend.

[rMarkus]

@yamagi
Gerade ist mir unter aktuellem Linux aufgefallen, dass auch dort das Kernelmodul "igb" der Intel 1000 ET heisst. Wir hatten uns gewundert, wieso es einen igb(4) zusätzlich zur em(4) gibt, obwohl die Sourcen gemeinsam sind.

Zitat von MuffiXXL

Ich habe mit em so meine Erfahrungen im Tor-Betrieb gesammelt, [..] dass der Treiber an einigen Stellen sehr suboptimal ist.

Damit ist gemeint, dass der Treiber der Broadcom unter FreeBSD suboptimal ist?