Vreemd linux netwerk probleem

[Verwijderd]

Hey tweakers,

Ik zit met het volgende. Ik heb een server in amsterdam hangen met Fedora Core 2.
De netwerk kaart die er in zat is een 3com 3c905b aangezien me transfer snelheid nogal traag was dacht ik dat de netwerk kaart z'n beste tijd heeft gehad dus heb ik er een nieuwe 3com kaart in gezet ( 3c905cx-txm ).
Echter doet het feit zich voor dat de snelheid niet bepaald naar volwachtingen voldoet. Netwerk kabel is getest en vervangen, tevens geprobeert op een andere switch poort. maar niets had een positieve uitwerking.
Ik heb me al rot gezocht op google en ook nog oplossingen bedacht met mij provider, maar ik ben ten einde raad.

OS: Linux Fedora core 2
Kernel: 2.6.7

mocht iemand enig idee hebben hoor ik dat graag

[Verwijderd]

Waarmee heb je de verbinding getest? kun je die daar in Amsterdam ook laten testen?

Verder zou ik vermoeden dat de line speed 10mbit is of misschien half duplex?


kun je anders je ifconfig ff neerdumpen?

[Verwijderd]

Ik heb mijn verbinding getest door een 10mb.bin van een andere ISP te downloaden wat met ongeveer 20 kb/sec ging.

de verbinding met de switch is 100mbit FullDuplex:
# mii-tool
eth0: 100 Mbit, full duplex, link ok

de ifconfig output:

eth0 Link encap:Ethernet HWaddr 00:50:04:41:62:01
inet addr:82.150.134.173 Bcast:82.150.134.255 Mask:255.255.255.0
inet6 addr: fe80::250:4ff:fe41:6201/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:53711 errors:0 dropped:0 overruns:0 frame:0
TX packets:37944 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:60229179 (57.4 Mb) TX bytes:3370236 (3.2 Mb)
Interrupt:11 Base address:0xc000


elke andere server op die switch kan wel alle snelheid halen dus het zal haast wel aan mijn server liggen. maar ik kan niet vinden wat.

[Verwijderd]

dit is idd erg vreemd! heb je dit thuis allemaal niet getest over lokaal netwerk?

Normaal zou het aan je dma kunnen liggen of de ide / sata controller die je gecompiled hebt in je kernel, maar dit is niet het geval lijkt me, anders zou ie wel wat harder gaan dan 20KB/s heb je ook al een andere isp geprobeerd om daar heen te zenden?

edit:
uitaard ff gekeken wat er op je server stond, kon het niet laten, pagina laat snel ondanks het een dir listing is, ook ff een file gedownload, ging met 230 Kb/s ....

je upload is iig wel snel

[ Voor 24% gewijzigd door Verwijderd op 22-07-2004 10:57 ]

[Verwijderd]

Thuis heb ik 't wel wat file transfers gedaan maar voor zo ver ik kon zien toen zonder problemen.
Heb ook al van meedere IPS zo'n test file gedownload, zelfs van 1tje in het zelfde netwerk en ging eveneens erg traag.
Zou het een probleem van de kernel kunnen zijn?
Aan de IDE controller kan het niet liggen aangezien file transfers op de HD wel snel gaan.

[Verwijderd]

het zou aan je kernel kunnen liggen, ik zie ook ipv6 staan (heb de kernel niet op me servers draaien) Deze heb ik wel eens eerder gedraaid op mijn eigen pc. Kan me alleen niet herinneren dat er ipv6 bij instond, heb je zelf ipv6 aangezet?

zo ja, probeer dit eens uit te zetten?! voor de rest een beetje prutsen zou ik zeggen. Zeiden ze in amsterdam niet dat het erg raar was? als die files maar 20 KB/s gaan..... je upload ligt iig wel hoger.

edit:

Als je thuis het probleem niet had......

daar ging zowel download als upload hoger mag ik aannemen? dan zit er kennelijk iets niet goed in het netwerk.... (of de instellingen)

[ Voor 18% gewijzigd door Verwijderd op 22-07-2004 11:08 ]

[Verwijderd]

Ik kan wel weer even gaan kloten aan me kernel.
ze vonden de transfer wel heeeel erg vreemd aangezien verder iedereen in dat netwerk 10 MB/sec haalt. dus aan het netwerk kan het niet liggen.

[Verwijderd]

ik blijf het een wazig verhaal vinden, maar om ff tot een gekke mogelijkheid te komen... probeer eens knoppix? of kijk of je misschien tijdelijk winblows erop kan installeren om het te checken of het niet aan het netwerk ligt?!

voor de rest durf ik je het ook niet te vertellen, hoop dat prutsen werkt

offtopic:
Altijd als ik er niet uit kom pruts ik wat aan, google een beetje vaak verhelpt dat de problemen wel.

good luck

[Verwijderd]

Tijdelijk windows er op zetten zal helaas niet lukken aangezien het een productie server is
ik heb net het e.e.a. aan me kernel verandert, als dat niet helpt weet ik 't ook niet meer
in elk geval bedankt!

[Verwijderd]

Hey electric, die NIC komt me bekend voor Mijn ouwe bak zeker?

Anyway welke kernel draai je? DMA staat aan voor de hd's? Hoe zit het met cpuload wanneer je aan het kopieren gaat?

Meer info!

[Ghandi]

Verwijderd schreef op 22 juli 2004 @ 13:30:
Hey electric, die NIC komt me bekend voor Mijn ouwe bak zeker?

Anyway welke kernel draai je? DMA staat aan voor de hd's? Hoe zit het met cpuload wanneer je aan het kopieren gaat?

Meer info!

Probeer eens een kompleet ander merk netwerkkaart als alternatief. Bijvoorbeeld een intelkaartje

De desbetreffende 3com, staat die op de supported lijst van je distro?

[Gert]

Een van die andere servers aan de switch heeft dezelfde nic als de jouwe? 3com kan wel eens vreemd reageren bij bepaalde switches, of onbepaalde eigenlijk.

[Verwijderd]

Ghandi schreef op 23 juli 2004 @ 00:29:
[...]


Probeer eens een kompleet ander merk netwerkkaart als alternatief. Bijvoorbeeld een intelkaartje

De desbetreffende 3com, staat die op de supported lijst van je distro?

drivers zitten gewoon in de kernel, is dezelfde als voor de -c variant

[Koffie]

Move PNS > NOS

[Verwijderd]

Verwijderd schreef op 22 juli 2004 @ 11:23:
Tijdelijk windows er op zetten zal helaas niet lukken aangezien het een productie server is
ik heb net het e.e.a. aan me kernel verandert, als dat niet helpt weet ik 't ook niet meer
in elk geval bedankt!

kun je tijdelijk terug naar jouw backup kernel?

[Verwijderd]

Nic in een ander slot geprobeerd?

[Verwijderd]

Hoe heb je die 100mbit-fdx connectie ingesteld? Is dat via auto-negotioation gegaan, of heb je m hard geforceerd op 100mbit-fdx. Als je het via auto-negotiation gedaan is, zou je dan zowel op de switch als op de nick de connectie hard kunnen forceren op 100mbit-fdx?

[Verwijderd]

@MrLeeJohn
V: Nic in een ander slot geprobeerd?
A: JA

@andre_at_home
V: kun je tijdelijk terug naar jouw backup kernel?
A: Dat is ook wel een optie ja

@r3boot
ik heb hem geforceerd op 100 Mbit FDX gezet.

@neographikal
Dit is niet jou oude bak ( dit is me P3tje )
kernel: 2.6.7
DMA staat aan ja
me load is niet bepaald hoog, soms 0.50

@Ghandi
Netwerk kaart word volledig ondersteunt onder linux.

@Gert
Ik heb geen idee wat voor netwerk kaart andere servers hebben maar ik bende enigste met dit probleem.

@iedereen

Ik heb zojuist nog een foutmelding gevonden in me kernel die soms voorkomt:

kernel: eth0: Transmit error, Tx status register 82.
kernel: Probably a duplex mismatch. See Documentation/networking/vortex.txt
kernel: Flags; bus-master 1, dirty 89100(12) current 89100(12)
kernel: Transmit list 00000000 vs. d571f980.
kernel: 0: @d571f200 length 80000042 status 00010042
kernel: 1: @d571f2a0 length 80000042 status 00010042
kernel: 2: @d571f340 length 80000036 status 00010036
kernel: 3: @d571f3e0 length 80000036 status 00010036
kernel: 4: @d571f480 length 8000006a status 0001006a
kernel: 5: @d571f520 length 80000036 status 00010036
kernel: 6: @d571f5c0 length 800000ba status 000100ba
kernel: 7: @d571f660 length 80000036 status 00010036
kernel: 8: @d571f700 length 80000036 status 00010036
kernel: 9: @d571f7a0 length 8000006a status 0001006a
kernel: 10: @d571f840 length 8000009a status 0001009a
kernel: 11: @d571f8e0 length 800005ea status 800105ea
kernel: 12: @d571f980 length 80000042 status 00010042
kernel: 13: @d571fa20 length 80000042 status 00010042
kernel: 14: @d571fac0 length 80000042 status 00010042
kernel: 15: @d571fb60 length 80000042 status 00010042

Maar dat heeft te maken dat iedereen eigenlijk HD draait en ik FD.

[Verwijderd]

Verwijderd schreef op 23 juli 2004 @ 14:38:
[...]
Maar dat heeft te maken dat iedereen eigenlijk HD draait en ik FD.

Force je kaart dan eens in hdx mode, en kijk of het probleem blijft.

[htca]

Ik heb ook problemen gehad met een 3com905. Uiteindelijk heb ik gevonden dat ik kudzu uitmoest zetten om het goed te laten werken. Inmiddels heb ik het kaartje vervangen door een realtek en heb ik geen probs meer.

[0siris]

misschien bepaalde businstellingen in je bios die niet meer op standaard staan (in paranoia mode begin ik altijd met alle enge dingen uit te sluiten )

[Verwijderd]

kernel: eth0: Transmit error, Tx status register 82.
kernel: Probably a duplex mismatch. See Documentation/networking/vortex.txt
kernel: Flags; bus-master 1, dirty 89100(12) current 89100(12)
kernel: Transmit list 00000000 vs. d571f980.
<snip>

Maar dat heeft te maken dat iedereen eigenlijk HD draait en ik FD.

En staat die switch dan niet toevallig keihard ingesteld op HD, of mis ik iets...

[ Voor 4% gewijzigd door Verwijderd op 23-07-2004 16:47 ]

[Verwijderd]

htca schreef op 23 juli 2004 @ 15:30:
Ik heb ook problemen gehad met een 3com905. Uiteindelijk heb ik gevonden dat ik kudzu uitmoest zetten om het goed te laten werken. Inmiddels heb ik het kaartje vervangen door een realtek en heb ik geen probs meer.

Een 3com kaart vervangen door een realtek is natuurlijk wat minder handig (in een server!), neem dan tenminste een ander fatsoenlijk merk.

[blaataaps]

Verwijderd schreef op 23 juli 2004 @ 17:03:
[...]


Een 3com kaart vervangen door een realtek is natuurlijk wat minder handig (in een server!), neem dan tenminste een ander fatsoenlijk merk.

Als de realtek geen ruzie maakt met andere hardware en de 3com wel, lijkt de keus mij niet zo heel moeilijk als je niks anders voorhanden hebt.

[Verwijderd]

Verwijderd schreef op 23 juli 2004 @ 16:47:
[...]


En staat die switch dan niet toevallig keihard ingesteld op HD, of mis ik iets...

Klopt:) maar om te kijken of het een oplossing zou kunnen zijn heb ik het op FD gezet. heb hem nu weer op HD gezet:

# mii-tool
eth0: no autonegotiation, 100baseTx-HD, link ok

[pierre-oord]

Verwijderd schreef op 23 juli 2004 @ 17:03:
[...]


Een 3com kaart vervangen door een realtek is natuurlijk wat minder handig (in een server!), neem dan tenminste een ander fatsoenlijk merk.

Ok, nu mag jij dan als eerste een vergelijking tussen een Realtek kaart en een Intel/3com whatever kaart laten zien.

Ik heb nu een maand een noodoplossing staan van een P4 + 2x Realtek 8139D. (Wordt vervangen door nieuwe router, maar ja, je moet wat he). Ennuh, het draait super stabiel, de pings zijn allemaal erg laag, net zo laag als op andere bakken met een Intel Pro100 kaartje erin. En dan ping ik dus nog van pc's achter de router, dus over 2x realtek kaart.

Ik weet dan een realtek meer CPU matig dingen uitvoert, misschien als je je server een heel hoge load geeft, dat er dan vertraging kan optreden op het netwerk. Verder heb ik het gevoel dat Realtek altijd wordt ondergewaardeerd.


Nu ontopic:
Ik ga het nakijken, maar heb op een test-machine van iemand anders een ping probleem waargenomen: INtern pingen naar die machine levert heel variabele ping's op, 1ms, 16 ms (!), 0.7ms, 2ms, 2.1ms dat soort tijden. Andere bakken geven gewoon 0.1 ms.
Deze machine zal een aardig nieuwe kernel hebben, misschien ook 2.6.7. Misschien een bug? Je kan even in de changelog kijekn.

[Verwijderd]

pierre-oord schreef op 23 juli 2004 @ 22:42:
[...]


Ok, nu mag jij dan als eerste een vergelijking tussen een Realtek kaart en een Intel/3com whatever kaart laten zien.

Ik heb nu een maand een noodoplossing staan van een P4 + 2x Realtek 8139D. (Wordt vervangen door nieuwe router, maar ja, je moet wat he). Ennuh, het draait super stabiel, de pings zijn allemaal erg laag, net zo laag als op andere bakken met een Intel Pro100 kaartje erin. En dan ping ik dus nog van pc's achter de router, dus over 2x realtek kaart.

Ik weet dan een realtek meer CPU matig dingen uitvoert, misschien als je je server een heel hoge load geeft, dat er dan vertraging kan optreden op het netwerk. Verder heb ik het gevoel dat Realtek altijd wordt ondergewaardeerd.


Nu ontopic:
Ik ga het nakijken, maar heb op een test-machine van iemand anders een ping probleem waargenomen: INtern pingen naar die machine levert heel variabele ping's op, 1ms, 16 ms (!), 0.7ms, 2ms, 2.1ms dat soort tijden. Andere bakken geven gewoon 0.1 ms.
Deze machine zal een aardig nieuwe kernel hebben, misschien ook 2.6.7. Misschien een bug? Je kan even in de changelog kijekn.

Mag ik ook de vergekijking geven?!

Geloof vorig jaar of dat jaar ervoor waren we met 8 man naar Campzone, als ik of een maat van mij (allebei een 3c905TX) een game hosten, lage ping, geen stotteringen in de game.

Andere mensen in onze tent hadden allemaal RTL8139 chipsetkaartjes

Bij hun wouden de games nog wel eens stotteren of de ping erg hoog.

De gemiddelde pc was een AMD 1800+ een enkeling iets hoger of lager.

Maar om terug te komen op het bericht,
Heb veel ervaring met die realtek kaartjes, ze zijn handig om ff in een pc te hangen om in je netwerk een backup te maken.

Maar echt doeltreffend verkeer? ik ben geen voorstander van die kaarten.


Nog een geval


heb hier een Pentium II 233 512Kb cache,
Met de realtek kaart en debian + kernel goed gecompiled een datarate vna max 8MB/sec

Als ik er een 3 com erin douw krijg ik snel al de 10MB/sec te pakken

Mjah, kan dus wel begrijpen waarom ik geen realtek meer wil

[pierre-oord]

Die laatste vergelijking, als die klopt, vind ik een aardige indicatie, alhoewel ik hier thuis met een Realtek ook tegen de 10 trek ?

Heb je niet een leuk onderzoekje op internet? (Natuurlijk niet op een 3com website )

[Verwijderd]

Sjonge, zijn we weer een topic aan het kapen Nouja, doe ik wel ff mee.

Over het algemeen zijn realtek kaartjes de consumenten kaartjes en 3com/intel kaarten worden gebruikt voor serieuze/professionele toepassingen. Waarom? Omdat die 3com/intel kaarten cpu's hebben die allerlei zaken mbt error correctie en netwerk optimalisatie verwerken. Het zijn intelligente kaarten, met meer mogelijkheden dan alleen maar pakketjes heen en weer slingeren. Intel kaarten bijvoorbeeld, hebben allerlei high-availability en reduncancy opties ingebouwt (die echter alleen maar werken met de e100 drivers van intel.com). Ook niet ongewoon bij intel kaarten (vooral de server modellen) is dat ze crypto chips onboard hebben, waarmee hardware matig gecrypte ipsec verbindingen mee kunnen worden opgezet, wat op z'n beurt een gigantische performance winst geeft voor ipsec verkeer.

Realtek kaartjes daarintegen (en alle andere consumenten kaartjes van rond de E10,-) hebben daarintegen bijster weinig intelligentie aan boord. Als de kaart "normaal" gebruikt word, functioneert de kaart ongeveer zoals een kaart met intelligentie, maar de problemen gaan komen als de kaart (vele) meerdere connecties moet gaan verwerken, of verschillende workloads. Deze kaarten hebben tevens niet de mogelijkheid om fatsoenlijke error correctie toe te passen, waardoor een groot gedeelte van alle optimalisatie en error correctie toekomt aan de kernel, waar het processor tijd moet delen met alles wat er verder op die bak draait.

Overigens zijn realtek kaarten perfect geschikt als je ff snel een netwerk kaart nodig hebt, maar als je serieus iets met netwerken wilt gaan doen ben je al snel toegewezen op 3com/intel/anderegrotehwboer

offtopic:
Overigens heb ik met EthernetExpress 100mbit server kaartjes een sustained 13.5MB/s gehaald. Zowel met NFS als met FTP. Dit tussen 2 dual p3@1g IBM Eservers, met een cisco catalyst 39xx ertussen.

[ Voor 7% gewijzigd door Verwijderd op 28-07-2004 18:59 ]

[JoetjeF]

Verwijderd schreef op 23 juli 2004 @ 14:38:...

kernel: eth0: Transmit error, Tx status register 82.
kernel: Probably a duplex mismatch. See Documentation/networking/vortex.txt
kernel: Flags; bus-master 1, dirty 89100(12) current 89100(12)
kernel: Transmit list 00000000 vs. d571f980.

Status register 82 betekend het volgende:

The value is in hex, so 0x82 really means both 0x80 (transmit complete) and 0x02 (reclaim error). A reclaim error means that a transmission error (most likely too many collisions) was detected after part of the transmit FIFO was already reclaimed. In other words, the chip had already transmitted the packet and was in the process of flushing it from its memory when it noticed the error.

Zie https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=107389 en http://www.fedorafaq.org/#3c905

Wat een aantal ander mensen dus ook al hadden gezegd. Maar helaas heeft TS nog niet gereageerd.

[nike]

hey zoiets had ik ook. Link

[Verwijderd]

Verwijderd schreef op 28 juli 2004 @ 18:56:

offtopic:
Overigens heb ik met EthernetExpress 100mbit server kaartjes een sustained 13.5MB/s gehaald. Zowel met NFS als met FTP. Dit tussen 2 dual p3@1g IBM Eservers, met een cisco catalyst 39xx ertussen.

100/8 maakt bij mij 12,5 en daar moet de overhead nog vanaf. 11,73 is me max wat ik sustained over de ams-ix heb kunnen blazen vanaf de xs4all fileserver naar netholding toe. 13,5 lijkt me eerlijk gezegd onmogelijk (of had je compressie aanstaan met gegevens die zich daarvoor leenden ofzo? ). Dit was overigens met zo'n zelfde 3com 905-B kaart als electric nu heeft

Overigens heb ik zelf slechte ervaringen met realtek op een drukke gameserver, ik heb het voor nood ook even gedraaid maar de load ging wel wat omhoog. Af en toe een lagspike, het viel allemaal wel mee, maar me 3com en intel kaart functioneerden met aanzienlijk minder problemen.

Electric, heb je die nic ook al in een ander pci-slot gestoken toevallig?

[ Voor 23% gewijzigd door Verwijderd op 29-07-2004 10:14 ]

[Bas!]

Electric, heb je al eens gecrosslinked naar een nic? Heb je al een ander merk switch geprobeerd?
Ik heb slechte ervaringen met allerlei 3com waar en compatibiliteit zelfs met 3com waar onderling.
Alleen met de superstacks die ik beheer heb ik nog weinig compatibiliteits problemen. (wel crashes maar dat heeft hier weinig mee van doen). Office connects zijn een hell, koop ik inmiddels liever een sweex voor. Netwerkkaarten heb ik ervaring met 905's (b,c) en 509's, beiden hebben hun eigenaardigheden wat compatibiliteit met andere hardware betreft.

PS zou je een andere nic willen kan ik je een amd of intel (geen dec/tulip/24xxxx) van harte aanbevelen, nooit problemen mee, zei hij die in de linuxbak waarop hij dit intikt een 905b heeft zitten

[ Voor 20% gewijzigd door Bas! op 29-07-2004 14:01 ]