die perfekte Netzwerkkarte

"Man sagt", fxp (Intel100) wäre sehr schön und rl (Realtek81XX) wäre Käse. Ich habe beide und merke keinen Unterschied, aber die Entwickler hassen das Realtek-Dingens.

hth,
W.
 
Ich hab - onboard - eine VT6102 Rhine II NIC von VIA. Die macht keine Probs, Unterschiede zu anderen hab ich nicht bemerkt. Das einzige was mir aufgefallen ist, ist das Windows (mit Original-Treiber) Zicken gemacht hat (ich hatte regelmäßig 4kbps Download-Geschwindigkeit bei so Dingen wie *BSD oder Debian) --> tut hier aber nichts zur Sache ;)
 
Da die Frage mich immernoch beschäftigt, möchte ich mal eine "Hitliste" beginnen.
Oben besser, unten schlechter.

fxp
Die Varianten mit 82550-Chip z.B. "Intel Pro/100 S" können haben vollwertiges Busmastering mit deskriptorbasiertem Ringpuffer, Interrupt-Moderation und Empfangend sowie sendend Layer 3 und 4 Hardware-Unterstützung - Letzteres können die anderen Varianten mit 82259/8/7-Chip nicht.
Leider wurde Hardware-Flusskontrolle ab FreeBSD 5.4 abgeschaltet.​

vr
Via-Rhine sind günstige Karten bzw. auch Mainboards mit VIA-Chipsatz eingebaut. Diese hätten fast ein vollwertiges Busmasterinterface (Zero-Kopie durch Deskriptor-Ringpuffer), wenn der Chip die Daten nicht "longword aligned" erwarten würde. Das bedeutet, dass die Daten hintereinander und zu 32-Bit Päckchen sauber ausgerichtet vorliegen müssen, was FreeBSD nicht sicherstellt, denn umso weniger die Daten angefasst werden, umso effizienter ist der Datenverkehr. Um den VIA-Controller aber zu befriedigen, muss per Software die Daten vorher jedesmal durch ein Kopieren sauber ausgerichtet werden.​

rl
Diese Chip ist auf fast allen Billig-Netzwerkkarten zu finden. Die Realtek-Chips führen das Busmastering ins Absurde, da es sendend es statt eines Deskriptor-Riungpuffers nur 4 Register gibt. Dabei müssen hier die Puffer wieder passend ausgerichtet sein (longword-aligned). Um das zu erreichen muss nun ein passender Puffer erst zusammenkopiert werden durch die CPU. Ausserdem koennen nur in guten Fällen maximal 4 Transaktionen in der Warteschlange betehen können.
Empfangend sieht es noch übler aus: Hier kopiert der Chip die ankommenden Daten in einen fest dafür vorgesehenen Speicherbereichs (RAM). Er gibt aber keine Auskunft darüber, wo ein Frame endet oder beginnt, daher müssen diese wegkopiert werden und die Frame-Erkennung den höheren Protokoll-Schichten überlassen werden, d.h. die CPU muss Layer 2 Aufgaben für die Karte übernehmen.
Bei CPUs jenseits der 400 MHz können das jedoch schnell genug verrichten, so dass zumindest kein Geschwindkeitseinbruch besteht.
Das Ethernet-Interface des Reaktek-Chips ist ausserdem dafür bekannt, dass er Daten verfälscht und Verbindungen verliert.
​
 
xl:
Diverse 3Com-Kartenmit Marvel Chipsatz (ehemals 3Com Semiconductors). Sie sind zwar teuer, laufen aber meiner Erfahrung nach sehr schnell und zuverlässig. Dank ihrer weiten Verbreitung gut unterstützt, diverse Features (Hardware Checksum...).
 
die besten Karten sind klar die "em", die 1000Mbit Karten von Intel. Oder die "sk"s-1000. Alle guten 1000er Karten outperformen jede 100Mbit Karten auch, wenn sie nur mit 100MBit laufen.

Es gibt keinen Grund 100er Karten zu kaufen.
 
Ich erweitere mal die Hit-Liste mit der Bitte um Kritik und Ergänzung.

fxp
Die Varianten mit 82550-Chip z.B. "Intel Pro/100 S" können haben vollwertiges Busmastering mit deskriptorbasiertem Ringpuffer, Interrupt-Moderation und Empfangend sowie sendend Layer 3 und 4 Hardware-Unterstützung - Letzteres können die anderen Varianten mit 82259/8/7-Chip nicht. Sie zeichnen sich durch ein besonders sauberes PCI-Interface aus und laufen auf den aktuellsten und selbst auf alten 5-Volt Chipsätzen noch sauber.
Leider wurde Hardware-Flusskontrolle ab FreeBSD 5.4 abgeschaltet. Eventuell scheint die Karte mit eingeschalteter Interruptmoderation (link0) langsamer zu werden (bei Samba).​

xl

Die 3Com 3c905* und 3c980* bieten fortgeschrittene Features wie deskriptorbasierenden Ringpuffer und Checksum-Offload. Leider ist ab FreeBSD 5.3 die hardwareseitige Checksumberechnung sendend (TX-SUM) abgeschaltet wurden, da einige nicht identifizierbare Exemplare entweder falsch oder langsam rechneten.
​

vr
Via-Rhine sind günstige Karten bzw. auch Mainboards mit VIA-Chipsatz eingebaut. Diese hätten fast ein vollwertiges Busmasterinterface (Zero-Kopie durch Deskriptor-Ringpuffer), wenn der Chip die Daten nicht "longword aligned" erwarten würde. Das bedeutet, dass die Daten hintereinander und zu 32-Bit Päckchen sauber ausgerichtet vorliegen müssen, was FreeBSD nicht sicherstellt, denn umso weniger die Daten angefasst werden, umso effizienter ist der Datenverkehr. Um den VIA-Controller aber zu befriedigen, muss per Software die Daten vorher jedesmal durch ein Kopieren sauber ausgerichtet werden.​

em

Von der Intel Pro/1000 gibt es in verschiedenen Generationen. Die erste Generation hatte keine Interruptmoderation und HW-Checksum (82542 und ??).
Die 3. Generation (82543 and 8254) haben diese Features, laufen jedoch nicht stabil, denn dadurch werden Frames verschluckt. Das passiert sogar mit nur 100 MBit.
In der 4. Generation (82541, 82541 und evtl. 82547) hat man dieses Problem behoben, indem man die Zahl der Puffer-Deskriptoren von 256 auf 65.000 stark angehoben hat.
Siehe auch: hier
Da diese Probleme auch in 5.4 noch nicht ganz geklärt sind, habe ich sie auf einen hinteren Platz geschoben.
​

rl
Diese Chip ist auf fast allen Billig-Netzwerkkarten zu finden. Die Realtek-Chips führen das Busmastering ins Absurde, da es sendend es statt eines Deskriptor-Riungpuffers nur 4 Register gibt. Dabei müssen hier die Puffer wieder passend ausgerichtet sein (longword-aligned). Um das zu erreichen muss nun ein passender Puffer erst zusammenkopiert werden durch die CPU. Ausserdem koennen nur in guten Fällen maximal 4 Transaktionen in der Warteschlange betehen können.
Empfangend sieht es noch übler aus: Hier kopiert der Chip die ankommenden Daten in einen fest dafür vorgesehenen Speicherbereichs (RAM). Er gibt aber keine Auskunft darüber, wo ein Frame endet oder beginnt, daher müssen diese wegkopiert werden und die Frame-Erkennung den höheren Protokoll-Schichten überlassen werden, d.h. die CPU muss Layer 2 Aufgaben für die Karte übernehmen.
Bei CPUs jenseits der 400 MHz können das jedoch schnell genug verrichten, so dass zumindest kein Geschwindkeitseinbruch besteht.
Das Ethernet-Interface des Reaktek-Chips ist ausserdem dafür bekannt, dass er Daten verfälscht und Verbindungen verliert.
​

Zu sk d.h. Marvell/3Com 940 Chipsatz kann ich nichts sagen, da mein Exemplar (3Com 3c2000T) nicht mit einem Intel BX-Chipsatz laufen will. Die Daten klingen interessant. Der Chip kommt hauptsächlich auf Mainboards vor und ist nur selten auf Steckkarten anzutreffen (evtl. aus dem Grund).
Der große Bruder der Karte 3Com 3c996B-T bge, der sogar PCI-X mit 133 MHz/64Bit unterstützt, läuft mit dem BX übrigens klaglos.
 
Zuletzt bearbeitet:
Ich hatte mal irgendwann Langeweile und habe meine rl gegen eine vr antreten lassen. Dabei habe ich zu meinem Erstaunen festgestellt, dass die rl doch ein Tick (fast 5 MBit/s) höheren Durchsatz bringt:
http://alpha-tierchen.de/dateien/rl_vs_vr.png
Die x-Achse stellt die Größe des zu übertragenden Datenpakets in Bytes zwischen der Server- und der Client-Anwendung dar. Auf der y-Achse ist der Durchsatz in MBit/s. Jede Karte drei mal im gleichen PCI-Slot mit netpipe gemessen; auf der anderen Seite war bei allen sechs Messungen eine xl-Karte.

Björn
 
Zuletzt bearbeitet:
Weiß jemand, wie sich die Karten von Netgear (sis) schlagen? Die benutze ich zuhause nämlich ausschließlich. Gibt es *BSD-relevante Aussagen zur Performance und Qualität dieser Karten?
 
Zum Benchmark:
Das haette ich jetzt nicht gedacht, dass die Realtek besser abschneidet.

Die CPU-Belastung (top) und die Interrupt-Dichte (vmstat -I) sollten aber ebenfalls als Bewertungskriterium mit einfliessen.

Vielleicht sollte man ttcp, netio oder netperf auch mal ausprobieren als Benchmark.
Wichtig waere z.B. auch, wie stark die Netzwerkkarte andere Schnittstellen wie IDE/SCSI-Controller stören auf dem PCI-Bus oder das Speichermanagement bzw. Speicherlast.

Zu SIS:
Ich selbst habe nur in dem WRAP SIS-kompatible Karten und kann das daher nicht testen.
Nach dem Source-Code-Kommentar sollten die etwas besser als die VIA Rhine (VR) sein, denn die haben auch "einfache" deskriptorbasierte Ringpuffer. Die Daten selbst muessen aber nicht ausgerichtet sein wie meim VIA. Lediglich der Deskriptor-Puffer fuer den Empfangspuffer muss ausgerichtet (long word aligned) sein, was aber bei 3*4 Byte pro Puffersegment kaum ins Gewicht fallen sollte.
 
ich benutz nur realtek ,da hab ich mal einen ganzen sack mit 8139c billig gekauft und die funktionieren alle sehr gut egal wo, 2 sind im router ,1x mal server und in meinen pc's und mein dsl ist sehr gut im durchsatz, ,cpu-belastung hab ich auch kontrolliert gerade bei meinem router mit 300mhz, da beträgt die belastung bei mehren downloads 1,5%,okay ,seh ich ein sind keine profikarten aber für den hausgebrauch voll einsetzbar und zuverlässig, das gute ist bei realtek-chips das sie auch von jeden betriebssystem schon lange unterstützt werden und denke auch ausgereift sind, natürlich fürs profi-rechenzentrum dann wohl auch ungeeignet sind und man auf was gutes zurückgreifen sollte, es kommt auch auf den zweck an und wieviel einen das "perfekt" wert ist.
 
Zuletzt bearbeitet:
Da stimme ich zu: Ausgereift und stabil ist wichtigste Kriterium.

Ich habe noch irgendwo eine (geschenkte) Realtek liegen, die probiere ich demnaechst mal aus.

Der Preis ist aber meiner Meinung nach nicht mehr das Kaufkriterium, denn bei Ebay kosten alle Karten 1 bis 5 EUR exklisive Versand.
Selbst neu vom Handler kosten "Intel Pro/100 S" um die 20 EUR, das kann man beim "Geiz-Ist-Geil"-Markt auch mal locker fuer eine Realtek bezahlen. Gut, man bekommt auch Realtek fuer 3 EUR, aber wenn man eine eventuell bessere SIS, VIA, ADMtek fuers gleiche Geld bekommt ...?
Den Preis wuerde ich nicht mehr als Kriterium ansetzen.

Mir ging es bei dem Thread um die technisch perfekte Netzwerkkarte, wobei die Kosten unwichtig sind.
 
das sind meine erfahrungen und da ich mehrere rechner hab hatte ich auch irgendwann kein bock mehr mit verschiedenen herstellern bzw. ihren chips rumzumachen, es gibt da auch die übelesten karten die vom os erkannt werden aber einfach nicht zum laufen zu bewegen sind oder einfach aus unerklärlichen gründen den dienst versagen das sind dann solche wo hersteller xy draufsteht aber chip abc gelötet ist oder unter gleichen namen mit verschiedenen chips bestückt sind, ich hab den kram verschenkt und den sack organisiert,

naja bei ebay-händler ist realtek billig man sollte auch aufs porto gucken,
 
Meine Erfahrungen mit Realtek waren bis jetzt noch nicht so toll. Ich hab hier notgedrungen einen RL8139-Klon im Einsatz (hab ich geschenkt bekommen). Allerdings macht mir die einen schnarchlangsamen Eindruck. Woran das liegt kann ich nicht sagen, am Treiber jedenfalls nicht (wird als rl8139 erkannt).

Mit den Standard-NICs (d509 (?)) hab ich bis jetzt nur gute Erfahrungen geamacht, und eben meine VR. Nur hab ich die leider noch nicht als PCI-Karte gesehen (soll's geben).

Gruß,
Philipp

P.S.: Wie siehts eigentlich mit 10000Mbit-Karten aus? Gibts da schon was?
 
10000 Mbit/s gibt es zwar schon, die Dinger haben allerdings 4 grundlegende Nachteile:
1. Sie sind schwer zu bekommen
2. Sie sind verdammt teuer
3. Sie sind schlecht unterstüzt
4. Es gibt im Hobby-Bereich kein Speichermedium, welches diese Daten verarbeiten könnte
 
Hallo markus.r,

bei mir sind in den Clients ausschließlich "Intel Pro 100/S "-Karten (fxp) eingebaut. Im Server steckt eine Adaptec "ANA-62022 64-bit dual port 10/100baseTX" (in 32-Bit-PCI-Slot eingesteckt). An dieser Karte hängen sowohl mein Intranet (Port 0) als auch T-DSL (Port 1).

Auf der Karte ist ein weiterer PCI-Bus mit zwei Ports, an dem jeweils ein Adaptec-Netzwerk-Chip angeschlossen ist. Laut Handbuch kann man eine Kanalbündelung aktivieren, dann schafft die Karte 800MBit/s. Dies allerdings nur, wenn sie in einem 64-Bit-PCI-Slot steckt und als Busmaster arbeiten darf.
Der FreeBSD-Treiber unterstützt diese Bündelung nicht.

Ob die anderen Features unterstützt werden, weiß ich noch nicht. Ich habe gerade eine Email an den Entwickler abgesetzt.

Beim Kopieren großer Datenmengen konnte ich bis jetzt keine signifikante Reduzierung der "SCSI-Leistung" feststellen. Auch die CPU-Last steigt nur unwesentlich an (FreeBSD 5.3 STABLE).
Anders sieht es aus, wenn alle 8 X-Terminal remote booten. Aber da sind andere Faktoren Ausschlag gebend.

Fazit: Mit der Adaptec-Karte bin ich sehr zufrieden und kann sie ohne Vorbehalte weiterempfehlen.

Die Karte kostete mal ca. 300,-¤, bei eBay habe ich sie für 60,-¤ erstanden, inkl. Kabel, Anleitung und zwei Jahren Garantie.

Viele Grüße

Jürgen
 
@OOZE: Danke für deine Infos. Es war eine reine Interessensfrage. Kaufen möchte ich mir sowas nicht. Wäre in meinem Fall auch ein totaler Overkill :)

@markus.r: Ich such mit, ich brauch nämlich nen Ersatz für diesen sch**ß Realtek-Klon.
 
Der Vergleich hinkt etwas, aber es ist wie mit den Rolex-Uhren: Die Realtek-NICs sind so "beliebt" oder was auch immer, das es viele Hersteller gibt, die Netzwerkkarten bauen, die genauso aufgebaut sind wie's Original. Auf dem Chip steht dann halt was anderes drauf, aber drin ist kopierte RL-Technik. Ob die das nun abkupfern oder legal nachbauen ist mir egal, solange es gescheit funktioniert. Was in meinem Fall nicht so ist.
 
Hallo Juedan,

sehr aehnlich habe ich das auch hier:
Meine Clients sind fast vollstaendig mit "Intel Pro/100 S Desktop Adapter" ausgeruestet. Der "Intel Pro/100 S Server Adapter" funktioniert leider unter FreeBSD nicht mit Interrupt-Moderation (link0), so dass der Desktop-Adapter ihm dann unter FreeBSD ueberlegen ist.

Mein Router hatte lange Zeit ebenfalls eine Dual-Intel-Pro/100 von Compaq, wobei zwei Chips auf einer Karte sassen, welche eine 66MHz/64Bit PCI-Bridge besitzt.
Diese lief selbst fehlerfrei in einem der ersten Intel-Pentium1-Chipsaetzen.

Heute habe ich einen WRAP mit NatSemi-Chip (SIS) - bisher Fehlerfrei. Habe das WRAP ausgepackt, die bespielte Flash-Karte eingesteckt, gebootet und er l*uft nun seit 50 Tagen durch.

In meinem Server hatte ich bis vor Kurzem auch eine "Intel Pro/100 S", welche ich aber durch eine 3Com 3c996B-T (bge) abgeloest habe.
Die 3Com l*uft problemlos, kann aber kein RXsum, wirkt aber subjektiv schneller als die Intel bei Samba.

Frueher hatte ich auch mal eine 4-Port Adaptec mit PCI-PCi-Bridge und 4 DEC-Chips (de).
Von der Karte kann ich nur abraten, da das Ringpuffermanagement unter Last zum Over- bzw. Unterflow neigt. In /var/log/messages kann man dann auch sehen, dass der Treiber mehrfach die Schwellenwerte umschaltet. Er macht das jedoch erst nach einem Timeout und nach Paketverlust. Erst nach einigen Problemen findet der Treiber das richtige Mischungsverhaeltnis und laeuft akzeptabel.
Der Linux-Treiber der Karte reagiert uebrigens empfindlicher und blockiert weiterhin bzw. findet kein gutes Verhaeltnis.

Juedan benutzt aber anscheinend die neuere Version mit dem Starfire oder Sundance (?) Chipsatz.
Welcher BSD-Treiber wird denn verwendet bzw. was kann die Karte (Checksum usw.)?
 
Hallo Markus,

so ich habe der Einfachheit halber mal alle Features der Karte zusammengetragen. Die Liste ist etwas umfrangreich geworden...
  • Supports four general purpose I/Os that can be programmed separately as inputs, outputs, open-drain outputs or, interrupt inputs
  • Interface to an external, 8-bit Boot ROM with a maximum size of 256-KByte
  • Supports dynamic system bus (PCI) clock where the network can continue to operate at any clock frequency
  • Internal loopback on all network ports for testing purposes
  • IEEE 1149.1 compliant JTAG Boundary Scan Test Access port Ethernet
  • IEEE 802.3 compliant 10/100 MII that supports Category 3 UTP, Category 5 UTP, Type 1 STP and Fiber cables
  • IEEE 802.3.x compliant Flow Control mechanism
  • Supports Cisco proprietary VLAN ISL frame format
  • Supports IEEE 802.1q (VLAN) frame format
  • Supports PCI and OnNow power managementSupports OnNow wakeup function
  • Calculates TCP/IP checksum in transmit mode
  • Checks TCP/IP checksum in receive mode
  • Supports full-duplex operation on all ports (MII, 10/100 Twisted Pair)
  • Provides a variety of address filtering modes:
  • Promiscuous 16 full 48-bit addresses
  • 512-bit hash table for multicast address filtering
  • Time stamp information of every frame received DMA
  • Two transmit DMA queues to prioritize network traffic
  • Enhanced interrupt mechanism increases performance and reduces CPU utilization:
  • Transmit DMA Complete (Early Transmit) Early receive
  • Transmit/Receive buffer under/over flow error handling.
  • No software intervention requiredDMA channel arbitration eliminates overrun/underrun of First-In-First-Out (FIFO) buffers
  • Supports 32- and 64-bit addressing of Host DMA buffers and DMA descriptor queues
  • Big/Little endian support for data and descriptors
  • Special output pin to indicate high-priority PCI request Internal Buffer Management
  • Large, 8 KByte DMA FIFO (default - 4KByte for transmit, 4-KByte for receive)
  • Programmable hardware-controlled transmit FIFO thresholds to prevent underrun of transmit FIFO and enhance overall system performance
  • Unlimited (limited only by the FIFO size) Receive/Transmit frame queueing in the FIFO to handle long PCI bus latencies
  • Hardware support for handling transmit collisions and FIFO underruns without software intervention 32/64-bit PCI
  • Compliant with PCI Local Bus Specification revision 2.1
  • Compliant with Intel PCI Bus Power Management Interface Specification Rev 1.00 and Microsoft Device Class Power Management Reference Specification (OnNow)
  • PC 97 ready. Implements all hardware features required by Microsoft s PC 98 design specification
  • Supports 3.3V and 5.0V PCI signaling
  • Direct pin out connection to PCI 32/64-bit bus interfacePCI bus master with zero wait state 32/64-bit memory data transfers at 133/266 MBytes/sec, capable to support leading and trailing byte offset for DMA read and write (32-bit) for DMA write
  • Supports 64-bit addressing in master and target modesPCI bus master/slave timing referenced to PCI signal PCLK (33.3 MHz max)
  • PCI bus master programmable Latency Timer, Cache Size, And Interrupt Line Select registers
  • Automatically senses if the adapter is plugged into a 32-bit or a 64-bit PCI slot.
  • Supports cache line sizes of 16, 32, 64, 128, and 256 bytes
  • Supports any combination of active byte enables for all PCI slave accesses
  • Supports medium PCI target device-select response time
  • Supports, as a bus master, enhanced PCI System memory data read and write commands:
  • Memory Read
  • Memory Read Line
  • Memory Read Multiple
  • Memory Write
  • Memory Write And Invalidate
  • Supports PCI bus address and data parity generation and checking
  • Supports PCI PERR and SERR requirements
  • Supports 8-bit, 256-KByte, external Memory port for interface with external Boot ROM or devices/registers
  • Supports external Boot ROM access from memory or Expansion ROM address space
  • Supports an external serial EEPROM for downloading chip configurations and MAC address
  • INTA_ interrupt generation from hardware, firmware, and software controlled sources
  • Supports PCI slave accesses to PCI Configuration Header from configuration (read/write), I/O (indirect, read only) and memory address spaces (read only)
  • Supports PCI slave access to AIC-6915 functional registers from configuration, I/O and memory address spaces
  • Supports PCI slave access to AIC-6915 debug/buffer/FIFO Ethernet registers (implemented in the Ethernet control module) and external Memory port from indirect I/O and memory address spaces
  • PCI target latency of 16 clocks maximum for the first target access cycle. The AIC-6915 initiates a cycle retry when an access requires more than 16 clocks to complete

Zusätzlich hat jeder AIC6915-Chip 8KByte SRAM on die für diverse Caches.

Die Karte wird vom Treiber sf angesprochen. Dazu ein Auszug aus dmesg (FreeBSD 5.3 STABLE #1):
Code: 
sf0: <Adaptec ANA-62022 10/100BaseTX> port 0x4000-0x40ff mem 0xf0300000-0xf037ffff irq 20 at device 4.0 on pci3
miibus0: <MII bus> on sf0
sf0: Ethernet address: 00:00:d1:d9:aa:4d
sf0: if_start running deferred for Giant
sf1: <Adaptec ANA-62022 10/100BaseTX> port 0x4400-0x44ff mem 0xf0380000-0xf03fffff irq 21 at device 5.0 on pci3
miibus1: <MII bus> on sf1
sf1: Ethernet address: 00:00:d1:d9:aa:4e
sf1: if_start running deferred for Giant


Viele Grüße

Jürgen
 
markus.r schrieb:
Mein Router hatte lange Zeit ebenfalls eine Dual-Intel-Pro/100 von Compaq, wobei zwei Chips auf einer Karte sassen, welche eine 66MHz/64Bit PCI-Bridge besitzt.
Diese lief selbst fehlerfrei in einem der ersten Intel-Pentium1-Chipsaetzen.
Zum Vergrößern anklicken....
Die hab ich in meinen "Hauptrechner". Definitiv ein klasse Stück Hardware.

Heute habe ich einen WRAP mit NatSemi-Chip (SIS) - bisher Fehlerfrei. Habe das WRAP ausgepackt, die bespielte Flash-Karte eingesteckt, gebootet und er l*uft nun seit 50 Tagen durch.
Zum Vergrößern anklicken....
Auch da schliess ich mich an - auch wenn ich die 50 Tage schon hinter mir hab.

Dynamisches ändern der Puffergrößen hat xl(4) übrigens inzwischen auch. Zumindest bei meinen 3c-905-cx-tx-m. Sieht mir auch immer nicht ganz gewollt aus.
 
zu Jürgen:
Ich hatte mal diese Adaptec ANA-6944A/TX, welche mit de (4) "funktionierte". Von der kann ich nur abraten - unter jedem Betriebssystem.

Die Adaptec-Starfire sieht aber richtig gut aus.
Hast Du noch den Ausdruck von ifconfig, dann kann man die unter FreeBSD nutzbaren Features sehen.


zu Elessar:
Bei der xl(4) habe ich das auch bei einer 3Com 3c-905B-TX beobachtet (ich meine ein sendender underrun).
Das passiert allerdings sehr selten und bis auf den Eintrag in die Messages ist das aber nicht spürbar, oder?

Noch ein sehr wichtiges Kriterium für eine gute Netzwerkkarte ist folgende Liste:
FreeBSD busdma und SMPng driver conversion project

Bei SMP-Systemen ist es sehr wichtig, dass die Treiber "INTR_MPSAFE" und "SMPng locked" sind. Ansonsten gilt überspitzt die alte Unix-Devise: Der Kernel ist ununterbrechbar und die anderen CPUs drehen solange Busy-Waiting-Loops.
Auch die Nutzung "Busdma" spielt hier eine Rolle sowie auch bei der Plattformunabhängigkeit.
Bei Systemen mit mehreren Gigabyte RAM ist "a!=p" wichtig.
 
Zuletzt bearbeitet:
markus.r schrieb:
zu Jürgen:
zu Elessar:
Bei der xl(4) habe ich das auch bei einer 3Com 3c-905B-TX beobachtet (ich meine ein sendender underrun).
Das passiert allerdings sehr selten und bis auf den Eintrag in die Messages ist das aber nicht spürbar, oder?
Zum Vergrößern anklicken....
Das war das $ext_if meines alten Routers.
Und nuja, lag da jetzt eine Latenzerhöhung vor? Fiel die mit der Meldung zusammen? Lags daran oder wars einfach nur der Uplink?

Ich kanns nicht sagen. Hat jedenfalls das log unnötig zugemüllert.
 
Hallo Markus,

markus.r schrieb:
zu Jürgen:
Ich hatte mal diese Adaptec ANA-6944A/TX, welche mit de (4) "funktionierte". Von der kann ich nur abraten - unter jedem Betriebssystem.
Zum Vergrößern anklicken....
Stimmt. Die verbauen wir in unseren Servern für die Kunden auch nicht mehr.

Die Adaptec-Starfire sieht aber richtig gut aus.
Hast Du noch den Ausdruck von ifconfig, dann kann man die unter FreeBSD nutzbaren Features sehen.
Zum Vergrößern anklicken....
Bitte sehr, bitte gleich:
Code: 
sf0: flags=108843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
        inet6 fe80::200:d1ff:fed9:aa4d%sf0 prefixlen 64 scopeid 0x1
        inet 192.168.1.200 netmask 0xffffffff broadcast 192.168.1.200
        inet 192.168.1.201 netmask 0xffffffff broadcast 192.168.1.201
        ether 00:00:d1:d9:aa:4d
        media: Ethernet autoselect (100baseTX <full-duplex>)
        status: active
sf1: flags=108843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet6 fe80::200:d1ff:fed9:aa4e%sf1 prefixlen 64 scopeid 0x2
        ether 00:00:d1:d9:aa:4e
        media: Ethernet autoselect (10baseT/UTP <full-duplex>)
        status: active

Bei SMP-Systemen ist es sehr wichtig, dass die Treiber "INTR_MPSAFE" und "SMPng locked" sind. Ansonsten gilt überspitzt die alte Unix-Devise: Der Kernel ist ununterbrechbar und die anderen CPUs drehen solange Busy-Waiting-Loops.
Auch die Nutzung "Busdma" spielt hier eine Rolle sowie auch bei der Plattformunabhängigkeit.
Bei Systemen mit mehreren Gigabyte RAM ist "a!=p" wichtig.
Zum Vergrößern anklicken....
An dem Treiber wird gerade gearbeitet, so wie ich es dem CVS entnehmen konnte.

Viele Grüße

Jürgen
 
Zuletzt bearbeitet von einem Moderator:
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben