Linux 2.4.x Netwerkprobleem

[TheGhostInc]

Korte samenvatting van het probleem:
Zodra er een upload komt van 16KB/s (max van @Home) naar @Home begint er een heleboel gezeur:
Ping's komen niet meer door, download's stallen helemaal en nog meer van die problemen.

Dit probleem doet zich voor met verschillende netwerkkaarten en verschillende setups,
Ik draai nu
Debian 2.2 met alles unstable en 2.4.4 kernel,
een vriend draait slackware met 2.4.14 kernel.
(allebei iptables)

Zijn er meer mensen die dit probleem tegen komen, of heeft iemand het probleem gehad.

* TheGhostInc post meer info zodra dat nodig is, ik weet dat dit niet veel info is, maar een complete specificatie is imho niet nodig, aangezien het niet configuratie gebonden is.
(teveel verschillen tussen mijn systeem en het andere systeem)

[Verwijderd]

Tja dit is heel normaal bij kabelinternet.
Zodra je maximale upload gebruikt wordt, valt zowat de complete download weg.

Ligt niet aan linux of je NIC, ligt aan de kabel

Enige oplossing is om traffic te gaan shapen

[TheGhostInc]

Waarom heeft het dan jaren goed gewerkt?
Tis echt sinds er een 2.4 kernel draait, daarvoor was er niks aan de hand.
En is trouwens wel iets heel vaags, wat is er dan een verband tussen upload en download.
Een kabelmodem is imho gewoon full duplex.

[Verwijderd]

ik heb dit probleem ook met 2.2.x, is al heel lang zo bij @home

[Verwijderd]

Je upload wordt volledig gebruikt voor het versturen van data. Downloaden gaat dan in ieder geval maximaal met de snelheid van je totale uploadsnelheid.

De verbinding kan op dat moment gewoon niet snel genoeg de packets verwerkt krijgen. Vandaar ook die ping en stall problemen van je.
Dit is inherent aan kabelinternet en adsl.

Heb je niet nog een 2.2.X kernel liggen om te testen? Het moet echt niks uitmaken als het goed is.

[Verwijderd]

Idd algemeen bekend van kabel.

Dat wordt shapen, gelukkig is dat goed te doen met 2.4.x + netfilter + iproute2/tc

Dat je dit voor het eerst krijgt kan ook aan @home zijde liggen. Misschien hebben ze daar iets veranderd?

Doe eens een nslookup voor je IP, als je dan als domeinachtervoegsel nodemove.home.com krijgt dan zijn ze met jouw verbinding bezig.

[Verwijderd]

Zou dit iets te maken kunnen hebben met:
[topic=332167/1/25] ?

[TumbleCow]

Ik heb ook last van dit probleem, en het is echt gekomen op DE DAG dat ik 2.4 installeerde..

zodra ik iets upload gaan alle pings naar buiten richting de 400, en wordt de ploss rond de 10%.

Hiervoor kon ik altijd prima dingen uploaden e.d. zonder dat er iets mis ging.. Nu krijg ik serieus VEEL webpaginatimeouts zodra ik audiogalaxy aan zet..

[odysseus]

Ik blijf er ook bij dat het meest logische zou zijn dat het probleem gewoon bij @home (of eigenlijk bij kabelinternet in het algemeen) ligt, maar aangezien er toch iets vreemds lijkt te zijn:
treedt het probleem ook op als je 2.4 + ipchains gebruikt? Op die manier zou je kunnen zien of het misschien aan iptables ligt.

[kieskes]

heb ik ook bij mijn kabelverbinding, zodra ik iets upload slibt m'n verbinding dicht, is volgens mij normaal (logisch?)

[TheGhostInc]

Razor, anders binnenkort even een test site opzetten, FF wat machines aan elkaar hangen, kunnen we een keer lekker testen.
Your place or mine?
(heb nog een P75 16MB die wel te charteren is)

[Verwijderd]

Mijn gangkast draait ook 2.4 (2.4.5) en kent dit probleem niet, althans niet in de mate waarin jij het omschrijft. 1 download zal het zooitje niet dichtslibben, pas als er echt veel mensen tegelijk beginnen kan dit voorkomen, maar dat is zoals gezegd normaal.

[TheGhostInc]

Toch blijf ik het raar vinden, dus als ik het goed begrijp:

Zodra ik mijn upload dichttrek ben ik mijn download kwijt?


Komt dit door de retour zending van pakketjes niet doorkomen. (dus ontvangstbevestigingpakketjes)of heeft het een andere oorzaak.

[Verwijderd]

Volgens de @home specs moet dat makkelijk kunnen met een upload van 16 Kb/sec. Maar je kunt pech hebben en in een buurt zitten waar veel mensen internet via de kabel hebben. Ik heb met kernel 2.4.x de volgende nics gebruikt zonder enig probleem met een dergelijke upload:
3c900B
3c590nogwat
rtl8029as (ne2k-pci)
pcnet32 (amd pcnet32)
Denk dus dat het je kabelverbinding is (ik roep altijd in de buurt dat kabelinternet traag en onbetrouwbaar is )

[Francois]

Probleem heeft IMO niks te maken met OS/NIC/etc.

Als je aan het downloaden bent wordt elk TCP (Transmission Control Protocol) pakket dat ontvangen wordt beantwoord met een TCP ACK/NACK. Moet wel, TCP is tenslotte een protocol waarbij gegarandeerd correcte data transfer wordt gedaan. Dit in tegenstelling tot UDP.

Dus indien je upload pijp voor 100% benut wordt kan het even duren voordat een TCP ACK/NACK verstuurd kan worden en de download verder kan lopen. (loopt wel gedeeltelijk parallel, maar niet zo dat alle ACKS verstuurd kunnen worden nadat je die ISO binnen hebt )

Met als gevolg dat je download stagneert. Komt in de praktijk idd uit op ongeveer dezelfde snelheid als je upload (128kbit/s met @home)

En ploss'es, trage pings etc. etc. horen daar allemaal bij.

als je je upload beperkt tot 10-12 kbyte/s heb je nergens last van

Ik heb met linux & winXP precies hetzelfde "probleem". Maarja, het is geen probleem, hoort gewoon zo.

Enige oplossing is dat @home de upload pijp open zet. Planning daarvoor ligt in het jaar 2156 d8 ik

En het is ook niet inherent aan kabel/adsl technisch kan het namelijk wel.

[TumbleCow]

srry voor de *kick*, maar ik kan nu een iets duidelijkere probleemomschrijving geven.

Het probleem is dus dat de downloads *zwaar* onder de maat zijn. (20kb/sec op www.speedtest.nl, terwijl een vriend in dezelfde regio hier zo 300kb haalt)

de pings zijn normaalgesproken wel goed, die schieten alleen ENORM omhoog op het moment dat de upload gebruikt wordt, bij een gelimite upload van 10 KB/sec gaan de pings al rap richting de 400. (max upload is 16KB/sec).

Dit alles gebeurt op een Slackware 8 box, met een 2.4.x kernel (2.4.5 had het, 2.4.13 ook)
Het is een AMD k6-2 450 met 128meg intern, maar de hardware lijkt er niet toe te doen.

verder draait er dus een iptables-nat-firewall op. De problemen doen zich zowel voor 'achter' de firewall, als op de machine zelf.

de nat wordt geconfigureerd met de volgende commando's:

code:

# applies IPTABLES routing
/sbin/modprobe ip_tables
/sbin/modprobe iptable_nat
/sbin/modprobe iptable_filter
/sbin/modprobe ipt_MASQUERADE
/sbin/modprobe ip_nat_ftp
/sbin/modprobe ip_conntrack_ftp

/usr/sbin/iptables -t nat -F
/usr/sbin/iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

[Verwijderd]

Heb je veel last van errors/collisions ? Te zien met ifconfig.

[Verwijderd]

Ik heb ook @ home en geen probleem met Kernel 2.4.8
ikkna gewoon uploaden en downloaden tegelijk.

uploaden van 16kb/s tot 20 kb/s.

en downloaden tussen 200kb/s en 540kb/s

wel heb ik een soortgelijke probleem gezien bij mijn zwager.
deze heeft Kabel van UPC. en als hij ging uploaden dan viel zijn hele verbinding in elkaar.
Na meerder malen met UPC gebeld te hebben zijn ze eindelijk zijn kabel komen meten, bleek dat ergens een versterker verrot was, waardoor de signaal te zwak was geworden....

als ik jullie was zou ik gewoon @home bellen. of ff met een Win p.c. proberen, kijken of ie nog steeds met upload de verbinding trager maakt.

Suc6.

[TumbleCow]

Errors / collisions valt heel erg mee..

op de 3354565316 pakketjes slechts 2 errors en 34 collisions, dus dat is het probleem niet.

verder denk ik dat ik er idd maar eens een andere pc aanhang, het was wel redelijk precies op het moment dat ik overstapte naar kernel 2.4, maar je zult natuurlijk altijd zien dat @home PRECIES op dat moment ergens iets omplugt.

[TumbleCow]

ik heb het eens op een andere pc geprobeert, Daardoor is mijn ip verandert (naar non-nodemove), en de downloads zijn opeens weer goed.

de Uploads daarentegen zijn nogsteeds enigsinds vreemd, als de upstream vol zit, gaan alle pings richting de 500, of soms zelf richting 1500!

nu heb ik de netwerkkaart die de verbinding naar internet verzorgt in mijn linux-bak ook maar eens vervangen.
die krijgt daardoor WEER een ander ip, en de download is vervolgens ook weer gefixed.

het lijkt dus idd niet aan de 2.4.x kernel te liggen. Sorry dat ik er aan getwijfeld heb