• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

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

rMarkus

Chuck The Plant
Themenstarter #1
Hallo,

eure Meinung möchte ich erfahren, welche Netzwerkkarte die bessere ist?
  • Intel Pro 1000 PT Server Dual Port Adapter: em(4)
  • Broadcom NetXtreme II 5709C (HP NC382T) bce(4)
  • Intel Pro 1000 ET Server Dual Port Adapter: igb(4)

Hintergrund ist folgender, dass ich mit Intel 1000 PT immer sehr gute Erfahrungen gemacht habe, jedoch aus Sicht der Funktionen die neuere Broadcom spürbar überlegen sein sollte.

Daher möchte ich nach Erfahrungen zu folgenden Punkten fragen:
  1. Geschwindigkeit
  2. CPU-Last (Qualität Interrupt-Moderation bzw. Interrupt-Load)
  3. Features (nutzbar unter FreeBSD 7.3)
  4. Treiberqualität (insbesondere unter FreeBSD 7.3, Pufferüberläufe und weitere bekannte Probleme?)
  5. Verwendung per IPMI

Ist bei der Verwendung der Broadcom-Karte ein Upgrade des FreeBSD 7.3 anzuraten?
Die Intel PT ist bereits seit Jahren verbaut und funktioniert absolut fehlerfrei, während die "Intel ET" neuer ist, mehr kann, aber scheinbar keine Verbreitung findet.
 
Zuletzt bearbeitet:

rMarkus

Chuck The Plant
Themenstarter #2
in der Changelog von bce(4) habe ich folgendes Gefunden:

  • PRO: TSO ist unterstützt
  • CONTRA: RX-Buffern müssen 8-byte Alignment haben wegen Hardwareeinschränkung (zusätzliches Umkopieren notwendig?)
In den Changelogs der bce(4) habe ich folgendes gefunden:
 

rMarkus

Chuck The Plant
Themenstarter #3
Endlich habe ich die beste Netzwerkarte gefunden:

Code:
pciconf -l
none2@pci0:9:0:0:       class=0x0b2000 card=0x11011a56 chip=0x00b61957 rev=0x11 hdr=0x00

pci9: <processor> at device 0.0 (no driver attached)
Leider gibt es keinen Treiber unter FreeBSD 7.3
 

rMarkus

Chuck The Plant
Themenstarter #5
FreeBSD 9.0
Code:
pci9: <ACPI PCI bus> on pcib9
pci9: <processor> at device 0.0 (no driver attached)
 

mapet

Active OpenBSD User
#6
dann wird es wohl nicht die beste sein, denn diese hätte treiber und könnte verwendet werden ;)

btw. manche behaupten sowas auch von realtekkarten *schüttel*
 

MuffiXXL

Well-Known Member
#7
Ich hab da letztens mal mit bce rumgemacht. Auf Linux eigentlich nicht verkehrt, aber der FreeBSD Treiber ist irgendwie Crap. Der kam von der Geschwindigkeit verglichen mit em nicht so ganz mit und hat ordentlich CPU Last erzeugt.
 

Azazyel

Well-Known Member
#8

mapet

Active OpenBSD User
#9
bei meinen eltern werkelte eines dieser onboard wunderwerke auch hinter eine wlan-brücke. alle paar tage musste diese resettet werden, da die karte ihr netz nicht mehr gefunden hat. nach dem 10 mal hab ich eine intelkarte eingesetzt und es war ruhe. eine davon hab ich mit linuxeigenen treibern nicht ans laufen bekommen und mit den herstellertreibern hatte sie dann unter last minutenweise aussetzer.
leider sind sie unter den onboardkarten auf consumerhardware weit verbreitet. meine freundin hat unter win7 auch eine im einsatz und bisher auch keine schwierigkeiten damit. mal sehen, wie die andere auf dem router sich mit der zeit verhält.
 

MuffiXXL

Well-Known Member
#10
bei meinen eltern werkelte eines dieser onboard wunderwerke auch hinter eine wlan-brücke. alle paar tage musste diese resettet werden, da die karte ihr netz nicht mehr gefunden hat. nach dem 10 mal hab ich eine intelkarte eingesetzt und es war ruhe. eine davon hab ich mit linuxeigenen treibern nicht ans laufen bekommen und mit den herstellertreibern hatte sie dann unter last minutenweise aussetzer.
leider sind sie unter den onboardkarten auf consumerhardware weit verbreitet. meine freundin hat unter win7 auch eine im einsatz und bisher auch keine schwierigkeiten damit. mal sehen, wie die andere auf dem router sich mit der zeit verhält.
es wäre jetzt schön, wenn du darauf eigehen würdest was das für ne Karte ist, weil schrottige Netzwekrtreiber gibt es viele und schrottige Hardware dafür irgendwie auch.
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#13
Es steht ja "Killer Xeno" drauf. Zu dem Ding findet man unter anderem: http://www.golem.de/0903/66069.html

Insbesondere Datenpakete von Spielen soll die Killer Xeno so behandeln und durch den eigenen Prozessor auch den Hauptprozessor entlasten, der dann mehr Ressourcen für das Spiel bereitstellen soll. Bis zu 256 MByte RAM sollen der mit 400 MHz getakteten NPU (Network Processing Unit) helfen. Damit auch VoIP-Verkehr schnell genug über die Leitung geht, wird auch dieser durch die Hardware beschleunigt. Dazu sind zwei Audiobuchsen direkt an der Netzwerkkarte vorhanden. Der Vorgänger Killer NIC hatte diese noch nicht.
Außerdem können Anwender auf der Netzwerkkarte Programme ausführen lassen. So lädt die Netzwerkkarte etwa BitTorrent-Dateien selbstständig herunter. Auch die Voice-Chat-Anwendung Mumble soll direkt auf der Netzwerkkarte laufen. Bigfoot hat die Software dafür auf die NPU portiert. Die Treiber der Karte unterstützen Windows XP und Windows Vista.
Unabhängig vom verbauten Netzwerk-Cip klingt das für mich sehr nach proprietärem Gebastel, was kaum ohne Weiteres funktionierten wird... :(
 

rMarkus

Chuck The Plant
Themenstarter #14
Als Netzwerk-Chip ist ein Marvell 88E111R auf der Rueckseite unten verbaut.
Dieser ist aber nur Gigabit Ethernet Transceiver und hängt hinter der CPU, d.h. man sieht nur die CPU von der PCIe-Seite und kann nicht an der vorbei mit dem Netzwerk-Chip sprechen.
 

Azazyel

Well-Known Member
#15
Als Netzwerk-Chip ist ein Marvell 88E111R auf der Rueckseite unten verbaut.
Dieser ist aber nur Gigabit Ethernet Transceiver und hängt hinter der CPU, d.h. man sieht nur die CPU von der PCIe-Seite und kann nicht an der vorbei mit dem Netzwerk-Chip sprechen.
Die Karte wirst du wohl nie unter etwas anderem als Windows zum Laufen kriegen.
Aufgrund des Preises und der Zielgruppe (Hardcore-Zocker, d.h. 100% Windows) glaube ich auch nicht, dass sich jemand die Mühe machen wird, einen Treiber für ein anderes Betriebssystem zu schreiben.

Auf einem halbwegs aktuellen Server spielt die CPU-Last der Netzwerkkarte sowieso keine Rolle.
 

rMarkus

Chuck The Plant
Themenstarter #16
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

Well-Known Member
#17
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. ;)

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.

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.

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

Possessed With Psi Powers
Mitarbeiter
#18
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

Chuck The Plant
Themenstarter #19
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?
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#21

rMarkus

Chuck The Plant
Themenstarter #22
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

Chuck The Plant
Themenstarter #23
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

Chuck The Plant
Themenstarter #24
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.