---

Hej!

Jeg har langt om længe fået aktiveret min nye ADSL2 forbindelse hos Tele2. Det
er en 20Mbps/512kbit forbindelse, som lige pt. kører ca. 8MBps downstream,
hvilket jo er en del fra det ønskede. Iflg. Tele2 support er jeg ca. 700m fra
centralen, og de påstår, at jeg vil få gavn af et dæmpeled fordi modemmet
åbenbart overstyres pga. den korte afstand.

Jeg har et Billion Bipac 5102SM ADSL2 modem til forbindelsen.

Kan jeg selv lavet noget diagnostik (signalniveau m.m.) på forbindelsen?

Der skulle iflg. Billions hjemmeside være noget Windows software til modemmet,
men det kan jeg sgutte finde på deres hjemmeside

Mon der er noget håb om at få min forbindelse til at udnytte de fulde 20MBps?

--
Mvh, Kim Voss Schrader

---

> Jeg har langt om længe fået aktiveret min nye ADSL2 forbindelse hos Tele2.
> Det er en 20Mbps/512kbit forbindelse, som lige pt. kører ca. 8MBps
> downstream, hvilket jo er en del fra det ønskede. Iflg. Tele2 support er
> jeg ca. 700m fra
[CUT]
> Mon der er noget håb om at få min forbindelse til at udnytte de fulde
> 20MBps?

Nej, aldrig.. Jeg er dybt imponeret over, at du kan køre 8Mbit ned. Når du
downloader antager jeg, at du downloader med TCP. TCP bruger kontrolpakker,
så hver gang der sendes en pakke med data, så sendes der en kontrolpakke
tilbage til afsenderen om, at pakken blev modtaget. Dette kræver tilgængelig
upload båndbredde og en god tommelfinger regel er, at man bør have mindst
10% upload hastighed i forhold til sin download - du har 2,5%.
Så mit bud er, at dit upload udnyttes 100% til at sende kontrolpakker og
derfor kan den ikke nå at downloade mere.

Få noget mere i upload.

PS - det er meget almindeligt at udbydere tilbyder urealistiske hastigheder
og efter min personlige overbevisning er det rent svindel, at de tillader
sådanne hastigheder, når man reelt ikke kan udnytte det til almindeligt
brug. Det skal dog siges, at downloader du almindeligt "dum" UDP, så kan du
sagtens udnytte dine 20Mbit, men der er bare ikke ret meget der bruger det -
f.eks. IP telefoni gør samt diverse radio- og TV-stationer sender typisk i
UDP.

---

> Nej, aldrig.. Jeg er dybt imponeret over, at du kan køre 8Mbit ned. Når du
> downloader antager jeg, at du downloader med TCP. TCP bruger kontrolpakker,
> så hver gang der sendes en pakke med data, så sendes der en kontrolpakke
> tilbage til afsenderen om, at pakken blev modtaget. Dette kræver tilgængelig
> upload båndbredde og en god tommelfinger regel er, at man bør have mindst
> 10% upload hastighed i forhold til sin download - du har 2,5%.
> Så mit bud er, at dit upload udnyttes 100% til at sende kontrolpakker og
> derfor kan den ikke nå at downloade mere.
>
> Få noget mere i upload.

Jeg kunne sagtens udnytte 20 Mbit på min Fullrate forbindelse med 1 Mbit
i upload.

Nu er der desværre sket noget med kobberet som gør, at jeg ikke kan køre
mere end 10 Mbit / 1 Mbit.


--
Mvh. Jesper

---

On Fri, 18 May 2007 10:32:32 +0200, "News" <news1234@REMOVE.gmail.com>
wrote:

> Nej, aldrig.. Jeg er dybt imponeret over, at du kan køre 8Mbit ned. Når du
> downloader antager jeg, at du downloader med TCP. TCP bruger kontrolpakker,
> så hver gang der sendes en pakke med data, så sendes der en kontrolpakke
> tilbage til afsenderen om, at pakken blev modtaget. Dette kræver tilgængelig
> upload båndbredde og en god tommelfinger regel er, at man bør have mindst
> 10% upload hastighed i forhold til sin download - du har 2,5%.

Man sender ikke en ACK for hver eneste pakke.

Hvis forbindelsen er stabil og vinduesstørrelsen høj, er der ikke
noget i vejen for at fylde en 20 Mbps forbindelse med 512 Kbps i
upstream.

-A
--
Hvis du bruger et anti-spam program, der spammer os andre i hvert
eneste indlæg, ser jeg ikke dine indlæg. Jeg filtrerer dem bort.

---

>> Nej, aldrig.. Jeg er dybt imponeret over, at du kan køre 8Mbit ned. Når
>> du
>> downloader antager jeg, at du downloader med TCP. TCP bruger
>> kontrolpakker,
>> så hver gang der sendes en pakke med data, så sendes der en kontrolpakke
>> tilbage til afsenderen om, at pakken blev modtaget. Dette kræver
>> tilgængelig
>> upload båndbredde og en god tommelfinger regel er, at man bør have mindst
>> 10% upload hastighed i forhold til sin download - du har 2,5%.
>
> Man sender ikke en ACK for hver eneste pakke.

Jo, det gør man:

TCP checks to make sure that no packets are lost by giving each packet a
sequence number, which is also used to make sure that the data is delivered
to the entity at the other end in the correct order. The TCP module at the
far end sends back an acknowledgement for packets which have been
successfully received; a timer at the sending TCP will cause a timeout if an
acknowledgement is not received within a reasonable round-trip time (or
RTT), and the (presumably lost) data will then be re-transmitted.

http://en.wikipedia.org/wiki/Transmission_Control_Protocol

---

2007-05-18 KV wrote
>>> Nej, aldrig.. Jeg er dybt imponeret over, at du kan køre 8Mbit ned. Når
>>> du
>>> downloader antager jeg, at du downloader med TCP. TCP bruger
>>> kontrolpakker,
>>> så hver gang der sendes en pakke med data, så sendes der en kontrolpakke
>>> tilbage til afsenderen om, at pakken blev modtaget. Dette kræver
>>> tilgængelig
>>> upload båndbredde og en god tommelfinger regel er, at man bør have mindst
>>> 10% upload hastighed i forhold til sin download - du har 2,5%.
>>
>> Man sender ikke en ACK for hver eneste pakke.
>
> Jo, det gør man:
>
> TCP checks to make sure that no packets are lost by giving each packet a
> sequence number, which is also used to make sure that the data is delivered
> to the entity at the other end in the correct order. The TCP module at the
> far end sends back an acknowledgement for packets which have been
> successfully received; a timer at the sending TCP will cause a timeout if an
> acknowledgement is not received within a reasonable round-trip time (or
> RTT), and the (presumably lost) data will then be re-transmitted.
>
> http://en.wikipedia.org/wiki/Transmission_Control_Protocol

Ja, TCP gør for hver eneste pakke, men IP, som jo ligger under kan skam
godt fragmentere pakkerne;

"If the upper layer protocol does not self-police its own size by first
looking at the Layer 2 Maximum Transmission Unit (MTU) size, and sends
the IP layer too much data, IP is forced to fragment the original
datagram into smaller fragments for transmission."

http://en.wikipedia.org/wiki/Internet_Protocol

Så hvis f.eks. FTP sender en stor fil i f.eks. 10000 bytes blokke,
så vil TCP laget sende 1 pakke og modtage 1 ACK.
Men IP neden under vil "sansynligvis" fragmentere pakken ned til
nogle håndterbare 1500 bytes pakker.
I modtagerenden bliver de så samlet igen inden de 10000 bytes sendes
til TCP.


/Morten

---

On Sat, 19 May 2007 00:54:46 +0200, "KV" <nospam@REMOVE.gmail.com>
wrote:

>> Man sender ikke en ACK for hver eneste pakke.

> Jo, det gør man:

Nej, det gør man ikke.

> The TCP module at the far end sends back an acknowledgement for
> packets which have been successfully received;

Det er ret upræcist formuleret.

Man ACK'er for modtagelsen af en mængde oktetter (bytes), ikke pakker,
og ACKs er kummulative, sådan at en ACK af sekvensnummer X er en ACK
af alt data op til (men ikke med) X.

Så ja, man sender ACKs for data, men *ikke for en pakke ad gangen*.

Læs RFC 793, hvis du ikke tror på mig. Jon Postel tror du vel?

-A
--
Hvis du bruger et anti-spam program, der spammer os andre i hvert
eneste indlæg, ser jeg ikke dine indlæg. Jeg filtrerer dem bort.

---

"Asbjorn Hojmark" <Asbjorn@Hojmark.ORG> wrote in message
news:738t431e428gmt00es56c47efdpjl8p9aj@hojmark.net...
> On Sat, 19 May 2007 00:54:46 +0200, "KV" <nospam@REMOVE.gmail.com>
> wrote:
>
>>> Man sender ikke en ACK for hver eneste pakke.
>
>> Jo, det gør man:
>
> Nej, det gør man ikke.
>
>> The TCP module at the far end sends back an acknowledgement for
>> packets which have been successfully received;
>
> Det er ret upræcist formuleret.
>
> Man ACK'er for modtagelsen af en mængde oktetter (bytes), ikke pakker,
> og ACKs er kummulative, sådan at en ACK af sekvensnummer X er en ACK
> af alt data op til (men ikke med) X.
>
> Så ja, man sender ACKs for data, men *ikke for en pakke ad gangen*.
>
> Læs RFC 793, hvis du ikke tror på mig. Jon Postel tror du vel?

Hmm..

Den er akkumulerende.. dvs hvis der ligger 20 pending pakker, og man ack'er
den sidste så er alle ack'et ?

Jeg har lavet en lille webserver i en uC over Uip tcp/ip, men den håndtere
kun 1 pakke, det skal jeg have ændret.

Problemet er windows er frygtelig lang tid om at sende ACK, så derfor kan
den kun komme op på de ca. 7kbyte/sec hvis jeg husker ret med 1 pakke.

Kasper

---

> Jeg har lavet en lille webserver i en uC over Uip tcp/ip, men den håndtere
> kun 1 pakke, det skal jeg have ændret.

small footprint, effecient, cheap, pick any 2 (eller noget .

Thomas
--
If you put a million monkeys at a million keyboards, one of them will
eventually write a Java program. The rest of them will write Perl
programs." -- Anonymous

---

Kasper skrev:

> Den er akkumulerende.. dvs hvis der ligger 20 pending pakker,
> og man ack'er den sidste så er alle ack'et ?

Netop.

--
Bertel
http://bertel.lundhansen.dk/      http://fiduso.dk/

---

On Sat, 19 May 2007 09:51:52 +0200, "Kasper" <kasper@kasper.kasper>
wrote:

> Den er akkumulerende.. dvs hvis der ligger 20 pending pakker, og
> man ack'er den sidste så er alle ack'et ?

Well, man ACK'er som sagt bytes, ikke pakker, men princippet er
korrekt forstået.

1) Man bliver enige om et vindue på X
2) Afsenderen sender X bytes
3) Modtageren ACK'er sekvensnr Y (der er tidligere sekvensnr + X)
4) Afsenderen sender X bytes
etc

Hvor mange IP-pakker, der faktisk skal til at sende X bytes, kan
variere fra en enkelt til mange, afhængig af vinduesstørrelsen og TCP
options. Størrelsen af vinduet forhandles ved setup, og at det kan
ændres undervejs (typisk ved pakketab)... men det vil føre for vidt at
diskutere i detaljer her i en DSL udbydergruppe.

> Jeg har lavet en lille webserver i en uC over Uip tcp/ip, men den
> håndtere kun 1 pakke, det skal jeg have ændret.

Uha ja. Det giver meget ringe performance.

-A
--
Hvis du bruger et anti-spam program, der spammer os andre i hvert
eneste indlæg, ser jeg ikke dine indlæg. Jeg filtrerer dem bort.