[LINUX] Lage snelheden netwerk, 2.6.x kernel (CentOS)

[Verwijderd]

Ik ben tot de conclusie gekomen dat een aantal machines met SuperMicro P4SCi borden (S478) erg lage snelheden op het netwerk opleveren met CentOS 4.4.

Ten eerste is de bekabeling op orde en wordt er op 1GB CAT6 gebruikt van degelijke kwaliteit. De 100Mbit tests zijn op dezelfde switch met exact dezefde CAT5e kabels.

Ik heb exact hetzelfde getest met SuperMicro P8SCT (S775) borden en hier lijkt alles normaal snel te gaan.

Wat haal ik ?

Met de P4SCi borden op 100Mbit:

3-4MB/s, met autoneg aan, met autoneg uit niet vooruit te branden.

Met de P8SCT borden op 100Mbit:

22-25MB/s met autoneg uit, met autoneg aan rond de 8MB (dacht ik, 22-25 weet ik zeker).

Met P4SCi op 1000Mbit:

19MB/s met autoneg aan en uit, aangezien dit op de switch al uitgeschakeld staat bij default.

Met P8SCT op 1000Mbit:

Nog geen test stats.


De 100Mbit test is met alle machines op dezelfde simpele 100Mbit unmanaged HP switch, de instellingen met ethtool zijn:

ethtool ethX -s speed 100 duplex full autneg off


Wanneer ik op de P4SCi borden op "autoneg off" zet zakt de snelheid in naar 132KB/s en komt nauwelijks vooruit.

Het blijkt dat de P4SCi borden voorzien zijn van Intel 1000/Pro kaarten, de P8SCT's van Broadcom BCM5721 Gigabit Ethernet Controllers.

Na het testen op dezelde HP-switch op een Compaq Machine met Intel 100/Pro nics erin bleek exact hetzelfde te gebeuren qua snelheid als bij de P4SCi's, ook met "autoneg off".

Alle tests op de 2e of eigenlijk eerste NIC (eth0) van alle borden geven dezelfde specificaties als hierboven. Eth0 is per machine op een andere switch aangesloten, er kan dus gezegd worden dat het niet aan de switches ligt.


Ik draai CentOS 4.4 met een 2.6.9-42.0.3.ELsmp kernel wat verder geen problemen geeft.


Het updaten van de BIOS op de P4SCi borden zal weinig nut hebben omdat de Compaq('s) met Intel 100/Pro kaarten hier ook last van heeft.

Het lijkt er dus op dat het puur Intel Nics zijn die lage snelheden opleveren.

De Prioriteit van de managed switches (eth0) staat op 0, zou prima in orde moeten zijn.

Ik heb zaken als autoneg op de switches ook al geprobeerd, maar aangezien ik een dergelijke "cross-test" van verschillende apparatuur heb gedaan/kunnen doen lijkt het me vrij duidelijk dat dit een Nic-probleem is in combinatie met het OS.

[ajvdvegt]

Wellivht zijn er nog specifieke driver opties om e.e.a. te versnellen? En welk protocol gebruik je voor bestandsoverdracht? SMB is niet bijzonder snel.

Ps. er staan drie taalfouten in je sig.....

[Verwijderd]

Ik ben dat vergeten toe te voegen, ik heb het getest met SCP omdat dit het makkelijkste was.

Met rsync hetzelfde euvel.

Driver-opties ? Als iemand hier een idee voor heeft, graag. Dan raadpleeg ik google nog even

[Verwijderd]

Ik kom met driver-opties alleen maar uit op tools als ethtool uit.

Verder lijkt er me weinig mogelijk ? Ik vind het vreemd dat een 100/Pro kaart het ook doet.

[Mishmash]

Wat gebeurt er als je een 3com kaartje in de super micro machines doet om te testen?

[Verwijderd]

Mishmash schreef op zaterdag 30 december 2006 @ 15:15:
Wat gebeurt er als je een 3com kaartje in de super micro machines doet om te testen?

Dat zou ik moeten testen, maar ik heb hier een machine staan met een simpel Intel Desktopbord en een 3com 990SRV kaart, en dat gaat gewoon op normale snelheden. Ik draai hier ook CentOS 4.4 op.

Ik test het direct even vanaf een zelfde systeem qua mobo en een Intel 100/Pro Nic, draaiende Debian Etch.

Het staat me bij dat dit gewoon snel ging.

edit:


Helaas, traag:

Default:

100% 100MB 9.1MB/s 00:11


ethtool -s eth0 speed 100 duplex full autoneg off

41% 42MB 621.6KB/s 01:35

Dit begon bij 125KB/s

Dit was vanad het Debian + Intel systeem naar de CentOS + 3Com

M'n livestream onder Debian klapt er zelfs uit bij autoneg off. Dit test ik trouwens op een 3Com 100Mbit Office Switch

De Intel Nic vindt het trouwens niet prettig wanneer ik deze op de OfficeSwicht op FullDuplex zet, ik kan dan niet eens meer een DHCP adres van de server ontvangen. Op half is alles prima.

[ Voor 35% gewijzigd door Verwijderd op 30-12-2006 15:45 ]

[Verwijderd]

Het blijft een raar probleem want met FTP-en van veel kleine bestanden is de machine wel eens compleet onbereikbaar lijkt het wel, hoewel de Compaq zelfs 50MB bestanden achter elkaar prima kan hebben.

Ik ben aanhet onderzoeken of dit probleem met FTP ook te maken heeft met de Intel 100/Pro in mijn Desktop.

Ik snap het echt niet.

[_JGC_]

Oude 2.6.9 kernel met nieuwe hardware. Grote kans dat er iets is veranderd in latere hardware revisies van die netwerkcontrolers waar je oude 2.6.9 kernel geen raad mee weet. Probeer eens een nieuwe kernel, grote kans dat je dan veel minder netwerkproblemen hebt.

[Verwijderd]

De vraag is of dat handig is met RHEL/CentOS om te upgraden naar een "niet-stock" kernel.

[pistole]

Verwijderd schreef op vrijdag 29 december 2006 @ 23:13:
Ik ben dat vergeten toe te voegen, ik heb het getest met SCP omdat dit het makkelijkste was.

Met rsync hetzelfde euvel.

Driver-opties ? Als iemand hier een idee voor heeft, graag. Dan raadpleeg ik google nog even

check even met modinfo (modinfo e100 in jouw geval maar weet niet zeker, zie lsmod) of je debugging of andere opties aan de module kan meegeven. Misschien kan je daar nog iets mee.

Hoe zit het verder met o.a. interrupt afhandeling? Wat vmstat als je die laat lopen?

[Olaf van der Spek]

Verwijderd schreef op dinsdag 02 januari 2007 @ 14:23:
De vraag is of dat handig is met RHEL/CentOS om te upgraden naar een "niet-stock" kernel.

Kun je niet booten met een recente live CD en dan testen?
En die autoneg problemen zijn ook vaag. Heb je al uitgezocht wat daar precies mis gaat?

[ Voor 14% gewijzigd door Olaf van der Spek op 02-01-2007 19:39 ]

[Verwijderd]

Olaf van der Spek schreef op dinsdag 02 januari 2007 @ 19:38:
[...]

Kun je niet booten met een recente live CD en dan testen?
En die autoneg problemen zijn ook vaag. Heb je al uitgezocht wat daar precies mis gaat?

Er is mij geadvisserd even NetCat te proberen. Het zou namelijk zo kunnen zijn dat ik met SCP puur de I/O van de schijven aan het testen ben.

NetCat kun je wat meer meer zien.

Ik kan even testen met een LiveCD een dezer dagen.

Ik zal het ook nog proberen met een andere driver, de e100pro of e1000pro inplaats van de e100 of e1000. Hoewel deze kaarten hier ook als PRO worden herkend.

[ Voor 13% gewijzigd door Verwijderd op 02-01-2007 20:45 ]

[Verwijderd]

Ik sprak gisteren iemand op IRC die hetzelfde probleem had alleen op een Dell Machine met Intel Nics en CentOS 4.4

Ik heb deze persoon gevraagd om een normale installatie van CentOS te doen, updaten, en dan te testen, aangezien hij dit probleem als VM op een Windows Host met Vmware had.

De vraag is namelijk in zijn geval of de Vm op ~25MB/s is gelimit, dit zou zo moeten zijn.

Toch vreemd dat dit de 2e als is die het opmerkt.

Ik heb nog geen tijd gehad te testen, maar zal dit spoedig doen.

[ Voor 7% gewijzigd door Verwijderd op 03-01-2007 15:05 ]

[TrailBlazer]

het kan inderdaad best een HD probleem zijn of een combi van een rotte chipset driver/netwerkkaart

[Verwijderd]

TrailBlazer schreef op woensdag 03 januari 2007 @ 15:18:
het kan inderdaad best een HD probleem zijn of een combi van een rotte chipset driver/netwerkkaart

Wel vreemd dat het dan op 6 machines hetzelfde is.

[TrailBlazer]

Verwijderd schreef op woensdag 03 januari 2007 @ 15:58:
[...]


Wel vreemd dat het dan op 6 machines hetzelfde is.

ik bedoel een beroerde driver voor die chipset niet zozeer een kapotte chipset. Zin was niet helemaal duidelijk. Ik heb ooit een keer een bios update moeten doen omdat de NIC niet lekker met de North of Southbridge chipset samen kon werken of iets in die richting

[Verwijderd]

TrailBlazer schreef op woensdag 03 januari 2007 @ 16:41:
[...]

ik bedoel een beroerde driver voor die chipset niet zozeer een kapotte chipset. Zin was niet helemaal duidelijk. Ik heb ooit een keer een bios update moeten doen omdat de NIC niet lekker met de North of Southbridge chipset samen kon werken of iets in die richting

Ik vind het zo gek dat dit ook gebeurt op een DL360 en een oudere 6400R waar de bios gewoon niet meer up-to-date kan zijn.

Het baart me wat zorgen eigenlijk. Ik zal de e100pro driver eens proberen.

[Verwijderd]

je geeft aan dat je kernel 2.6.9 gebruikt. zijn er updates? zo ja, kun je een losse box eens proberen en zien of het beter werkt?
zijn de netwerkinstellingen goed? heb je de juiste drivers in de kernel?

[CyBeR]

Verwijderd schreef op vrijdag 29 december 2006 @ 11:33:

Met de P8SCT borden op 100Mbit:

22-25MB/s met autoneg uit, met autoneg aan rond de 8MB (dacht ik, 22-25 weet ik zeker).

Dit lijkt me heel sterk. Ofwel klopt er iets aan je testmethodiek, ofwel niet aan wat hierboven staat. 25MB/sec over 100mbit kan niet.

Netwerkperformance testen kun je beter met iperf doen. Scp limiteert je namelijk omdat 't gebeuren ook nog ge-encrypt moet worden.

[Verwijderd]

Verwijderd schreef op woensdag 03 januari 2007 @ 17:17:
je geeft aan dat je kernel 2.6.9 gebruikt. zijn er updates? zo ja, kun je een losse box eens proberen en zien of het beter werkt?
zijn de netwerkinstellingen goed? heb je de juiste drivers in de kernel?

Ik had het al eerder aangegeven, maar ik zal het nogmaals opsommen:

- CentOS 4.4 met de laatste updates en running op de laatste STOCK kernel.
- Gebruikte driver voor 100Mbit e100 en voor 1000Mbit e1000

De kaarten worden herkend als Pro kaarten met de e100/0 varianten. Redhat heeft enige tijd geleden de originele Intel drivers geinclude dus je gebruikt ook geen Native meer.

Het plan is om de e100pro en de e1000pro te gaan testen omdat dit misschien een betere herkenning heeft.

Alle netwerk-instellingen zijn uitvoerig getest, op een Broadcom haal ik een hogere snelheid met autoneg off trouwens. De rest staat gewoon op full-duplex bij de broadcoms.

CyBeR schreef op woensdag 03 januari 2007 @ 17:26:
[...]


Dit lijkt me heel sterk. Ofwel klopt er iets aan je testmethodiek, ofwel niet aan wat hierboven staat. 25MB/sec over 100mbit kan niet.

Netwerkperformance testen kun je beter met iperf doen. Scp limiteert je namelijk omdat 't gebeuren ook nog ge-encrypt moet worden.

Nee dit klopt inderdaad niet, het zou 100/8 moeten zijn @ max., 12,5 MB/s dus.

[ Voor 19% gewijzigd door Verwijderd op 03-01-2007 17:30 ]