Re: tl0-tx underrun - Fehler

On 2000-07-25 13:37 +0200, Dejan Grujin <DGrujin(at)b-o-p.de> wrote:
> Und nochmal ich...
>
> Ich habe hier an einer Netzwerkkarte (Im selben Rechner, in dem ich das
> Problem mit dem watchdog timeout hatte) das Problem, daß ich ständig
> diese Meldung bekomme:
> Rechnername /kernel: tx0: tx underrun -- increasing threshold to 512
> bytes. Und das erhöht sich dann immer um 256 bytes, also 768, dann 1024.
> Ich habe auf der manpage geschaut, da aber nichts gefunden. Dann in der
> source unter /sys/pci/if_tl.c geschaut. Bin aber nicht so der C-Experte,
> konnte nicht rauslesen, WARUM er das macht, habe die Funktion gefunden,
> aber konnte ehrlich gesagt nichts damit anfangen...:-( So, what can I
> do?

Die Transceiver Underruns passieren dann, wenn der Ethernet-Chip mit dem
Senden der Daten anfängt, bevor alle Daten per DMA in den Sendebuffer
übertragen wurden. Das macht man normalerweise, weil der PCI-Bus wesentlich
schneller ist, als selbst ein 100baseT Netz. (Im Grunde reicht es ein paar
Byte im Ethernet-Chip zu haben, da dort nur alle 100ns ein Byte gesendet
wird, der PCI-Bus innerhalb eines Burst aber alle 30ns 4 neue Bytes liefert.)

Der Vorteil des frühen Sendens ist, daß das erste Byte des Pakets schon
beim Empfänger sein kann, während der Sender noch Daten in den Ethernet-
Controller schreibt ...

Allerdings gibt es noch andere Geräte, die gelegentlich mal den PCI-Bus
anfordern. Daher kann es passieren, daß der Ethernet-Chip auf Zuteilung
wartet, während sein Sendepuffer leer läuft.

Wenn das passiert, dann wird die Meldung ausgegeben, und in der Folge wird
die Anzahl Bytes, die im Chip sein müssen, um 256 erhöht. Damit wird das
Risiko eines erneuten Underrun geringer.

Ob der PCI-Bus immer rechtzeitig zur Verfügung steht, das hängt u.a. davon
ab, wieviele PCI-Devices im Bus-Master-Betrieb größere Datenmengen übertragen.
Generell ist eine große Burst-Länge effizienter, aber wenn in der Zeit ein
anderes PCI-Device "verhungert", dann kann z.B: das Reduzieren des Wertes
des PCI Master Latency Timer eine Abhilfe darstellen.

Der Wert ist in Einheiten des PCI Bus-Taktes, also 30ns. D.h, wenn der
Ethernet-Chip einen FIFO von 256 Byte hat, dann kann er bei 100baseT bis
maximal 25.6 Mikrosekunden auf den PCI-Bus warten (unter der Annahme, daß
er beim Senden des ersten Bytes auf dem Ethernet anfängt Daten auf dem
PCI-Bus nachzulesen; tatsächlich liegt die Schwelle anders, ich schätze,
daß tatsächlich bei 128 Byte leerem Sende-FIFO ein Bus-Request erzeugt
wird, was maximal 12.8us Wartezeit zuläßt).

Der Master-Latency-Timer läßt sich sinnvoll auf Werte zwischen 20 und 255
einstellen. Bei 20 wäre die Burst-Länge auf ca. 50 Byte beschränkt, wenn
viele Geräte den Bus benötigen (20Takte - 6Takte Adress-Übertragung und
Dekodierzeit => 14 Takte für Transfer, 4 Byte/Transfer => 52 Byte/Burst).

Da das Senden von 128Byte 12.8us dauert, müßten also innerhalb dieser Zeit
drei Bursts stattfinden. Daraus ergibt sich ein Abstand der Bursts von 4.3us,
oder ein Latency Timer Wert von 4.3us*33 geteilt durch die Anzahl der Bus-
Master, also etwa 143/N (z.B. mit N=5, wenn die Host-Bridge, der IDE-Controller
mit zwei Kanälen, die ISA-Bridge und der Ethernet-Kontroller unter voller
Last laufen).

Also könnte man in einer solchen Situation den Master Latency Timer auf 0x18
(dezimal 24) stellen, und hätte noch etwas Reserve. Die effektive Burst-Länge
wäre etwa 70Byte, so daß die Datenrate noch nicht zu sehr leidet (etwa 70%
des Limits von 133MB/s Bus-Durchsatz). Da die Bursts etwas länger sind als
oben angenommen, könnte der Latency-Timer Wert noch ein bisschen erhöht werden,
so etwa bis auf 0x28 (dezimal 40) schätze ich.

Ansonsten wird durch die Erhöhung des Buffers aber auch automatisch dafür
gesorgt, daß Buffer Underruns nicht so leicht auftreten können. Der Treiber
fängt später an auf dem Ethernet zu senden, die Daten kommen minimal später
an, aber es gibt mehr Reserve und damit mehr Toleranz für PCI-Arbitrations-
Latencies ...

Gruß, STefan

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message
Received on Tue 25 Jul 2000 - 21:07:43 CEST