Dual Core CPU: IRQ-Problematik behebbar?

Eisenfaust

Well-Known Member
Hallo.
Meine Frage mag einigen vielleicht naiv erscheinen, sie ist allerdings essentiell.

Ich habe ein ASUS A8N32-SLI Mainboard, das zur Zeit noch mit einer AMD 3500+ Single-Core CPU mit Winchester-Kern bestückt ist. Das Board hat 2GB DDR400-ECC RAM. Als Betriebssystem läuft FreeBSD 7.0-CURRENT/amd64.

Mein Problem ist, daß sich der Netzwerk-Controller des CK804 (nForce4) Chipsatz, MCP9, einen IRQ mit dem USB Controller teilen muß und das führt leider aus mehreren Gründen aktuell zu massiven Problemen mit dieser Hardware, die zuweilen die Maschine nutzlos machen. Der MCP9 ist nach Aussage einiger Entwickler nicht MSI/MSI-X-fähig, so daß der IRQ Konflikt nicht ohne Probleme vermeidbar scheint. Unter hoher System- und Netzlast verabschiedet sich der nfe-Controller ab und an mit einem watchdog-Timeout und alle USB Geräte werden mehrere Minuten in den Zustand der Inaktivität geschickt. Das schließt Maus, externe Platten und USB-Sticks mit ein. Aktiviert man Polling, sind die Probleme mit den IRQs nicht mehr vorhanden, allerdings ist die gesamte Systemleistung dann mehr als Lächerlich. Rechenleistung, Platten- sowie Netzdurchsatz sind um 25 - 30% niedriger, X11 reagiert nur noch zäh.
Die Verwendung des onboard msk0-Chips (zweiter NIC von Broadcom) ist fatal, dieser, obschon MSI-fähig, verabschiedet sich nach wenigen Minuten.

Nun, lange Rede kurzer Sinn, ich möchte wissen, ob sich an der IRQ Situation unter Verwendung einer Dual-Core CPU etwas ändert. Von Mehrsockel-Systemen aus der Pentium-III Zeit weiß ich, daß mit der zweiten CPU ein weiterer IO-APIC hinzukam, der gleich ein paar IRQs mitbrachte und so oft Engpässe glättete. Da ich kein Technikmensch in dieser Hinsicht bin, gebe ich nur wider, was ich mal gelesen habe.
Vielleicht ist jemand hier, der mir sagen kann, ob zum Beispiel der einsatz eines Opteron 185 etwas hinsichtlich IRQ-Sharing bringt.

Dank im voraus,

Grüße,
E.
 
hmmm, das mit dem watchdog-timeout kommt mir irgendwie bekannt vor... hast du mal versucht, dem nfe das autosensing abzugewöhnen den fest auf 100/FullDuplex zu setzen? irgendwas hatte ich mal auf der obsd-misc@ gelesen, das der chipsatz da fest drauf gesetzt werden muss, sonst steigt der bei hoher netzlast aus. bei interesse such ichs auch gerne nochmal raus...

EDIT: habs gerade greifbar: hier ist der thread. vielleicht hilfts dir ja weiter...
 
Zuletzt bearbeitet:
Hallo Eisenfaust,

wäre es nicht ein einfacher Workaround,
eine gute, von FreeBSD 1a unterstützte, Netzwerkkarte einzubauen
und diese zu benutzen,
um die Problembehafteten Onboard Netzwerkkarten zu deaktivieren
und einfach nicht zu benutzen?

Eine dickere CPU hat verständlicherweise ihre gewissen Reize,
kommt mir aber irgendwie wie "mit dem Schinken nach der Wurst werfen" vor. ;)


Gruß, Fusselbär
 
Hallo Eisenfaust,

wäre es nicht ein einfacher Workaround,
eine gute, von FreeBSD 1a unterstützte, Netzwerkkarte einzubauen
und diese zu benutzen,
um die Problembehafteten Onboard Netzwerkkarten zu deaktivieren
und einfach nicht zu benutzen?

Eine dickere CPU hat verständlicherweise ihre gewissen Reize,
kommt mir aber irgendwie wie "mit dem Schinken nach der Wurst werfen" vor. ;)


Gruß, Fusselbär

... wäre, aber nur hypothetisch, da es sich dabei wieder um 'Investitionen' handeln würde. Eine vernünftige Intel GBit LAN Karte ist auch nicht umsonst. Da aber ganz offenbar BEIDE onboard Netzkarten unter FreeBSD auf dem A8N32-SLI fast unbrauchbar sind, ist dieser Gedanke gewiß verfolgenswert.

Der CK804 mit SPP51 soll ja identisch dem nF2200 sein und dort scheint die NIC (auch nfe) zu funktionieren ... :-(

Eine größere CPU ist mitlerweile ein muß, da mein Rechner zu langsam rechnet. Bis heute Nachmittag war ich drauf und dran, auf einen Opteron 185 zu spekulieren und es wäre Klasse, wenn durch die beiden APICs das IRQ-Routing und -Sharing Problem gelöst wäre. Allerdings hat AMD heute sämtliche Möglichkeiten jedwedem rationalen Boden entzogen - die Sockel 939 CPUs sind gleichteuer geblieben. Da wechselt man ob diesen Schwachsinns bei der erstbesten Gelegenheit ins gegnerische Chipzilla-Lager ...
 
hmmm, das mit dem watchdog-timeout kommt mir irgendwie bekannt vor... hast du mal versucht, dem nfe das autosensing abzugewöhnen den fest auf 100/FullDuplex zu setzen? irgendwas hatte ich mal auf der obsd-misc@ gelesen, das der chipsatz da fest drauf gesetzt werden muss, sonst steigt der bei hoher netzlast aus. bei interesse such ichs auch gerne nochmal raus...

EDIT: habs gerade greifbar: hier ist der thread. vielleicht hilfts dir ja weiter...

HAllo makenoob,

das beschriebene Problem mit der Fixierung des Übertragungsmodus betrifft offenbar nur den nForce3-250 Chipsatz. Dieser Chipsatz hatte seine Probleme, wohl weil nVidia per Übertakten des nForce3 so nochmals gute Geschäfte machen konnte.

Auf meinem Board arbeitet der nForce4/CK804 mit einer SPP (nForce4X32, zwei Chip Lösung). Vermutlich ist dieses Gespann genauso überzüchtet, jedenfalls arbietete mein Vorgängerboard, das ASUS A8N-SLI Deluxe weitaus performanter! Und das, obwohl dort 'nur' der einfache nForce4 verbaut war.


Habe jetzt nochmals ein wenig experimentiert. Das Festsetzen der Netztgeschwindigkeit bringt leider nichts.

Traurig ist, daß ich im Labor einen Intel P4 mit 3.0 GHz und HTT stehen habe, der auf einem Intel P865 Chipsatz basiert. Obwohl die Kiste technisch meinem AMD unterlegen ist und auch in puncto Rechenleistung gegenüber meinem mit 2,2 GHz getakteten 3500+ das Nachsehen hat, ist der Kasten bei ähnlicher Last weitaus 'responsiver'. Ob das nun am SMP-Kernel und HTT liegt, weiß ich nicht und wage es zu bezweifeln. Ich muß mir nur die Plattendurchsätze ansehen und da tut sich ein Kuriosum auf.
Meine AMD Kiste benutzt zwei Hitachi T7K250 250GB Platten als RAID 0 (ar0) am nForce SATA Controller. bonnie bescheinigt mir Peak bis zu 119 MB/s, die Einzellaufwerke liegen bei 35 - 59 MB/s, je nach Test. Im taglichen Betrieb merke ich davon nur nicht viel, der Plattendurchsatz ist als durchaus zähfließend zu bezeichnen, I/O-Operationen scheinen das ganze System lahm zu legen. Dabei gibt es kein IRQ-Sharing mit SATA Controller und anderen Geräten. Eine Beobachtung mit systat -vmstat 1 zeigt, daß, auch bei großen zusammenhängenden Datenblöcken, der Durchsatz nie 30 MB/s übersteigt - was sehr komisch ist.

FreeBSD hat wohl ein generelles Problem ... :-(
 
ich hatte auch mal so ein ähnliches phänomen mit ner sata-raidkarte... da hatte ich durchsatzgeschwindigkeiten von wenigen MB. der grund war, dass ich im BIOS was verbockt habe (eigentlich habe ich nur den fdd-controler und onboard SCSI deaktiviert, aber das scheint gereicht zu haben). jedenfalls nach einem zurückschalten auf "safe default" hat der jetzt "normale" durchsatzgeschwindigkeiten bei den platten etc. also es ist nicht immer das os, was da auf der bremse steht...

ich habe in meinem desktop-rechner auch die onboard abgeschaltet und ne intel reingepackt. die gibts bei alternate bereits schon für relativ wenig geld (die desktop versionen; die "server"-dinger sind deutlich hochpreisiger). bei mir wars allerdings auch ne realtek onboard.
 
ich hatte das gleiche problem mit einem nforce board.

hol dir eine neue netzwerkkarte, fuer wenig geld. gar nicht viel.
dann hast du das problem nicht mehr.
 
Ich hatte, wenn auch unter OpenBSD, auch massiv probleme mit meiner NVIDIA-Onboard-Nic, nach ersatz durch einen intel (zei

Nachdem ich die gegen eine Intel (Zeitweise auch eine 3com) getauscht hatte, hatte ich keine Probleme mehr.
 
Hatte genau das gleiche Problem mit NVIDIA-onboard-Ethernet.
Ich konnte das Onboard-Netzwerkzeug vom NVIDIA-Chipsatz erst mal überhaupt nicht zum stabilen Laufen bewegen. Watchdog-Timeouts bei Transfer; wenn Interface mal lief, dann nur das Interface selbst pingbar, sonst ging nichts, usw.

1. Lösung (wie oben beschrieben): Intel-Karte installieren, onboard abschalten. Ist wahrscheinlich die solideste Lösung, einfach, sauber, keine Probleme.

2. Lösung: "device polling" aktivieren.
Im Kernel

options DEVICE_POLLING

eintragen und Kernel neu bauen. Danach lässt sich per "ifconfig nfe0 polling" das Polling aktivieren. Das kann man auch in die rc.conf eintragen, einfach das "polling" hinten an die if_xxx-Zeile anhängen.

Polling bewirkt, dass das OS aktiv die Netzwerkkarte abfragt (default mit 1000Hz), und dabei das Interrupt-Handling ignoriert wird. Das scheint bei IRQ-Konflikten mit Netzwerkkarten Wunder zu wirken, grade bei NVIDIA-Chipsätzen.

Weiteres unter "man 4 polling".

3. Lösung: http://www.f.csce.kyushu-u.ac.jp/~shigeaki/software/freebsd-nfe.html checken

Habe meine beiden Onboard-Schnittstellen überhaupt nur so zum Laufen gebracht, bis ich auf ne Intel-Gigabit-Karte umgestiegen bin...
 
Zuletzt bearbeitet:
Zurück
Oben