Hogere limieten voor telenet-klanten

**arlene** · 4 februari 2010, 20:05

Zou dit er ook mee te maken hebben

Onderzoek naar limieten Belgisch internet

**Yorkfield** · 6 februari 2010, 18:35

Ik weet niet hoe het zit met de uploadsnelheden bij Turbonet XL en Fibernet, maar als het zou daadwerkelijk 40/1.25 en resp 100/4 zou zijn kunnen we nog eens goed lachen.

Weet wanneer je iets download, er voor ieder pakketje een ACK moet teruggestuurd worden naar de desbetreffende server. Weet dat bij een 100mb down link er véél ack's moeten teruggestuurd worden via die trage 1,25 UP? Man man man..........

**arlene** · 7 februari 2010, 11:09

Ik weet niet hoe het zit met de uploadsnelheden bij Turbonet XL en Fibernet, maar als het zou daadwerkelijk 40/1.25 en resp 100/4 zou zijn kunnen we nog eens goed lachen.

Weet wanneer je iets download, er voor ieder pakketje een ACK moet teruggestuurd worden naar de desbetreffende server. Weet dat bij een 100mb down link er véél ack's moeten teruggestuurd worden via die trage 1,25 UP? Man man man..........

Leg eens uit aan de gewone forumgebruiker, de meesten willen graag weten wat je bedoeld.

**Yorkfield** · 7 februari 2010, 12:04

Het is zo, als je een bestand download van het internet, dit bestand onderverdeeld is in pakketjes. Die pakketjes zijn nodig voor volgende redenen:

- Als het bestand niet zou onderverdeeld zijn in kleinere pakketjes, dan zou uw bestand 1 groot pakket zijn: Dit pakketje moet bijvoorbeeld van een server van de US komen. Weet dat dit pakketje meerdere routers moet passeren tegen dat het hier in België aankomt. Stel nu eens voor dat er een van dezer routers uitvalt: Dan is je download bij jouw thuis gestopt, dan moet je terug van 0 beginnen te downloaden.

- Hier komt het nut van die kleinere pakketjes te pas. (technisch: wij gebruiken het IP-protocol, meer bepaald TCP). We downloaden terug het grote bestand, op jouw PC komen er nu kleine pakketjes toe, in plaats van dat grote bestand. Wanneer er één van die kleine pakketjes goed is toegekomen zend je PC een ACK-bit terug naar de server: Dit wil zeggen, ik heb het pakketje ontvangen, zend maar het volgende pakket naar mij. Deze ACK-bits moeten over je UPLOAD link. Het voordeel van deze pakketjes zijn legio: wanneer er één verloren gaat, corrupt wordt,.... vraagt je PC gewoon terug een nieuw pakket.

Daarom de test: Wanneer jij terug eens je foto's upload via je gmail, of via telenet webmail naar het internet toe, probeer dan maar eens een groot bestand te downloaden: Je zal zien dat je downloadsnelheid drastisch omlaag gaat. Of nog beter: wanneer je dus volop upload: probeer eens gewoon te SURFEN!! Inderdaad, aan prehistorische snelheden, nu weet je hoe dat komt: Je uplink is al verzadidgd dooor het uploaden van je foto's, en je PC kan niet meer snel genoeg ACK's terugsturen naar de server, waar je naartoe surft.

Heb je bovenstaande probleem niet, proficiat: U hebt een goede router gekocht

Edit: Youtuben lukt wel nog: Dit gebeurt via UDP en is geen reliable protocol: De server zend maar data naar jouw thuis, en je hoeft geen ACK's terug sturen. Maar men kan niet alles via UDP versturen over internet: Een fout pakketje via UDP zal je niet zien in een video, maar stel dat je een binary bestand download van het internet, mag daar geen fout inzitten, daarom TCP: reliable en foutcorrectie.

**arlene** · 7 februari 2010, 12:15

Prima Uitleg Yorkfield.

**Snakey** · 7 februari 2010, 18:10

Jouw pc zal niet voor ieder ontvangen pakketje een ACK terugzenden, de TCP window zal automatisch aangepast worden afhankelijk van de snelheid van jouw verbinding zodat er minder ACKs verzonden moet worden.

Oorspronkelijk geplaatst door Yorkfield

(technisch: wij gebruiken het IP-protocol, meer bepaald TCP).

Wat je bedoelt, is eigenlijk het TCP/IP protocol suite, waarbij TCP & UDP transportlaag-protocollen zijn en IP is het netwerklaagprotocol. TCP doet trouwens aan foutdetectie ipv foutcorrectie, belangrijk verschil, want bij detecteren van de fout moet het pakket opnieuw verstuurd worden.

**Yorkfield** · 7 februari 2010, 18:58

Volgens deze RFC is SACK (wat jij bedoelt den ik) nooit in gebruik genomen. Voor ieder pakket moet er een ACK worden terug gestuurd.

The receiver SHOULD send an ACK for every valid segment that arrives
containing new data, and each of these "duplicate" ACKs SHOULD bear a
SACK option.

http://www.ietf.org/rfc/rfc2018.txt

Correct me if I'm wrong

**Snakey** · 7 februari 2010, 20:35

http://www.ietf.org/rfc/rfc813.txt
http://en.wikipedia.org/wiki/Transmi...l#Flow_control

**Yorkfield** · 7 februari 2010, 21:03

Op de eerste RFC is het volgende terug te vinden:

The acknowledgement mechanism is at the heart of TCP. Very simply, when data arrives at the recipient, the protocol requires that it send back an acknowledgement of this data. The protocol specifies that the bytes of data are sequentially numbered, so that the recipient can
acknowledge data by naming the highest numbered byte of data it has received, which also acknowledges the previous bytes (actually, it identifies the first byte of data which it has not yet received, but this is a small detail). The protocol contains only a general assertion
that data should be acknowledged promptly, but gives no more specific
indication as to how quickly an acknowledgement must be sent, or how much data should be acknowledged in each separate acknowledgement.

Je OS moet die RFC ondersteunen:

http://www.mail-archive.com/lwip-use.../msg06087.html

In praktijk merk je toch zelf de extra overhead die het downloaden van een bestand inneemt, ik heb weliswaar overdreven dat ieder pakket een ack terug nodig heeft, en zal ook wel verschillen per OS en dergelijke, maar een abbonement met een 100/4 profiel vind ik nutteloos.

Maar ik ben off-topic bezig

**Snakey** · 7 februari 2010, 21:30

Hoe hoger de bandbreedte waarop de zender het kan versturen naar de ontvanger, hoe groter de TCP window, en dit is de indicatie hoe snel er een acknowledgement moet gestuurd worden (iedere ack bevat het nummer van het pakket dat het verwacht te ontvangen). Als de ack niet teruggestuurd wordt, dan wordt de window opnieuw verstuurd.
Dit wordt door zowat iedere modern besturingssysteem ondersteund, inclusief XP, waar jij naar verwijst is een bug in een lightweight TCP/IP stack, wat waarschijnlijk nu al verholpen zal zijn.

100/4 is normaal genoeg, toch allesins voor ACKs. Natuurlijk, in situaties waarbij je zelf bestanden moet uploaden/doorsturen, is meer altijd beter. Nuja, het is nog steeds speculeren wat de snelheden zullen zijn van Telenet. Als de down 100Mbps is, dan gok ik meer op een 6Mbps tot 10Mbps voor upload.