---

hej. er det nye isp Sverige Perspektiv udbyde i DK?

---

> hej. er det nye isp Sverige Perspektiv udbyde i DK?

Ja, læs her: http://www.cph-metronet.dk/.

Venlig hilsen
Dag Stinus

---

Tak, for oplysning.
Skal man skal have abonnement Tlf hos TDC først ikke?før man kan
oprette ADSL!!


On Thu, 13 Oct 2005 17:45:46 +0200, "Dag Stinus"
<dag@SLETTESstinus.dk> wrote:

>> hej. er det nye isp Sverige Perspektiv udbyde i DK?
>
>Ja, læs her: http://www.cph-metronet.dk/.
>
>Venlig hilsen
>Dag Stinus
>

---

har find ud af med det. De kun tilbyd kunden i Sjælland ...sur æble

On Fri, 14 Oct 2005 07:40:47 +0200, hoodini <Holy@saki.com> wrote:

>Tak, for oplysning.
>Skal man skal have abonnement Tlf hos TDC først ikke?før man kan
>oprette ADSL!!
>
>
>On Thu, 13 Oct 2005 17:45:46 +0200, "Dag Stinus"
><dag@SLETTESstinus.dk> wrote:
>
>>> hej. er det nye isp Sverige Perspektiv udbyde i DK?
>>
>>Ja, læs her: http://www.cph-metronet.dk/.
>>
>>Venlig hilsen
>>Dag Stinus
>>

---

"Dag Stinus" <dag@SLETTESstinus.dk> writes:

> Ja, læs her: http://www.cph-metronet.dk/.

Det lyder som en sund og spændende virksomhed.

Jeg vil dog lige advare om et problem med deres top-produkt. (24Mbps /
1 Mbps)

Man siger vist normalt noget om, at ratio mellem op og ned bør være
mindst 1:8. Jeg har snakket med et par forskere på COM center (eller
institut for datakommunikation, eller hvad de nu er i gang med at
komme til at hedde nu) på DTU, og de siger normalt, at 1:10 er
minimum.

Forklaringen er denne:

Når man er i gang med en dataoverførsel via TCP, så skal TCP-stakken
hos klienten sende en ACK-pakke for hver pakke, den får fra
serveren. Eftersom stort set alle servere (og klienter) i dag kører
Ethernet, er datapakken højst 1500 bytes, mens ACK-pakken er på 60
bytes.

Det betyder, at for hver 1500 bytes serveren sender, sender klienten
60. Det giver et nødvendigt forhold på 1:25.

I praksis er der vist en del nyere TCP-implementationer, som lukker
mere igennem - det gælder i hvert fald min linux på arbejdet, som
lukker to pakker igennem. Det betyder, at forholdet bliver 1:50.

Disse tal gælder dog kun ved hurtige, konstante dataoverførsler. (FTP
eller HTTP af store filer, f.eks.)

Ved almindelig blandet http-trafik ser jeg en ACK-pakke
pr. data-pakke. Og den gennemsnitlige pakke på Forskningsnettet ligger
på omkring 750 bytes. Nuvel, det inkluderer så en masse ACK-pakker,
men sikkert også nogle meget solide dataoverførsler, så jeg tillader
mig at regne med tallet. Det giver ca. 1:12 og betyder altså i
praksis, at en ordentlig udnyttelse af en 24 Mbps kræver 2 Mbps den
anden vej.

Og hvis man kører så hårdt har man i øvrigt ingen reel
upload-kapacitet ved siden af.

Jeg har kontaktet cph-metronet om problemet og nævnt COMs
anbefalinger. Det første svar var noget i retning af "vi vil senere
lave højere upload-kapaciteter, men ikke nu" og da jeg uddybede
problemet fik jeg et svar i retning af "Jeg forstår ikke, hvad du
snakker om".

Jeg tør i hvert fald hverken købe eller anbefale 24/1-produktet lige
nu.

--
Peter B. Juul, o.-.o "All great epics come to an end. The Iliad. The
The RockBear. ((^)) Odyssey. War and Peace. Buffy the Vampire Slayer.
I speak only 0}._.{0 Just kidding. The Tolstoy book is a ringer.
for myself. O/ \O Doesn't belong on this list. Too literal.
Not enough monsters." - New York Newsday

---

Uden at kende til firmaet andet end fra deres hjemmeside og uden at
have undersøgt sagen så grundigt som dig vil jeg prøve at sige
én ting til deres forsvar:

Det du nævner omhandler vel kun TCP forbindelser? Hvis man nu
forestiller sig at det de og/eller kunden havde tænkt sig at bruge den
store download til services, der kører over UDP (f.eks. [kommende] IP
fjernsyn, IP telefoni, evt. netradioer m.v. der kører over UDP), så
er det du nævner ikke et problem.

Ellers kan man blot sige, at prisen er interessant, selv om man reelt
kun kan få glæde af f.eks. de 10-14 Mbit/s download. Og det, at
upload starter ved 1 Mbit/s, hvor ADSL har været begrænest til
højest 768 Kbit/s, er da glædeligt...

Men det er da godt at nogen er vagtsomme overfor markedsføringen

vh
Nicolas

---

xnicolas@gmail.com writes:

> Det du nævner omhandler vel kun TCP forbindelser? Hvis man nu
> forestiller sig at det de og/eller kunden havde tænkt sig at bruge den
> store download til services, der kører over UDP (f.eks. [kommende] IP
> fjernsyn, IP telefoni, evt. netradioer m.v. der kører over UDP), så
> er det du nævner ikke et problem.

Helt sikkert!

Og som nævnt: Hvis man kun kører enkelte, hurtige streams af
fil-overførsler, så bør man også kunne nå de 24 Mbps. Jeg ved ikke,
hvordan det ser ud mht. p2p-ting, jeg har ikke haft lejlighed til at
studere trafikmønsteret.

Men man skal i hvert fald ikke regne med at kunne spille on-line spil
imens...

--
Peter B. Juul, o.-.o "We haven't lost and we never will
The RockBear. ((^)) Today you came into our grasp
I speak only 0}._.{0 We are going to kill you
for myself. O/ \O We are going to kill you
By giving you lots of water to drink"

---

Undskyld mig lige, men du blander da vist lige 2 ting sammen - FRAME
SIZE og WINDOW SIZE. Et WINDOW består af x antal frames. Man kan SELV
sætte hvor stort WINDOWS (x antal frames) der skal være, FØR der
bliver lavet en ACK.
Få lige styr på termerne før du konkluderer noget.
24/1 Mbit funger FINT her i Sverige og det vil det osse gøre i DK !
http://www.babinszki.com/Networking/Max-Ethernet-and-TCP-Throughput.html
"This is a simplified model of TCP/IP over Ethernet behaviour of a
single TCP connection intended to provide insight into throughput
limitations of TCP/IP due to network transit latency. In the model,
TCP/IP sends the maximum TCP receive window size worth of application
data (filling the maximum possible receive buffer), then waits for a
single acknowledgement for the entire max. window size burst. The
model also assumes that the instant the acknowledgement is sent, the
data is emptied from the receive buffer and the entire window size is
again fully available."

Lidt ærgeligt du lige skal tage den gode nyhed fra de gode folk - den
HOLDER ALTSÅ og du må lige læse lidt på det med TCP/IP og hvordan
det funger før du kommer med konklusioner (som oven i købet er HELT
ved siden af) !

Peter B. Juul wrote:
> "Dag Stinus" <dag@SLETTESstinus.dk> writes:
>
> > Ja, læs her: http://www.cph-metronet.dk/.
>
> Det lyder som en sund og spændende virksomhed.
>
> Jeg vil dog lige advare om et problem med deres top-produkt. (24Mbps /
> 1 Mbps)
>
> Man siger vist normalt noget om, at ratio mellem op og ned bør være
> mindst 1:8. Jeg har snakket med et par forskere på COM center (eller
> institut for datakommunikation, eller hvad de nu er i gang med at
> komme til at hedde nu) på DTU, og de siger normalt, at 1:10 er
> minimum.
>
> Forklaringen er denne:
>
> Når man er i gang med en dataoverførsel via TCP, så skal TCP-stakken
> hos klienten sende en ACK-pakke for hver pakke, den får fra
> serveren. Eftersom stort set alle servere (og klienter) i dag kører
> Ethernet, er datapakken højst 1500 bytes, mens ACK-pakken er på 60
> bytes.
>
> Det betyder, at for hver 1500 bytes serveren sender, sender klienten
> 60. Det giver et nødvendigt forhold på 1:25.
>
> I praksis er der vist en del nyere TCP-implementationer, som lukker
> mere igennem - det gælder i hvert fald min linux på arbejdet, som
> lukker to pakker igennem. Det betyder, at forholdet bliver 1:50.
>
> Disse tal gælder dog kun ved hurtige, konstante dataoverførsler. (FTP
> eller HTTP af store filer, f.eks.)
>
> Ved almindelig blandet http-trafik ser jeg en ACK-pakke
> pr. data-pakke. Og den gennemsnitlige pakke på Forskningsnettet ligger
> på omkring 750 bytes. Nuvel, det inkluderer så en masse ACK-pakker,
> men sikkert også nogle meget solide dataoverførsler, så jeg tillader
> mig at regne med tallet. Det giver ca. 1:12 og betyder altså i
> praksis, at en ordentlig udnyttelse af en 24 Mbps kræver 2 Mbps den
> anden vej.
>
> Og hvis man kører så hårdt har man i øvrigt ingen reel
> upload-kapacitet ved siden af.
>
> Jeg har kontaktet cph-metronet om problemet og nævnt COMs
> anbefalinger. Det første svar var noget i retning af "vi vil senere
> lave højere upload-kapaciteter, men ikke nu" og da jeg uddybede
> problemet fik jeg et svar i retning af "Jeg forstår ikke, hvad du
> snakker om".
>
> Jeg tør i hvert fald hverken købe eller anbefale 24/1-produktet lige
> nu.
>
> --
> Peter B. Juul, o.-.o "All great epics come to an end. The Iliad. The
> The RockBear. ((^)) Odyssey. War and Peace. Buffy the Vampire Slayer.
> I speak only 0}._.{0 Just kidding. The Tolstoy book is a ringer.
> for myself. O/ \O Doesn't belong on this list. Too literal.
> Not enough monsters." - New York Newsday

---

"LordNam" <lordnam@pier.dk> writes:

> Undskyld mig lige, men du blander da vist lige 2 ting sammen - FRAME
> SIZE og WINDOW SIZE. Et WINDOW består af x antal frames. Man kan SELV
> sætte hvor stort WINDOWS (x antal frames) der skal være, FØR der
> bliver lavet en ACK.

Ja. Jeg ved udmærket hvad Window Size er.

Har du studeret pakkeflowet fra din maskine for nylig? Jeg startede
simpelthen tcpdump på min linux og studerede hvad der faktisk _sker_.

Jeg har netop gjort det samme på min MacOS X herhjemme.

Guess what? Den svarer _også_ for hver anden pakke.

> Få lige styr på termerne før du konkluderer noget.

TCP-vinduet angiver, hvor mange data serveren må sende til klienten
før den skal have fået svar for de første data.

Der kan være masser af data-pakker i transit en vej og ACK-pakker i
transit den anden vej.

Klienten sender stadigvæk løbende ACK-pakker, efterhånden som den
modtager data-pakker.

Hvis klienten - som du faktisk påstår - ventede med at sende ACK til
den havde modtaget hele Window size, så ville der opstå en pause i
transmissionen fra serveren sendte de sidste data og til den modtog
ACK-pakken.

Det er faktisk det, window size skal sikre imod, så det ville jo være
tåbeligt.

Må jeg anbefale, at du selv får styr på dine termer? Og evt. prøver at
kigge på, hvad der sker på dit data-link i stedet for kun at basere
dig på din teoretiske opfattelse af tingene?

Du kan ikke forvente, at Metronets kunder går ud og koder deres egen
TCP-stak, for at have en stak, der passer med den alt for asynkrone
up/down-ratio, som Metronet har valgt.

> 24/1 Mbit funger FINT her i Sverige og det vil det osse gøre i
> DK !

Det glæder mig. Hvis du lige læser mit indlæg igen vil du opdage, at
jeg faktisk siger, at der er situationer, hvor det vil virke og
situationer hvor det ikke vil virke. Jeg vil foretrække at købe et
produkt, hvor den form for begrænsninger ikke ligger implicit i
produktbeskrivelsen.

> http://www.babinszki.com/Networking/Max-Ethernet-and-TCP-Throughput.html

Right.

> "This is a simplified model of TCP/IP over Ethernet behaviour of a
> single TCP connection intended to provide insight into throughput
> limitations of TCP/IP due to network transit latency.

"Simplified model". Den model tager sig af problemet med for små
vinduer. Det er et reelt problem, som opstår, når du sætter visse
OS'er til at snakke på hurtige net-links. Problemet er vigtigt, fordi
det gælder for bl.a. Win2000 og MacOS X, som jo er ganske udbredte.

Problemet drejer sig om, at den maksimale data rate du kan opnå i en
TCP-forbindelse er

Max window size
---------------
round trip time

Sidder du f.eks. og har en pingtid (round trip time) til en server på
250 ms og et max window size på 64KB, så kan du aldrig komme over en
hastighed på 256 KB/s, hvilket vel ikke var, hvad du havde tænkt dig,
da du købte det GE-kort

Det har INTET med up/down-ratio-problemet at gøre.
--
Peter B. Juul, o.-.o "All great epics come to an end. The Iliad. The
The RockBear. ((^)) Odyssey. War and Peace. Buffy the Vampire Slayer.
I speak only 0}._.{0 Just kidding. The Tolstoy book is a ringer.
for myself. O/ \O Doesn't belong on this list. Too literal.
Not enough monsters." - New York Newsday

---

Jeg holder fast i min påstand om at WINDOW SIZE, er hvad som ACK
pakkerne bliver sendt på og IKKE pr. frame.

http://www.dslreports.com/faq/7799

RWIN / WINDOW SIZE og ACKS hænger sammen, muligt du har lavet et
tcpdump på din Linux og konstateret ET - ved ikke hvad / hvordan du
har optimeret stacken. Alt andet lige er det PRÆCIS DET MAN GØR
(OPTIMERER RWIN etc.) for at få bedre. throughput på TCP. UDP er
intet problem, da der jo ingen garanti er for levering.

Igen foreslår jeg du får styr på termerne !

Jeg VED en 24/1 MBIT LEVERER 24/1 MBIT (har du set/anvendt en sådan
ADSL - jeg gør det til hverdag !)

Peter B. Juul wrote:
> "LordNam" <lordnam@pier.dk> writes:
>
> > Undskyld mig lige, men du blander da vist lige 2 ting sammen - FRAME
> > SIZE og WINDOW SIZE. Et WINDOW består af x antal frames. Man kan SELV
> > sætte hvor stort WINDOWS (x antal frames) der skal være, FØR der
> > bliver lavet en ACK.
>
> Ja. Jeg ved udmærket hvad Window Size er.
>
> Har du studeret pakkeflowet fra din maskine for nylig? Jeg startede
> simpelthen tcpdump på min linux og studerede hvad der faktisk _sker_.
>
> Jeg har netop gjort det samme på min MacOS X herhjemme.
>
> Guess what? Den svarer _også_ for hver anden pakke.
>
> > Få lige styr på termerne før du konkluderer noget.
>
> TCP-vinduet angiver, hvor mange data serveren må sende til klienten
> før den skal have fået svar for de første data.
>
> Der kan være masser af data-pakker i transit en vej og ACK-pakker i
> transit den anden vej.
>
> Klienten sender stadigvæk løbende ACK-pakker, efterhånden som den
> modtager data-pakker.
>
> Hvis klienten - som du faktisk påstår - ventede med at sende ACK til
> den havde modtaget hele Window size, så ville der opstå en pause i
> transmissionen fra serveren sendte de sidste data og til den modtog
> ACK-pakken.
>
> Det er faktisk det, window size skal sikre imod, så det ville jo være
> tåbeligt.
>
> Må jeg anbefale, at du selv får styr på dine termer? Og evt. prøver at
> kigge på, hvad der sker på dit data-link i stedet for kun at basere
> dig på din teoretiske opfattelse af tingene?
>
> Du kan ikke forvente, at Metronets kunder går ud og koder deres egen
> TCP-stak, for at have en stak, der passer med den alt for asynkrone
> up/down-ratio, som Metronet har valgt.
>
> > 24/1 Mbit funger FINT her i Sverige og det vil det osse gøre i
> > DK !
>
> Det glæder mig. Hvis du lige læser mit indlæg igen vil du opdage, at
> jeg faktisk siger, at der er situationer, hvor det vil virke og
> situationer hvor det ikke vil virke. Jeg vil foretrække at købe et
> produkt, hvor den form for begrænsninger ikke ligger implicit i
> produktbeskrivelsen.
>
> > http://www.babinszki.com/Networking/Max-Ethernet-and-TCP-Throughput.html
>
> Right.
>
> > "This is a simplified model of TCP/IP over Ethernet behaviour of a
> > single TCP connection intended to provide insight into throughput
> > limitations of TCP/IP due to network transit latency.
>
> "Simplified model". Den model tager sig af problemet med for små
> vinduer. Det er et reelt problem, som opstår, når du sætter visse
> OS'er til at snakke på hurtige net-links. Problemet er vigtigt, fordi
> det gælder for bl.a. Win2000 og MacOS X, som jo er ganske udbredte.
>
> Problemet drejer sig om, at den maksimale data rate du kan opnå i en
> TCP-forbindelse er
>
> Max window size
> ---------------
> round trip time
>
> Sidder du f.eks. og har en pingtid (round trip time) til en server på
> 250 ms og et max window size på 64KB, så kan du aldrig komme over en
> hastighed på 256 KB/s, hvilket vel ikke var, hvad du havde tænkt dig,
> da du købte det GE-kort
>
> Det har INTET med up/down-ratio-problemet at gøre.
> --
> Peter B. Juul, o.-.o "All great epics come to an end. The Iliad. The
> The RockBear. ((^)) Odyssey. War and Peace. Buffy the Vampire Slayer.
> I speak only 0}._.{0 Just kidding. The Tolstoy book is a ringer.
> for myself. O/ \O Doesn't belong on this list. Too literal.
> Not enough monsters." - New York Newsday

---

Prøv at se her Peter:
http://cable-dsl.home.att.net/rwinanim.htm

Den illustrerer det meget godt - ACKS bliver IKKE sendt før HELE
vinduet (WINDOW) er modtaget - jeg HAR ret !

---

"LordNam" <lordnam@pier.dk> writes:

> Prøv at se her Peter:
> http://cable-dsl.home.att.net/rwinanim.htm
>
> Den illustrerer det meget godt - ACKS bliver IKKE sendt før HELE
> vinduet (WINDOW) er modtaget - jeg HAR ret !

Ja, den slags argumenter kan jeg jo intet stille op mod.

-+-
"The argument goes something like this: `I refuse to prove that I
exist,' says God, `for proof denies faith, and without faith I am
nothing.'

"`But,' says Man, `The Babel fish is a dead giveaway, isn't it?
It could not have evolved by chance. It proves you exist, and so
therefore, by your own arguments, you don't. QED.'

"`Oh dear,' says God, `I hadn't thought of that,' and promptly
vanished in a puff of logic.

"`Oh, that was easy,' says Man, and for an encore goes on to
prove that black is white and gets himself killed on the next
zebra crossing.
-+-
--
Peter B. Juul, o.-.o "Man skal ikke dø en lineær død."
The RockBear. ((^)) - Birksted
I speak only 0}._.{0
for myself. O/ \O

---

p4@enzym.rnd.uni-c.dk (Peter B. Juul) writes:

> > Prøv at se her Peter:
> > http://cable-dsl.home.att.net/rwinanim.htm
> >
> > Den illustrerer det meget godt - ACKS bliver IKKE sendt før HELE
> > vinduet (WINDOW) er modtaget - jeg HAR ret !
>
> Ja, den slags argumenter kan jeg jo intet stille op mod.

Hov!

Ja, nu gjorde jeg mig lige den ulejlighed faktisk at SE animationen,
som du linkede til.

Det skulle du måske også gøre. For den viser faktisk præcis, hvad
_jeg_ siger:

Afsender sender pakker afsted. Der er fem pakker i transit af
gangen. Hver gang modtager modtager en pakke, sender han en ACK. Der
er fem ACK i transit af gangen.

Hver gang afsender sender en pakke trækker han 1 fra RWIN. Hver gang
han modtager en ACK, lægger han 1 til RWIN.

Ved et 5 pakker stort RWIN opstår der pauser i trafikken. Ved et 10
pakker stort RWIN gør der ikke.

Det er en glimrende animation. Se den nu selv og prøv at forstå den.

--
Peter B. Juul, o.-.o "Bekæmp med al din kløgt og flid
The RockBear. ((^)) den tåge tåber spreder.
I speak only 0}._.{0 Thi visseligen, ting tager tid,
for myself. O/ \O men ævl tager evigheder" -Piet Hein

---

Desuden Peter, er jeg sikker på MANGE af de producenter som laver
ADSL2+ udstyr, sq da ikke kan tage fejl.
http://www.zyxel.dk/Produkter.32+B6JnR4X1p5WEVMcHJvZHVjdHNfcGkxW3Nob3dVaWRdPTExMCZjSGFzaD04MGYxNTFkZmNh.0.html

Og Zyxel er bare 1 - du skal da ikke fortælle mig at alle disse
udbydere, som udbyder 24/1 Mbit på ADSL2+ herovre i Sverige, samt alle
de leverandører som Zyxel og andre, der laver udstyret til Centralerne
og brugerne er "lige så galt på den" som mig. Du må altså læse
lidt på lektien, før du kommer med disse påstande !
ACK pakkerne bliver FØRST sendt, når REC. WINDOW er fuld ! Og sådan
er det. Den sender ikke en ACK efter hver FRAME !

Og dette er min final post på denne tråd - jeg VED dette funger
PERFEKT med 24/1 i praksis - så må du og DTU folkene (du refererer
til) længere ud på landet ! (men der har de sikkert ikke ADSL2+...
hehe).

---

Peter B. Juul skrev:

> "Dag Stinus" <dag@SLETTESstinus.dk> writes:
>
> > Ja, læs her: http://www.cph-metronet.dk/.
>
> Det lyder som en sund og spændende virksomhed.

> Ved almindelig blandet http-trafik ser jeg en ACK-pakke
> pr. data-pakke. Og den gennemsnitlige pakke på Forskningsnettet ligger
> på omkring 750 bytes. Nuvel, det inkluderer så en masse ACK-pakker,
> men sikkert også nogle meget solide dataoverførsler, så jeg tillader
> mig at regne med tallet. Det giver ca. 1:12 og betyder altså i
> praksis, at en ordentlig udnyttelse af en 24 Mbps kræver 2 Mbps den
> anden vej.

Hehe men nu er i vel også noget forvendte på DTU? ADSL har jo ikke
mulighed for hæjere upload end de 1Mbit.. men det ser vist ud til at
metronet kører 1,2Mbit ifl. deres graf.

Men er det ikke også noget med at i nu har fået Comx
fiberforbindelse? hvordan er den egenligt indplanteret?

---

"Bjarke Hansen" <bjarke_h@hotmail.com> writes:

> Men er det ikke også noget med at i nu har fået Comx
> fiberforbindelse? hvordan er den egenligt indplanteret?

Den koerer raa ethernet.

--
Christian Jørgensen | Use the Source, Luke!
http://www.razor.dk |

---

"Bjarke Hansen" <bjarke_h@hotmail.com> writes:

> Hehe men nu er i vel også noget forvendte på DTU?

Det handler ikke om at være forvænt, men om tekniske begrænsninger i
TCP-specifikationerne.

> ADSL har jo ikke
> mulighed for hæjere upload end de 1Mbit..

Næh, men ADSL har heller ikke mulighed for mere end 8 Mbps downstream,
så der løber man ikke ind i problemer.

Men Metronet kører ADSL2+. Den grundlæggende standard, ITU G.992.5, er
ganske rigtigt maxed ud ved 24/1, mens der er en udvidelse til denne -
Annex L - der tillader 3.5 Mbps upstream.

Ifølge wikipedia har i hvert fald Ericsson lavet udstyr, der kan
levere upstream på 2 Mpbs i ADSL2 og ADSL2+.

> Men er det ikke også noget med at i nu har fået Comx
> fiberforbindelse? hvordan er den egenligt indplanteret?

Jeg aner personligt ikke, hvad du taler om

Jeg sidder ikke på DTU som sådan, men på Uni-C. Jeg arbejder primært
med Forskningsnettets backbone. Hvad jeg henviste til, var, at jeg har
_spurgt_ et par af forskerne på DTUs Com Center (eller hvad det nu
skal til at hedde nu) ud om emnet.

--
Peter B. Juul, o.-.o "Kritikken af dine indlæg skyldes alene det
The RockBear. ((^)) faktum, at du er en idiot."
I speak only 0}._.{0 -Stefan Holm
for myself. O/ \O

---

On 2005-10-15, Peter B. Juul <p4@enzym.rnd.uni-c.dk> wrote:
>
> Men Metronet kører ADSL2+. Den grundlæggende standard, ITU G.992.5, er
> ganske rigtigt maxed ud ved 24/1, mens der er en udvidelse til denne -
> Annex L - der tillader 3.5 Mbps upstream.

Annex M.
Der har vist været nogen forvirring omkring hvilket annex den skulle
ende som, så du er lovligt undskyldt.

--
Andreas

---

Andreas Plesner Jacobsen <apj@daarligstil.dk> writes:

> Annex M.
> Der har vist været nogen forvirring omkring hvilket annex den skulle
> ende som, så du er lovligt undskyldt.

Det får man ud af at belave sig på Wikipedia.
--
Peter B. Juul, o.-.o "All great epics come to an end. The Iliad. The
The RockBear. ((^)) Odyssey. War and Peace. Buffy the Vampire Slayer.
I speak only 0}._.{0 Just kidding. The Tolstoy book is a ringer.
for myself. O/ \O Doesn't belong on this list. Too literal.
Not enough monsters." - New York Newsday

---

Lol - det er da helt utroligt !

Sidder DU og snakker af praktisk erfaring.... nej VEL - det gør jeg.
Har siddet hos FLERE af mine venner herovre og downloadet på en 24/1
Mbit ADSL2+, hvor mange gange har du det ?
Og det er DOWNLOADS over HTTP eller HTTPS, FTP mv. IKKE UDP - så her
ER ACK pakker - og det VIRKER ! Har FLERE gange hentet med 2.7 - 2.8
MegaBYTE (ikke Mbit) i sek. 2.7 MB/sek * 8 = 21,6 Mbit - dvs ca. 90%
udnyttelse I TCP som ANVENDER ACKS. Men det KRÆVER man SÆTTER RWIN
(receive Window). Thats bloody final.

Og med nedenstående link slutter jeg af - så kan du fortsat læse om
24Mbit og jeg..... jeg kan anvende det i praksis !

Folkens DET SPILLER - BARE man har ordentlige KABLER (kobber) og IKKE
bor for langt fra stationerne ! Så spiller det. Nogle KLAGER dog over
de KUN har ca. 19 Mbit effektivt, hvis de bor lidt for langt fra
stationen.

http://www.dslprime.com/a/adsl21.pdf
En af min kammeratter herovre bor ca. 300 - 350 Meter fra stationen,
HAN kører som ovennævnt 2.7 eller 2.8 MegaBYTE download i sek !

http://www.dslreports.com/tweaks/RWIN

Længere nede i teksten:
Why does tuning TCP Receive Window improve throughput?
"TCP is a reliable communication protocol. As a result, sender expects
Acknowlegement (ACK) packets from receiver to make sure packets are
delivered to destination and are free of errors. However, as sending
one packet and waiting for ACK is rather inefficient, a window is
implemented. In this scheme, receiver advertises its RWIN size during
TCP connection setup and sender keeps sending as many packets as
allowed by receive window of receiver. In other words, each packet sent
closes the window a little and each ACK received opens it up a little
again.

On a high bandwidth or high delay (or both simultaneously) TCP
connection, sender may transmit a number of packets before the first
packet reaches the receiver. Even if the receiver were to send ACK
immediately, it takes some more time for the ACK packet to get back to
the sender. To optimize the throughput, the pipe must be filled at all
times and to do this sender should never stall waiting for ACK.This is
only possible if Receive Window is made sufficiently large."

Men du hverken KAN eller VIL høre på at jeg HAR SIDDET PÅ EN 24MBIT
UTALLIGE GANGE, så dine argumenter falder til jorden. Med en MEGET
effektiv utilization på 24 Mbit downstream linien.

---

"LordNam" <lordnam@pier.dk> writes:

> Lol - det er da helt utroligt !

Ja, det er det.

Nu kaster du dig ud i en masse anekdotisk bevisførsel for at
overbevise verden om, at jeg tager fejl og at du har ret.

Men hvis du gad læse, hvad jeg har skrevet adskillige gange, så ville
du se, at jeg har skrevet, at de 24 Mbps formentlig virker fint ved
direkte downloads via HTTP og FTP...

Det er bare _ikke_ fordi du har ret i dit vås om RWIN og ACK-pakker,
men netop fordi forholdet i disse rå enkelt-overførsler falder til
1:25 eller endda 1:50. Og så er der jo intet andet problem, end at man
pludselig ingen samtidig upload-kapacitet har til rådighed.

> Og med nedenstående link slutter jeg af

Den har vi jo hørt før.

> Længere nede i teksten:
> Why does tuning TCP Receive Window improve throughput?

Suk. Det har stadig intet med sagen at gøre. Men det er pænt af dig at
blive ved med at finde ting frem, der bekræfter, hvad jeg har skrevet
flere gange.

--
Peter B. Juul, o.-.o "Honest criticism is hard to take. Particularly
The RockBear. ((^)) from a relative, a friend, an acquaintance, or
I speak only 0}._.{0 a stranger."
for myself. O/ \O - Book of Zuma