enorm trage verbinding win7 <--> linux

[Aesculapius]

Ik gebruik al jaren lang een ubuntu linux server om mijn thuisnetwerk te NATten en als simpele NAS-oplossing met samba. Werkt altijd prima, tot voorkort.

De precieze aanleiding weet ik niet, maar ik vermoed dat het met een distro-upgrade van linux te maken heeft (naar Lucid).

Probleem is dat mijn samba shares enorrrrrrm langzaam zijn geworden. Kopieëren gaat met 300KB/s terwijl voorheen met gemak 30 tot 40 MB/s gehaald werd over het gigabit netwerk. De server heeft twee intel gigabit kaartjes.

Heb het getest vanaf meerdere clients (om die uit te sluiten), en met meerdere protocollen. Maar zowel samba als proftpd zijn te traag voor woorden. Een file-copy op de server zelf van schijf a naar b gaat wel gewoon op volle snelheid, waardoor ik dus vermoed dat er iets in de verbinding scheef zit.

Ik heb gekeken of er extreem veel belasting is met htop, maar alles rustig daar; genoeg mem en de twee cpu's staan uit hun neus te eten. Voor de volledigheid, ook al is daar niets aan veranderd, ook ipTables maar even snel uit gezet maar ook dat levert niks op.

Log files geven me ook niet veel info - syslog, dmesg en samba logs doen alsog hun neus bloedt.

Heeft iemand misschien suggesties waarmee ik achter de oorzaak van dit probleem kan komen?

[Osiris]

Ubuntu server heeft ook GUI? Zo ja, misschien kan Wireshark je op weg helpen om bijv IP of TCP-issues te vinden en zo nee, dan kun je met tcpdump een capture-file aanleggen en die op je client openen in Wireshark

[Aesculapius]

Ubuntu server heeft geen GUI nee, maar gewoon zo bedoel je?

tcpdump -i eth1 -w /tmp/condump

Wat moet ik dan zien?

[ Voor 68% gewijzigd door Aesculapius op 08-09-2010 23:23 . Reden: refraseren ]

[Osiris]

Aesculapius schreef op woensdag 08 september 2010 @ 23:17:
Ubuntu server heeft geen GUI nee, maar gewoon zo bedoel je?

tcpdump -i eth1 -w /tmp/condump

Bijv.

Aesculapius schreef op woensdag 08 september 2010 @ 23:17:
Wat moet ik dan zien?

Iets bijzonders? Niets bijzonders dus? Geen enge pakketjes die wijzen op problemen? Dan weet ik 't ook niet

[Aesculapius]

Tsjah ik kan moeilijk beoordelen wat wel en neit bijzonder is. Er zitten wel een aantal zwart met rode regels in;

[Aesculapius]

Niemand een idee wat er hier fout gaat? Ik kan er geen koek van bakken...

[fonsoy]

Aesculapius schreef op donderdag 09 september 2010 @ 11:23:
Tsjah ik kan moeilijk beoordelen wat wel en neit bijzonder is. Er zitten wel een aantal zwart met rode regels in;

[afbeelding]

Er zit nogal vaak een TCP out of order in. Dit kan van alles betekenen, aangezien dit op het OSI model nogal laag zit. Als er een TCP out of order is, dan wordt deze weggegooid, en dat is wel afbreuk aan de snelheid. Misschien is het ontvangerswindow te klein?

Zijn die zwarte regels gedurende die hele dump aanwezig?

[Aesculapius]

fonsoy schreef op vrijdag 10 september 2010 @ 16:09:
[...]
Zijn die zwarte regels gedurende die hele dump aanwezig?

Ja, die komen eigenlijk het hele stuk terug. Dat ontvangerswindow zou dan met een linux-update veranderd moeten zijn en ik neem aan dat als dat het geval was, er wel wat meer google hits zouden zijn? Maar ik controleer het graag..... als ik weet waar ik dat moet doen ;-)

[Verwijderd]

Er is ook niet toevallig rond dezelfde tijd iets veranderd met de fysieke kabels? Je zou ook nog even op zoek kunnen gaan naar een duplex mismatch. ifconfig zou informatie moeten kunnen geven over de hoeveelheid errors op laag 2.

[Aesculapius]

ifconfig geeft geen enkele error en hij auto-negotiate gewoon lekker op gigabit zoals het hoort. Ook aan de kabels is niets veranderd; alleen op de linux bak is een apt-get upgrade uitgevoerd.

Het blijft een probleem en ik weet nog steeds niet waar ik zoeken moet

edit: bij beter nakijken blijken er inderdaad 230 RX errors te zijn bij de interface aan de LAN kant van de server. Maargoed; daar heb ik nog niet veel aan?

[ Voor 22% gewijzigd door Aesculapius op 13-09-2010 21:08 ]

[Aesculapius]

update;

inmiddels wat extra getest. Alle kabels zijn in orde en zekerheidshalve heb ik met een nieuwe kabel een laptop rechtstreeks aan de server gehangen - dus geen network loops of slechte kabels. Nog steeds - terwijl wel gigabit negotiated - slechts snelheden van 500k, zowel over samba als ftp. Ik heb nog even wat met MTU waardes geprobeerd, maar ook dat aanpassen levert geen results.

Clients sluit ik nu uit (meerdere geprobeerd),
Kabels sluit ik uit (getest met powered link-tester),
switches sluit ik uit (getest met andere gigabit switch),

maar dan.... er zijn dus wat errors in het ifconfig result, maar niet veel - stuk of 200-300. Op verzoek kan ik wel een tcpdump sturen als iemand er verstand van heeft. Er komen daar een groot aantal zwarte regels terug, met vnl.

9033 26.941835 192.168.10.5 192.168.10.1 TCP [TCP Retransmission] [TCP segment of a reassembled PDU]


(192.168.10.1 is de nat-server met het probleem, 192.168.10.5 is mijn client)

ik sta open voor andere suggesties!

[silentsnake]

TCP retransmissions houden dus in dat de pakketjes niet of incorrect zijn aangekomen aan de andere kant, en dus opnieuw verstuurt wordt. Of nog specifieker, hij heeft het ook over een reassembled PDU, wat dus inhoudt dat de gefragmenteerde pakketjes problemen hebben. (de data past niet in één pakketje dus wordt afgebroken a.d.v. MTU size, en aan de andere kant weer reassembled) Kan wijzen op een hardware probleem, maar ook software kan hier vaak een probleem geven. Aangezien je errors hebt lijkt het in eerste instantie op hardware - maar het kan ook zijn dat de andere kant ze niet meer goed kan assembleren. Ik ben ook geen netwerk guru hoor, dus wellicht dat ik hier op het verkeerde spoor zit

Probeer eens met een "ping -f -l <size> " op Windows om te kijken of je errors of drops krijgt vanuit je ping? (je zult geen retransmissions zien aangezien ping ICMP gebruikt en geen TCP). Met de -f zet je de Don't Fragment header. Ben benieuwd of je dan ook errors krijgt, ook met grotere ICMP pakketen.

[Aesculapius]

Weet niet goed waar ik naar moet kijken, maar het ziet er in wireshark wel een stuk vriendelijker uit;

10693 65.493252 192.168.10.1 192.168.10.5 ICMP Echo (ping) reply (id=0x0001, seq(be/le)=46/11776, ttl=64)

Bij een size van 1500 wil hij de ping niet eens uitvoeren...

Ik denk dat ik je opmerking wel enigszins begrijp (denk), maar het vreemde is dat het op meerdere clients plaatsvindt dus ik moet het denk ik echt bij instellingen op de server zoeken - of is dat een verkeerde aanname?

Ik kan wel gewoon met de volle 60MBit van mijn internet abonnement downloaden, maar vervolgens niet met diezelfde snelheid van de server (waar al het internet ook langs komt).

(inet) --> (NAT-/fileserver) --> Client

edit;
met FTP overigens vergelijkbare errors;
23411 369.368397 192.168.10.5 192.168.10.1 TCP [TCP Out-Of-Order] 55356 > bmc-perf-sd [ACK] Seq=3904667 Ack=1 Win=262140 Len=1460

[ Voor 11% gewijzigd door Aesculapius op 14-09-2010 00:25 ]

[Geert de Graaf]

laat maar

[ Voor 92% gewijzigd door Geert de Graaf op 14-09-2010 00:40 . Reden: niet goed gelezen ]

[powerboat]

Ik had bij de het overstappen naar 10.04 ook netwerk problemen.

Bij stonden de nics in een trunk/bond.
De oplossing bij mij was dar de bond anders geconfigureert moest worden.

ik zal morgen effe op het werk door mijn docu kijken.

[Aesculapius]

daar ben ik erg benieuwd naar ljarutten!

Voor de volledigheid mijn /etc/network/interfaces:

# The loopback network interface
auto lo
iface lo inet loopback

# WAN network interface
auto eth0
iface eth0 inet dhcp
post-up iptables-restore < /etc/iptables.up.rules

# LAN network interface
auto eth1
iface eth1 inet static
address 192.168.10.1
netmask 255.255.255.0
network 192.168.10.0

[ Voor 83% gewijzigd door Aesculapius op 14-09-2010 00:50 . Reden: interfaces toegevoegd ]

[osmosis]

heb je de mogelijkheid om de netwerk kaart van je server even te switchen ?
stel dat dat het is. bespaard t je een hoop hoofdpijn en werk

[Aesculapius]

tsjah dat idee had ik ook nog staan als laatste "wat kan ik nog proberen".... zal zo eens zoeken. Maar had ik dan niet veel meer errors bij ifconfig moeten zien?

[osmosis]

ooit eens had ik een server met freebsd, daarbij kreeg ik ook rare TCP / UDP errors en belabberde snelheid.
bleek dat me nic niet helemaal lekker was

kwam ik na een week vol frustratie en WTF momenten achter

[ Voor 21% gewijzigd door osmosis op 14-09-2010 01:03 ]

[Aesculapius]

nou ik heb inmiddels inderdaad ook aardig wat WTFjes gehad haha.... zo onderhand denk je dat je alles wel getest / uitgesloten hebt. Heb net de nic vervangen door een 100mbit kaartje dat ik nog had liggen en die trekt met gemak richting de 10MB/s. dus daar lijkt het probleem inderdaad te liggen.

tenzij...het een configuratie probleem is, want deze nieuwe nic staat nu op eth2 i.p.v. eth1. Ik ga even proberen om hem op eth1 te zetten. Als daarmee het probleem terug komt is het dus alsnog niet de nic, maar een instelling ergens...

Nee dus - maar wel interesting. Door de kaart naar eth1 te zetten heb ik weer transfer rates van 500 / 700k. Fijn, dan is mijn Intel pro/1000GT kaartje toch niet kapot, maar zit een config optie de boel te verzieken...

tijdelijke oplossing dus de boel naar eth2 zetten (in /etc/udev/rules.d/70-persistent-net.rules). Nu de hamvraag; waar begin ik met zoeken naar conflicterende instellingen....

[ Voor 27% gewijzigd door Aesculapius op 14-09-2010 01:30 ]

[Aesculapius]

{ah wat lekker om na zo veel geklooi het ding weer met 100MB/sec te zien pompen :-)}

Laatsgenoemde wijziging werkt dus.... ergens wordt eth1 gemisconfigureerd....

[osmosis]

mooi dat t werkt. vreemd probleem... alsnog

* miss werkt dit... maak een uitdraai van de instellingen op eth2
vervolgens zet je um weer op eth1 , vergelijk de instellingen
daar ergens zou volgens mij t probleem moeten liggen

[ Voor 217% gewijzigd door osmosis op 14-09-2010 12:41 ]

[Aesculapius]

jterpstra schreef op dinsdag 14 september 2010 @ 12:36:
* miss werkt dit... maak een uitdraai van de instellingen op eth2

ehh, heel goed, maar wat voor uitdraai bedoel je? Het enige dat ik verander is de naamstoewijzing van udev aan de netwerk interface - instellingen blijven gelijk (/etc/network/interfaces in ieder geval).

[osmosis]

oke... uhm ja dan weet ik t ook niet had verwacht dat er iets veranderde in interfaces.

[fonsoy]

Aesculapius schreef op dinsdag 14 september 2010 @ 13:13:
[...]


ehh, heel goed, maar wat voor uitdraai bedoel je? Het enige dat ik verander is de naamstoewijzing van udev aan de netwerk interface - instellingen blijven gelijk (/etc/network/interfaces in ieder geval).

Dat is heel vreemd. Echt heel vreemd. Het kan niet anders zijn dan dat er iets mis is met een instelling.
Kan je niet de Intel eth2 toewijzen? Heb je dan ook nog het probleem?

[Aesculapius]

dat heb ik nu gedaan; gewoon udev i.p.v. eth1, het ding eth2 laten noemen en het probleem is weg. Definately een instelling ergens...maarja, waar?