[Gentoo] RX Overruns

[Sluuut]

Hi mede-tweakers, ik heb een probleempje met een linux server. Wij (ik + vriend van me die behoorlijk wat meer van linux afweet) zijn er al een paar weken mee bezig maar kunnen er niet achter komen wat het nou is.

Specs:
XP 2400+ / 1gb ram
3x 3c905C-TX/TX-M
Promise Technology Ultra133TX2 pci card met 4x hdds in raid0.

Het probleem is dat er constant 1 van de 3 nics TX overruns krijgt en dan niet meer data kan verwerken. elk nieuw pakketje wat je erheen stuurt word als TX overrun erbij getelt.
Enige oplossing is dan het pid van de eth killen en restarten.

De ene keer gebeurd dit na een dag of 2, de andere keer na 2 uur. Of er veel of geen data overheen word gestuurd maakt niks uit.

code:

eth0      Link encap:Ethernet  HWaddr 00:0A:5E:99:99:99
          inet addr:123.123.123.1  Bcast:123.123.123.123  Mask:255.255.254.0
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1708925 errors:0 dropped:0 overruns:1 frame:0
          TX packets:893008 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:936930331 (893.5 Mb)  TX bytes:984265574 (938.6 Mb)
          Interrupt:4

eth1      Link encap:Ethernet  HWaddr 00:0A:5E:99:99:99
          inet addr:123.123.123.2  Bcast:123.123.123.123  Mask:255.255.254.0
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4024572 errors:0 dropped:0 overruns:410 frame:0
          TX packets:3035881 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3743860819 (3570.4 Mb)  TX bytes:3341367168 (3186.5 Mb)
          Interrupt:10 Base address:0x2000

eth2      Link encap:Ethernet  HWaddr 00:0A:5E:99:99:99
          inet addr:123.123.123.3  Bcast:123.123.123.123  Mask:255.255.254.0
          UP BROADCAST NOTRAILERS RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3999900 errors:0 dropped:0 overruns:26307 frame:0
          TX packets:3099537 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:3576199827 (3410.5 Mb)  TX bytes:3343934965 (3189.0 Mb)
          Interrupt:12 Base address:0x4000

Zoals je ziet heeft eth2 nogal wat overruns. Veel meer dan normaal iig.

Nou heb ik een paar vragen:

- Kan dit komen door een kapotte switch/kabel? Lijkt me dat er dan ook RX overruns moeten komen? Zou ook teveel toeval zijn omdat het random bij elke lijn gebeurd?

- Kan het door een IRQ conflict komen? Alle 3 de kaartjes hebben aparte IRQ's en voor zover ik het kan vinden heeft geen ander device hetzelfde IRQ als een 3com kaartje.

- Zou het hardware of softwarematig kunnen zijn, wat is het meest logische?

Dan nog een los vraagje:
Klopt het dat een 66MHz PCI bus 133 MB/s kan verwerken maximaal?
Als 3 NICS dan 36 mb/s doen, en de HDDs ook nog 36MB/s, dan zou dat toch geen bottleneck moeten kunnen zijn?

Wat ik op internet kon vinden over het TX probleem was dat het aan meerdere dingen kon liggen, CPU is sowieso te langzaam want die is constant op 100% bezig, maar dat zou dit probleem niet moeten veroorzaken. Is het trouwens ook normaal dat eth0 geen base adress heeft
Elke ander hulp is zeer welkom!

[_root]

Er ook iets anders niet goed..

Alle interfaces hebben een MAC van 00:0A:5E:99:99:99, en gaat zeker voor een hoop problemen zorgen.

Eerst dit oplossen en dan verder gaan kijken

Edit:
Ik zie ook dat alle kaarten in hetzelfde de netwerk zitten, wat wil je met deze configuratie ??

[ Voor 27% gewijzigd door _root op 24-04-2006 19:41 ]

[Sluuut]

Hehe lol root, ik heb de MAC adressen & IP adresssen & Subnets aangepast zodat we niet ineens hack-attacks krijgen

Deze adressen zijn dus puur fictief, in het echt hebben ze allemaal een ander IP adres/Mac adress.

[Skinkie]

Sluuut schreef op maandag 24 april 2006 @ 20:07:
Hehe lol root, ik heb de MAC adressen & IP adresssen & Subnets aangepast zodat we niet ineens hack-attacks krijgen

Deze adressen zijn dus puur fictief, in het echt hebben ze allemaal een ander IP adres/Mac adress.

Ik was al bang dat je niets van subnets afwist Maar goed post eens je /proc/interrupts

[deepbass909]

Je router en kabels zijn makkelijk te elimineren.
1. Prik de kaarten eens in andere poorten (schuif ze allemaal 1 op of zo). Eerst op je switch, blijft eth2 problemen geven, weet je dat het de switch niet is, immers de kaart zit met dezelfde kabel op een poort die met een andere kaart geen problemen gaf.
2. Draai het doorschuiven weer om,maar nu door de kabels op je server in tegenover gestelde richting te verschuiven. Je eth2 komt dus weer terug op z'n oude poort, maar nu met de kabel van eth1 of eth0. Je weet dat de kabel van eth0 en eth1 goed zijn, aangezien deze geen problemen gaven. Als bij punt 1 het probleem bij eth2 bleef, weet je ook dat de poorten op je switch goed zijn. Schuift nu het probleem met de kabel mee, dan is de kabel defect, blijft het hij eth2, dan zit het probleem in je kaart of installatie.
3. Blijft het probleem bij eth2 zitten, verander dan eens de positie van de kaarten in de pc. Hierbij moet je wel in de gaten houden dat waarschijnlijk de eth identificatie kan veranderen. Het is belangrijk om de kaart te identificeren aan de hand van z'n mac-adres. Blijft je probleem bij dezelfde kaart zitten, is het heel aannemelijk dat de kaart defect is of een misconfiguratie in z'n eeprom heeft.

Nu kan het dus zijn dat ook de identificaties veranderen, en eigenlijk wil je dat ook. Blijft eth2 problemen geven, terwijl het nu een andere kaart is, kunnen er 2 situties zijn:
1. eth2 is de kaart in een bepaald pci slot (identificatie blijft gekoppeld aan een pci-slot) en geeft nog steeds problemen, kan het je moederbord zijn. => gebruik een ander pci-slot voor de 3de kaart (eventueel omruilen met de SATA controller)
2. eth2 zit in een ander pci slot en is een andere kaart, dan zit het probleem heel waarschijnlijk in de installatie, alle hardware factoren voor eth2 zijn namelijk anders, en in de andere situaties werkte dit wel.

Het laatste stukje testen is het lastigst, omdat je te maken hebt met een aantal automatische processen die je niet zo goed kan beïnvloeden.
Kom je er echt niet uit, test dan in iedergeval de 3 kaarten eens los van elkaar. Steeds in hetzelfde pci-slot en verzeker jezelf ervan dat je kaarten in iedergeval goed werken.

Wat betreft je hardware limieten, een te lichte proc kan eigenlijk nooit dit soort fouten veroorzaken. Ik heb vaak genoeg 100mbit kaarten in een machine gehad waarvan de io-bus het niet aan kon. Het effect is dat je gewoon minder data doorvoer krijgt.
Overigens vraag ik me af wat je er toch op doet, en wanneer die cpu op 100% staat. Je 3com's zouden dat toch eigenlijk niet mogen veroorzaken, het zijn niet voor niets managed NIC's (daar staat namelijk de M voor).
Het ontbreken van een Base of IO-adres voor eth0 is inderdaad wat raar, maar aan de andere kant, deze kaart levert geen problemen. Ik ben met de nieuwe hardware wel meer interessante dingen tegen gekomen (IRQ's hoger dan 16, wat volledig buiten de i386 specificatie valt)

Overigens moet je niet vergeten dat je per kaart ook een zekere overhead hebt op de pci bus. Je zult met 4 kaarten 133MB/s effectief kunnen halen. Ik denk dat je al blij mag zijn met 100MB/s.

edit:
Ik realiseer me net ineens, dat mijn 3c905 ruzie had met m'n live als ze in bepaalde sloten zaten. Beide wouden bus-master worden. Positie omruilen deed wonderen en sindsdien werkt het goed. Wellicht ligt de kaart in het slot van eth2 in gevecht met de SATA controller.
Ik zou dat als eerste testen, nadat je de switch en kabels hebt geëlimineerd.

[ Voor 8% gewijzigd door deepbass909 op 25-04-2006 05:15 ]

[Verwijderd]

Thanx voor je enorm uitgebreide uitleg, maar het is dus niet alleen eth2 die dit doet, random doet elke kaart het zo nu en dan...

Overigens vraag ik me af wat je er toch op doet, en wanneer die cpu op 100% staat. Je 3com's zouden dat toch eigenlijk niet mogen veroorzaken, het zijn niet voor niets managed NIC's (daar staat namelijk de M voor).

Er zijn dan een stuk of 15 mensen tegelijkertijd aan het schrijven en lezen. Dit gaat gewoon met de maximale speed die mogelijk is in deze machine...
Elke kaart vreet ongeveer 33%, vandaar dat ik op de 100 uitkom..

Ik zie dat ik heb gereageerd onder een account van een collega.. ik ben dus Sluuut

[ Voor 9% gewijzigd door Verwijderd op 25-04-2006 15:34 ]

[deepbass909]

je kaarten werken parallel? Want het valt me op dat eth0 (die zonder base-io) wel weinig data verwerkt in verhouding tot de andere 2.
Als het trouwens steeds veranderd, blijven IRQ's en IO's wel gelijk? Zo niet, dan zal ik het toch in je software gaan zoeken.

[Parasietje]

eth0 en eth1 hebben ook overruns. Kan het misschien dat je CPU het zo druk heeft met netwerkverkeer afhandelen, dat hij half stikt? Wie weet handelt de kernel netwerkverkeer af op volgorde (eerst eth0, dan eth1, dan eth2). Dat zou verklaren waarom vooral eth2 dichtslibt.

Probeer eens een simpele stress-test op een specifiek IP. Kijk of je nog overruns krijgt. Kijk of je het probleem op willekeurige tijdstippen hebt, of enkel op zware load.

[deepbass909]

Mijn ervaring is eigenlijk dat een hoge netwerk load, waarbij de cpu het niet meer bij kan houden, zelden tot overruns leidt... Zowel m'n huidige server als m'n oude server waren wat processorkracht betreft te zwak om 100mbit te kunnen verwerken. Ze hadden/hebben echter wel een 100mbit kaart, op een 100mbit netwerk, en mijn laptop en pc kunnen wel 100mbit aanbieden. Kopieer acties gingen uiteindelijk met de snelheid van de traagste schakel, zonder buffer fouten.
Het TCP/IP protocol houdt namelijk rekening met dit soort situaties, door maar een beperkt aantal pakketten te sturen, en pas opnieuw te sturen als er bevestiging van ontvangst is ontvangen.
Ik weet natuurlijk niet of de TS ook UDP diensten op z'n server aanbied, deze mist namelijk de ontvangst controle en kan dus wel verslikken in een overrun.

[Sluuut]

Nee, het gaat alleen om TCP/IP diensten, geen UDP.

Ik moet er wel bij zeggen dat er TCP/IP "finetuning" is geweest... dat zou het dus best wel kunnen zijn?
Ik weet helaas niet precies wat voor soort finetuning het is. Maar het lijkt me ook wel logisch dat er bijvoorbeeld voor is gekozen om bepaalde pakketen niet te checken ofzo en dat ze dan te snel binnenkomen om te kunnen verwerken wat dan weer overruns veroorzaakt.

Maargoed we zijn er nog naar aan t kijken
Thx voor de replies.

[Sluuut]

We hebben inmiddels FreeBSD geprobeerd maar helaas kregen we daar multilink niet mee aan de praat, dus dat was geen optie.

Toen maar weer overgestapt op een schone Gentoo install zonder tweaks.. alles basic ingesteld. Helaas kwam het probleem de 2e dag al terug, 1 van de nics kreeg overruns...

Zou dit ook nog een CPU issue kunnen zijn? Stel ik gooi er een amd 64 3500+ in, zou het dan nog steeds gebeuren?

[Superboer12]

Probeer de bonding driver van linux eens.
Ik had eerder twee NICs parallel staan en toen kreeg ik ook veel overruns op eth1.
Na m'n server upgrade heb ik 3 NICs met bonding mode 4 ('IEEE 802.3ad Dynamic link aggregation') gezet. Als er vol gepompt (+/- 270mbps) wordt komt de CPU-load niet hoger dan 8% van de quad Xeon 550.

[Sluuut]

Het is vrijwel zeker de firewall geweest

Na deze als test uit te hebben gezet werkt alles al 4 dagen vlekkenloos.. dus misschien dat de firewall toch het e.e.a. tegenhield wat niet helemaal de bedoeling was. Of dat er een bepaald limiet aan zat.

Hopelijk blijft het nu goed werken

Eigelijk had ik nog 1 vraagje, als we een nieuw moederbord gaan kopen met Gbit onboard en 2 3Com nics overplaatsen.. dan moet het als het goed is sowieso al sneller gaan lopen, omdat tegenwoordig alle Gbit onboards via de PCI Express baan lopen ipv de PCI baan? Dus loopt er minder over de PCI waardoor er uiteindelijk betere snelheden moeten kunnen worden gehaald..?