Bluecom og hastighet.
Bjørn H
betaler for.
Les denne: http://www.bluecom.no/index.php?cat=2768&id=44454
Hilsen Bjørn
B.D.
"Bjørn H" <hel...@bluezone.no> wrote in message
news:rdGs8.107$R05.6...@rdr1.wms.teleglobe.net...
Lurer på når Telenor følger etter, de har jo visstnok lovet det.. (har blitt
diskutert i denne gruppen før...)
Stein Pettersen
"B.D." <bj...@spamcop.net> wrote in message
news:a8vdvr$qsq$1...@samson.equant.no...
Vil tro at det gjelder for alle leverandører som leier utstyr av Telenor
Mvh Stein
Kyrre Baker
Jeg kan ikke akkurat si at jeg har savnet de få prosentene, men det er
likevel en velkommen sak :-) Betaler man for det; så gjør man jo det
:-)
Forøvrig er jeg ganske så mye mer fornøyd med Bluecom en NextGenTel
hele veien. Alt fra oppetid til kunde-service er bedre. Det eneste er
uthastigheten, men den kan jeg leve med :-)
--
Kyrre Baker <URL:http://www.kyrres.net/>
B.D.
"Stein Pettersen" <no...@nowhere.no> wrote in message
news:thHs8.2620$cm1....@news4.ulv.nextra.no...
> Ja, det gjør de. Telenor skal også øke hastigheten med 20%
> Vil tro at det gjelder for alle leverandører som leier utstyr av Telenor
Vel, jeg venter i spenning.. har fremdeles aldri vært over 610kbit/s på min
"704kb" linje....
Kjetil Torgrim Homme
> Vel, jeg venter i spenning.. har fremdeles aldri vært over
> 610kbit/s på min "704kb" linje....
vel, eg oppnår utan problem det teoretiske maksimumet på 614 kbps
(75,0 KiB/s) frå mi 640 kbps-linje frå NGT. (ruteren seier at han er
konfigurert til levere 704 kbps med rå bandbreidde, men NGT brukar
ikkje dette talet i sitt reklamemateriell). som du ser er ein
framleis eit lite stykke unna det dei reklamerer med, men eg er godt
nøgd med dette. Telenor (og dermed Bluecom) har litt meir overhead
pga. den tekniske løysinga dei har valt (PPPoE vs. PPPoA), så 704 kbps
brutto gir der 608 kbps (74,3 KiB/s) netto.
--
Kjetil T. [ nerd #3 -- http://nerdquiz.thathost.com ]
Roy-Magne Mo
> Telenor (og dermed Bluecom) har litt meir overhead
> pga. den tekniske løysinga dei har valt (PPPoE vs. PPPoA), så 704 kbps
> brutto gir der 608 kbps (74,3 KiB/s) netto.
Vi brukar ikkje PPPoE, men reint ethernet. Så det vil seie at
vi slepp PPP-overheadet som Telenor kompenserar for.
I praksis vil det seie at du bør få meir ut av linja hos oss
enn Telenor.
På den andre side vil Telenor ha anledning til å køyre større
MTU-storleik, men det trur eg ikkje vanlege brukarar vil
merke noko til.
--
Roy-Magne Mo
Bjorn Djupvik
"Roy-Magne Mo" <r...@sunnmore.net> wrote in message
news:slrnab8e8...@gaupe.sunnmore.no...
> In article <1rn0wcw...@einn.ifi.uio.no>, Kjetil Torgrim Homme wrote:
> > Telenor (og dermed Bluecom) har litt meir overhead
> > pga. den tekniske løysinga dei har valt (PPPoE vs. PPPoA), så 704 kbps
> > brutto gir der 608 kbps (74,3 KiB/s) netto.
>
> Vi brukar ikkje PPPoE, men reint ethernet. Så det vil seie at
> vi slepp PPP-overheadet som Telenor kompenserar for.
>
> I praksis vil det seie at du bør få meir ut av linja hos oss
> enn Telenor.
Det er mulig, men det Telenor burde gjøre er å snarest slutte å markedsføre
linja som 704 og heller gjøre som NGT, kalle den for 640.. det er ihvertfall
to skritt nærmere sannheten...
Bjørn Mork
Det blir ikke vesentlig forskjell på PPPoE, PPPoA eller bridging. Det
meste av overhead stammer fra transporten over ATM uansett. Se f.eks.
http://www.dslforum.org/aboutdsl/Technical_Reports/TR-043.pdf
for en grei sammenligning av de tre variantene. Appendix C gir noen
overhead-beregninger.
Bjørn
--
Reagan is white, right?
Roy-Magne Mo
> Det blir ikke vesentlig forskjell på PPPoE, PPPoA eller bridging. Det
> meste av overhead stammer fra transporten over ATM uansett. Se f.eks.
> http://www.dslforum.org/aboutdsl/Technical_Reports/TR-043.pdf
> for en grei sammenligning av de tre variantene. Appendix C gir noen
> overhead-beregninger.
Nei, det vil ikkje vere der det meste ligg :)
Det er rett at det er ATM som står for det meste av overheadet.
Dessverre er det ikkje enkelt for enkelte å klare å få med seg
desse konsepta.
Det er nok av brukarar som forventar garantert tenestekvalitet
på Internett. Skal Forbrukarombodet inn i desse samanhengane
bør dei nesten forstå dette sjølv.
--
Roy-Magne Mo
Bjørn H
"Roy-Magne Mo" <r...@sunnmore.net> skrev i melding
news:slrnab8gk...@gaupe.sunnmore.no...
Jeg er uenig i din konklusjon. Det er internett leverandørene, og ikke
forbrukerne som må forstå at de selger en linje på 384/128. Da må de levere
minimum den hastigheten. Jeg bruker Bluecom ADSL 384/128, og har aldrig hatt
over 330kbit/s i følge ITavisen. Dette er det samme som å kjøpe 1 liter melk
som bare er fylt med 0,85 liter. Da er det egentlig liten trøst i at naboen
som bruker Telenor får bare 312kbit/s. Bortsett fra hastigheten er jeg
fornøyd med Bluecom.
Hilsen Bjørn
Bjorn Djupvik
> Dette er det samme som å kjøpe 1 liter melk
> som bare er fylt med 0,85 liter.
Det er nok overhead på meieriet / svinn i produksjonen som gjør at du ikke
får en hel liter, men det har ikke meieriet lyst til at de fleste skal vite
så derfor merker de kartongene med 1L :-)
Bjørn Mork
> Jeg er uenig i din konklusjon. Det er internett leverandørene, og ikke
> forbrukerne som må forstå at de selger en linje på 384/128.
Nei, feilen er bruk av tall i det hele tatt i produktspesifikasjonene.
Det er bare forvirrende for ikke-profesjonelle kunder. Man selger ikke
en fastlinje, man selger internett-aksess for privat- kunder. Det
inkluderer mye mer enn teoretisk lokal linjehastighet.
Bjørn
--
You must be a real cretin to think that Multics is a really bad
operating system.
Roy-Magne Mo
> Jeg er uenig i din konklusjon. Det er internett leverandørene, og ikke
> forbrukerne som må forstå at de selger en linje på 384/128. Da må de levere
> minimum den hastigheten. Jeg bruker Bluecom ADSL 384/128, og har aldrig hatt
> over 330kbit/s i følge ITavisen. Dette er det samme som å kjøpe 1 liter melk
> som bare er fylt med 0,85 liter. Da er det egentlig liten trøst i at naboen
> som bruker Telenor får bare 312kbit/s. Bortsett fra hastigheten er jeg
> fornøyd med Bluecom.
Du har eit poeng der, men dette er likevel noko anna enn ei fastlinje
eller eit oppringt samband over vanlege linjer.
Ved seinaste testar, får ei 704-linje, 730 kb/s. Dette er faktisk
meir enn det ein betalar for, om du ser slik på det.
Dette er hovudsakleg for Telenor har kompensert for linjehastigheita
si, og vi har mindre overhead. Og det vil seie at du forhåpentlegvis
snart får meir enn det du betalar for også :)
BTW: bestiller du ein halvliter på uteplassane rundt om, så får
du ofte 0,4l :)
Det er ein del ankepunkt mot testen til IT-avisen, men den er
likevel retningsgivande.
--
Roy-Magne Mo
Roy-Magne Mo
> Nei, feilen er bruk av tall i det hele tatt i produktspesifikasjonene.
> Det er bare forvirrende for ikke-profesjonelle kunder. Man selger ikke
> en fastlinje, man selger internett-aksess for privat- kunder. Det
> inkluderer mye mer enn teoretisk lokal linjehastighet.
For bluecom sin del heiter desse linjene forsåvidt 3+, 10+ osv :)
Men det er likevel ikkje det folk er interessert i å høyre.
--
Roy-Magne Mo
Thore Harald Hoye
> Det er nok overhead på meieriet / svinn i produksjonen som gjør at du ikke
> får en hel liter, men det har ikke meieriet lyst til at de fleste skal vite
> så derfor merker de kartongene med 1L :-)
Det er heldigvis ikke slik det virker. Dette blir kontrollmålt jevnlig, og
står det en liter på melkekartongen, så er det en liter. Mål gjerne selv.
Om det skulle vise seg at litermålet ditt sier noe annet, er det
sansynligvis feil. Det samme gjelder f.eks. en kilo smør. Viser vekten noe
annet, er den sansynligvis feil.
Det er ingen grunn til å akseptere at man får mindre enn man blir oppgitt
på andre områder heller. For skjermer har man f.eks. begynt å oppgi
både faktisk og brukbar bildeflate.
Bjørn Mork
> Det er heldigvis ikke slik det virker. Dette blir kontrollmålt jevnlig, og
> står det en liter på melkekartongen, så er det en liter. Mål gjerne selv.
> Om det skulle vise seg at litermålet ditt sier noe annet, er det
> sansynligvis feil. Det samme gjelder f.eks. en kilo smør. Viser vekten noe
> annet, er den sansynligvis feil.
>
> Det er ingen grunn til å akseptere at man får mindre enn man blir oppgitt
> på andre områder heller. For skjermer har man f.eks. begynt å oppgi
> både faktisk og brukbar bildeflate.
Ja, dette er lett målbare størrelser. Linjehastighet uten overhead er
ikke uten videre det. Den avhenger av hva du flytter, og kan for
ATM-basert ADSL variere fra ca 10% til 165%. Og hvilken rolle spiller
det for deg om ISPen din har den høyeste teoretiske hastigheten hvis
de samtidig overbooker mer enn alle andre? Eller hva om de baserer seg
på sytråder ut i verden?
Det er flott om folk tester og sammenligner reell ytelse, service og
tjenester mellom ISPene. Men å sammenligne ISPenes oppgitte linje-
hastigheter er ganske meningsløst når det gjelder privat Internett-
aksess. Den er i beste fall kun veiledende uansett, og vil bare bli
enda mer unøyaktig om du krever at ISPene også skal ta høyde for
overhead.
Bjørn
--
Man, how can you say that the sexual revolution is over?
Kjetil Torgrim Homme
> Dette er det samme som å kjøpe 1 liter melk som bare er fylt med
> 0,85 liter.
klarte ikkje å motstå analogitrangen:
synest du at det er feil å betale kilopris for appelsinskrell også?
B.D.
"Thore Harald Hoye" <thh...@online.no> wrote in message
news:slrnab913o...@whitestar.d2g.com...
For ordens skyld, mitt innlegg var ironisk ment, derav ":-)"'en
B.D.
> Det er ein del ankepunkt mot testen til IT-avisen, men den er
> likevel retningsgivande.
Enig. den beste testen etter min mening er å bruke et overvåkningsverktøy
ala MRTG og laste ned noen store filer gjerne fra et par tre raske servere
samtidig..
Hvis noen er intressert i hvordan linja mi yter kan dere se på denne url'en,
har lagt opp et eksempelbilde fra MRTG....
Viser reell inn og ut hastighet ganske bra:
B.D.
"Kjetil Torgrim Homme" <kjet...@haey.ifi.uio.no> wrote in message
news:1rn0wcw...@einn.ifi.uio.no...
>(ruteren seier at han er
> konfigurert til levere 704 kbps med rå bandbreidde, men NGT brukar
> ikkje dette talet i sitt reklamemateriell). som du ser er ein
> framleis eit lite stykke unna det dei reklamerer med, men eg er godt
> nøgd med dette.
Dette er mitt poeng også, jeg savner ikke de 70-80kbit/s jeg mangler så mye,
det er markedsføringen av dette produktet som får mange til å føre seg
lurt...
Roy-Magne Mo
> Enig. den beste testen etter min mening er å bruke et overvåkningsverktøy
> ala MRTG og laste ned noen store filer gjerne fra et par tre raske servere
> samtidig..
ttcp på unix funkar ganske greitt, merk at du her blir spelt enkelte puss
av ATM, og du bør forstå resultatet.
Nedlasting av store filer over ftp og http med ein klient som viser rett
burde også vere greitt.
SNMP er ikkje nødvendigvis noko godt mål på hastigheita, det varierar ofte
fleire prosent på kva som blir målt.
--
Roy-Magne Mo
Bjørn H
">
> klarte ikkje å motstå analogitrangen:
>
> synest du at det er feil å betale kilopris for appelsinskrell også?
>
> --
juice. Ikke 0,85 liter.
Hilsen Bjørn
Thore Harald Hoye
In article <hvelhnq...@rasputin.ws.nextra.no>, Bjørn Mork wrote:
> Ja, dette er lett målbare størrelser. Linjehastighet uten overhead er
> ikke uten videre det. Den avhenger av hva du flytter, og kan for
> ATM-basert ADSL variere fra ca 10% til 165%. Og hvilken rolle spiller
Teoretisk sett, selvsagt. Jeg regner med at du vet at for de fleste gjør
det langt mindre utslag i praksis.
> det for deg om ISPen din har den høyeste teoretiske hastigheten hvis
> de samtidig overbooker mer enn alle andre? Eller hva om de baserer seg
> på sytråder ut i verden?
Om dette hadde vært et problem, tror jeg noen her hadde klaget, slik man
gjorde da det var det for Chello for to år siden. Siden ikke vi hører noe,
blir det bare enda en teoretisk problemstilling. Det hadde selvsagt vært
fint å oppgi konsentrasjon i tillegg, slik de satser mye hardere på i
England, men når ingen gjør det, tar jeg det som et tegn på at de vet at
ikke de er noe særlig bedre enn andre.
> Det er flott om folk tester og sammenligner reell ytelse, service og
> tjenester mellom ISPene. Men å sammenligne ISPenes oppgitte linje-
> hastigheter er ganske meningsløst når det gjelder privat Internett-
Det er meningsløst, fordi noen av selskapene, som f.eks. det du jobber
for, oppgir svært misvisende tall. Jeg har vanskelig for å tro at det er
helt tilfeldig at Chello først oppgav Maestro til 640 kbit, Telenor kommer
med 704 kbit, og Chello deretter endrer sitt til 768 kbit.
> aksess. Den er i beste fall kun veiledende uansett, og vil bare bli
> enda mer unøyaktig om du krever at ISPene også skal ta høyde for
> overhead.
Det er jo bare tull å si.
Bjorn Egil Moltu
>
> Ja, hvis jeg kjøper ferdigskrellede appelsiner på Rema får jeg 1 liter
> juice. Ikke 0,85 liter.
Har du sjekket? Tror nok IT-gutta sjekker bedre. Rema-kunder sjekker
helt sikker like ofte, men vi kan med et lite klikk sjekke kvaliteten
på linja med diverse hastighetsmålerer. Tror nok ikke rema(rimi?) hagen
gir sine kunder et like godt instrument.
Bjørn Egil
Bjorn Egil Moltu
>
> Det er meningsløst, fordi noen av selskapene, som f.eks. det du jobber
> for, oppgir svært misvisende tall. Jeg har vanskelig for å tro at det er
> helt tilfeldig at Chello først oppgav Maestro til 640 kbit, Telenor kommer
> med 704 kbit, og Chello deretter endrer sitt til 768 kbit.
Men jeg fikk også Chellos påberopte hastighet. Tro meg, jeg målte og
målte om igjen..:) Hadde jeg vært Telenor, hadde jeg implementer litt over.
Koster ingenting... håper det er en "selger" i Telenor har har fått
sparken i det siste!
Bjørn Egil
Bjørn Mork
>
>> Ja, dette er lett målbare størrelser. Linjehastighet uten overhead er
>> ikke uten videre det. Den avhenger av hva du flytter, og kan for
>> ATM-basert ADSL variere fra ca 10% til 165%. Og hvilken rolle spiller
>
> Teoretisk sett, selvsagt. Jeg regner med at du vet at for de fleste gjør
> det langt mindre utslag i praksis.
Selvsagt. Men hvilket tall er riktig? Det eneste man kan garantere er
at overhead er mindre enn 165%, men som du sier den i være langt
lavere for de fleste praktiske formål. Det vil likevel være å føre
kundene bak lyset hvis man garanterer noe annet enn denne fullstendig
urealistiske verdien.
>> det for deg om ISPen din har den høyeste teoretiske hastigheten hvis
>> de samtidig overbooker mer enn alle andre? Eller hva om de baserer seg
>> på sytråder ut i verden?
>
> Om dette hadde vært et problem, tror jeg noen her hadde klaget, slik man
> gjorde da det var det for Chello for to år siden. Siden ikke vi hører noe,
> blir det bare enda en teoretisk problemstilling. Det hadde selvsagt vært
> fint å oppgi konsentrasjon i tillegg, slik de satser mye hardere på i
> England, men når ingen gjør det, tar jeg det som et tegn på at de vet at
> ikke de er noe særlig bedre enn andre.
Tja, noen norske ISPer selger da ADSL med forskjellige konsentrasjons-
klasser.
Men når vi ikke har noen ekstrem overbooking i Norge er det jo fordi
markedet er dominert av seriøse aktører med strenge kvalitetskrav. Jeg
tviler på at det vil fortsette i det uendelige. Det er tross alt mye
enklere å selge lav pris enn høy kvalitet. Det dukker nok snart opp noen
luringer som vet å utnytte pressens naive "1024 kbit/s er 1024 kbit/s"
holdning.
>> Det er flott om folk tester og sammenligner reell ytelse, service og
>> tjenester mellom ISPene. Men å sammenligne ISPenes oppgitte linje-
>> hastigheter er ganske meningsløst når det gjelder privat Internett-
>
> Det er meningsløst, fordi noen av selskapene, som f.eks. det du jobber
> for, oppgir svært misvisende tall. Jeg har vanskelig for å tro at det er
> helt tilfeldig at Chello først oppgav Maestro til 640 kbit, Telenor kommer
> med 704 kbit, og Chello deretter endrer sitt til 768 kbit.
Janco/Chello startet da virkelig med "10 Mbit/s". Ikke at det noen
gang var oppnåelig, men det er et fint eksempel på hvor meningsløse
disse tallene er. Dagens "chello plus" er et mye bedre Internett-
abonnement enn "10 Mbit/s"-varianten var mot slutten, til tross for at
"chello plus" nå "bare" er definert som 768 kbit/s.
>> aksess. Den er i beste fall kun veiledende uansett, og vil bare bli
>> enda mer unøyaktig om du krever at ISPene også skal ta høyde for
>> overhead.
>
> Det er jo bare tull å si.
Fordi? Det som oppgis i dag, irrelevant eller ei, er tross alt en
korrekt, målbar verdi. Hvis man skal ta høyde for overhead er man over
på synsing og fingeren-i-luften-tall. Jeg har vansker med å se hva de
kan brukes til. Sammenlignbare med noe annet blir de ihvertfall ikke
uten å ta hensyn til hele beregningsmetoden, og da kan man da like
godt gjøre beregningene selv fra grunnen av.
Det vil aldri bli mulig å beskrive et internettabonnement med ett
tall, men hvis man først skal oppgi ett er det vel en fordel om det
har en eller annen fast referanse?
Bjørn
--
You make me sick.
Bjørn H
"> Har du sjekket? Tror nok IT-gutta sjekker bedre. Rema-kunder sjekker
> helt sikker like ofte, men vi kan med et lite klikk sjekke kvaliteten
> på linja med diverse hastighetsmålerer. Tror nok ikke rema(rimi?) hagen
> gir sine kunder et like godt instrument.
>
> Bjørn Egil
Beklager, men jeg kan ikke se ett sted dine IT-gutter eller ISP leverandører
har greid å levere det di reklamerer for.
Hilsen Børn
Thore Harald Hoye
> Thore Harald Hoye wrote:
>>
>> Det er meningsløst, fordi noen av selskapene, som f.eks. det du jobber
>> for, oppgir svært misvisende tall. Jeg har vanskelig for å tro at det er
>> helt tilfeldig at Chello først oppgav Maestro til 640 kbit, Telenor kommer
>> med 704 kbit, og Chello deretter endrer sitt til 768 kbit.
>
> Men jeg fikk også Chellos påberopte hastighet. Tro meg, jeg målte og
> målte om igjen..:) Hadde jeg vært Telenor, hadde jeg implementer litt over.
Jeg vet det, jeg hadde Chello før, men byttet til NGT for å få høyere
ut-hastighet. Jeg ble litt skuffet da jeg gikk fra de 93-94 KB/s jeg fikk
med 768-linjen til Chello, til 66 KB/s med 640-linjen til NGT, siden de da
kostet det samme. I ettertid har det jo endret seg. Chello har økt til 500
for samme produktet, mens NGT har kompensert for overhead, og i tillegg
gitt meg 1 mbit for 523.
Bjørn Nordbø
> In article <1rn0wcw...@einn.ifi.uio.no>, Kjetil Torgrim Homme wrote:
>> Telenor (og dermed Bluecom) har litt meir overhead
>> pga. den tekniske løysinga dei har valt (PPPoE vs. PPPoA), så 704 kbps
>> brutto gir der 608 kbps (74,3 KiB/s) netto.
>
> Vi brukar ikkje PPPoE, men reint ethernet. Så det vil seie at
> vi slepp PPP-overheadet som Telenor kompenserar for.
Men dere tunellerer trafikken over ATM mellom DSLAM og konsentrator
regner jeg med? I så fall har dere omtrent det samme overheadet som
alle andre.
> På den andre side vil Telenor ha anledning til å køyre større
> MTU-storleik, men det trur eg ikkje vanlege brukarar vil
> merke noko til.
Hvorfor skulle Telenor ha anledning til å kjøre større MTU enn dere?
--
At midnight all the agents and their superhuman crew come
out and round up everyone that knows more than they do.
-- Bob Dylan, "Desolation Row"
Bjørn Nordbø
> In article <hvelhnq...@rasputin.ws.nextra.no>, Bjørn Mork wrote:
>> Ja, dette er lett målbare størrelser. Linjehastighet uten overhead er
>> ikke uten videre det. Den avhenger av hva du flytter, og kan for
>> ATM-basert ADSL variere fra ca 10% til 165%. Og hvilken rolle spiller
>
> Teoretisk sett, selvsagt. Jeg regner med at du vet at for de fleste gjør
> det langt mindre utslag i praksis.
Nei, spilltrafikk har et overhead på 25%-45%, avhengig av en hel del
faktorer.
>> det for deg om ISPen din har den høyeste teoretiske hastigheten hvis
>> de samtidig overbooker mer enn alle andre? Eller hva om de baserer seg
>> på sytråder ut i verden?
>
> Om dette hadde vært et problem, tror jeg noen her hadde klaget, slik man
> gjorde da det var det for Chello for to år siden. Siden ikke vi hører noe,
> blir det bare enda en teoretisk problemstilling. Det hadde selvsagt vært
> fint å oppgi konsentrasjon i tillegg, slik de satser mye hardere på i
> England, men når ingen gjør det, tar jeg det som et tegn på at de vet at
> ikke de er noe særlig bedre enn andre.
Hvordan i alle dager vet du at dette ikke er et problem? Jeg skal garan-
tere deg at det en en god del ADSL-kunder som får betraktelig redusert
hastighet pga. høy konsentrasjonsfaktor.
>> aksess. Den er i beste fall kun veiledende uansett, og vil bare bli
>> enda mer unøyaktig om du krever at ISPene også skal ta høyde for
>> overhead.
>
> Det er jo bare tull å si.
Nei, for overheaden er ukjent. Det eneste man kan regne seg frem til er
maks- og min-verdier. Råhastigheten er absolutt.
Thore Harald Hoye
> Selvsagt. Men hvilket tall er riktig? Det eneste man kan garantere er
> at overhead er mindre enn 165%, men som du sier den i være langt
> lavere for de fleste praktiske formål. Det vil likevel være å føre
> kundene bak lyset hvis man garanterer noe annet enn denne fullstendig
> urealistiske verdien.
Det eneste endel nå kan garantere er jo at hastigheten de under en hver
omstendighet maksimalt kan oppnå er 15% lavere. Jeg kan ikke skjønne at
det skal være å føre folk mindre bak lyset. Får man 168% overhead, er
det fordi man overfører knøttsmå pakker. Det vil usansynlig sjelden
skje om man samtidig overfører store mengder data.
>> blir det bare enda en teoretisk problemstilling. Det hadde selvsagt vært
>> fint å oppgi konsentrasjon i tillegg, slik de satser mye hardere på i
>> England, men når ingen gjør det, tar jeg det som et tegn på at de vet at
>> ikke de er noe særlig bedre enn andre.
>
> Tja, noen norske ISPer selger da ADSL med forskjellige konsentrasjons-
> klasser.
Jeg har ikke sett det for annet enn bedriftsabonnementer.
> enklere å selge lav pris enn høy kvalitet. Det dukker nok snart opp noen
> luringer som vet å utnytte pressens naive "1024 kbit/s er 1024 kbit/s"
> holdning.
Vel, pressen ser jo ut til å henge seg veldig mye opp i IT-avisens
tester, noe som gjør det endel vanskeligere. Det er desverre få som ser
på overføring til utlandet, men det kommer kanskje om det skulle vise
seg å bli et problem.
> Janco/Chello startet da virkelig med "10 Mbit/s". Ikke at det noen
> gang var oppnåelig, men det er et fint eksempel på hvor meningsløse
De fikk jo svært høy hastighet i begynnelsen, men det dabbet jo av etter
som noen haiet med full hastighet hele tiden. Etter det ble det skrudd
ned.
> disse tallene er. Dagens "chello plus" er et mye bedre Internett-
> abonnement enn "10 Mbit/s"-varianten var mot slutten, til tross for at
> "chello plus" nå "bare" er definert som 768 kbit/s.
Men så er det også omtrent det de får.
>>> aksess. Den er i beste fall kun veiledende uansett, og vil bare bli
>>> enda mer unøyaktig om du krever at ISPene også skal ta høyde for
>>> overhead.
>>
>> Det er jo bare tull å si.
>
> Fordi? Det som oppgis i dag, irrelevant eller ei, er tross alt en
> korrekt, målbar verdi. Hvis man skal ta høyde for overhead er man over
Fordi man *vet* at det blir minst f.eks. 15% overhead, og for de aller
fleste tilfeller der man faktisk trenger hele båndbredden, vil den holde
seg på temmelig nøyaktig det, kanskje + et par prosent om man f.eks.
laster ned en websiden med veldig mange små bilder. Du henger deg opp i
tekniske dikkedarier som ikke har noen praktisk innvirkning.
Carl Stefan Grøtter
> Jeg er uenig i din konklusjon. Det er internett leverandørene, og ikke
> forbrukerne som må forstå at de selger en linje på 384/128. Da må de
> levere minimum den hastigheten. Jeg bruker Bluecom ADSL 384/128, og har
> aldrig hatt over 330kbit/s i følge ITavisen. Dette er det samme som å
> kjøpe 1 liter melk som bare er fylt med 0,85 liter. Da er det egentlig
> liten trøst i at naboen som bruker Telenor får bare 312kbit/s. Bortsett
> fra hastigheten er jeg fornøyd med Bluecom.
Dette har vært diskutert til det kjedsommelige tidligere, så jeg er
overrasket over jeg gidder å svare på noe slikt nok en gang.
Anyway... Når du kjøper en forbindelse til internett kjøper du "rå
båndbredde". Du kjøper ikke "opplevd hastighet", som er noe helt annet. For
å bruke ditt melke-eksempel kan man da si at linjen er selve kartongen,
mens dataene du sender er melka. Den rå båndbredden vil da tilsvare de
utvendige målene til melkekartongen, hvilket, som du sikkert vet, er
betraktelig mer enn en liter.
Det er et uomtvistelig faktum at du er avhengig av såkalt overhead for at
dine data skal komme frem til den maskinen de er ment å komme frem til. Det
er også et uomtvistelig faktum at det i all tid (inntil bredbånd ble
vanlige til uvitende privatpersoner) har vært enighet om at linjehastighet
måles i hvor mange nuller og enere det er teoretisk mulig å sende gjennom
linjen, inkludert all kontrollinformasjon.
Når enkelte ISP-er (det er veldig lite vanlig) likevel "kompenserer" for
overhead er det utelukkende fordi de blir lei av å diskutere med kunder som
ikke kan/vil/gidder skjønne hvordan virkeligheten er.
Det er forøvrig litt merksnodig at folk begynner å klage over disse få
prosentene med en gang de får en "fastlinje" med høy hastighet til en
billig penge, mens de samme menneskene aldri har klaget over at de "mister"
nesten 8 kbps på sin trege, men kjempedyre, ISDN-linje.
--
Carl Stefan Grøtter
www.kverulant.net || ne...@kverulant.net
<Sett inn underfundig tankevekker her>
Roy-Magne Mo
> Men dere tunellerer trafikken over ATM mellom DSLAM og konsentrator
> regner jeg med? I så fall har dere omtrent det samme overheadet som
> alle andre.
Ja - vi køyrer ethernet over ATM same som Telenor, men Telenor køyrer
også PPPoE på det laget i tillegg.
> Hvorfor skulle Telenor ha anledning til å kjøre større MTU enn dere?
Fordi du brukar PPP og ikkje ethernet til pakkestorleik.
--
Roy-Magne Mo
Bjørn Mork
> In article <Hdbt8.3471$dm4....@news2.ulv.nextra.no>, Bjørn Nordbø wrote:
>
>> Men dere tunellerer trafikken over ATM mellom DSLAM og konsentrator
>> regner jeg med? I så fall har dere omtrent det samme overheadet som
>> alle andre.
>
> Ja - vi køyrer ethernet over ATM same som Telenor, men Telenor køyrer
> også PPPoE på det laget i tillegg.
Det gir ingen forskjell under 1492 byte, og nokså ubetydelig forskjell
ved større datamengder. Sender du 10 KiB må du bruke 217 ATM-celler
med PPPoE og 216 uten. Det er selvsagt en forskjell, men du skal være
ganske fintfølende for å merke den.
>> Hvorfor skulle Telenor ha anledning til å kjøre større MTU enn dere?
>
> Fordi du brukar PPP og ikkje ethernet til pakkestorleik.
PPPoE mangler foreløpig en fragmenteringsmekanisme, så hver PPP-pakke
må trykkes inn i en ethernet-pakke. Det begrenser maks MTU til 1492
byte.
Bjørn
--
You must be a real fool to think that a mentally retarded man ain't
got nothing in the world these days.
Roy-Magne Mo
> Det gir ingen forskjell under 1492 byte, og nokså ubetydelig forskjell
> ved større datamengder. Sender du 10 KiB må du bruke 217 ATM-celler
> med PPPoE og 216 uten. Det er selvsagt en forskjell, men du skal være
> ganske fintfølende for å merke den.
Ja, men resultatet vil typisk vere at du vil sjå det som litt forskjell
ved full blås.
> PPPoE mangler foreløpig en fragmenteringsmekanisme, så hver PPP-pakke
> må trykkes inn i en ethernet-pakke. Det begrenser maks MTU til 1492
> byte.
ok
--
Roy-Magne Mo
Bjørn H
>
> Det er nok overhead på meieriet / svinn i produksjonen som gjør at du
ikke
> får en hel liter, men det har ikke meieriet lyst til at de fleste skal
vite
> så derfor merker de kartongene med 1L :-)
>
Harryhead.
Hilsen Bjørn
Kjetil Torgrim Homme
> Fordi? Det som oppgis i dag, irrelevant eller ei, er tross alt en
> korrekt, målbar verdi. Hvis man skal ta høyde for overhead er man
> over på synsing og fingeren-i-luften-tall. Jeg har vansker med å
> se hva de kan brukes til. Sammenlignbare med noe annet blir de
> ihvertfall ikke uten å ta hensyn til hele beregningsmetoden, og da
> kan man da like godt gjøre beregningene selv fra grunnen av.
eg basererer meg på maksimal netto gjennomstrøyming i ein enkelt
TCP-straum. det er dette som er relevant for dei fleste kundar, og
det er også lett å rekne ut.
Kjetil Torgrim Homme
> Det er forøvrig litt merksnodig at folk begynner å klage over
> disse få prosentene med en gang de får en "fastlinje" med høy
> hastighet til en billig penge, mens de samme menneskene aldri har
> klaget over at de "mister" nesten 8 kbps på sin trege, men
> kjempedyre, ISDN-linje.
dette må du forklare for meg. kvar forsvinn desse 8 kbps?
Lars Erik Gullerud
news:slrnab913o...@whitestar.d2g.com...
> In article <a91nov$p4e$1...@sunshine.equant.no>, Bjorn Djupvik wrote:
> > Det er nok overhead på meieriet / svinn i produksjonen som gjør at du
ikke
> > får en hel liter, men det har ikke meieriet lyst til at de fleste skal
vite
> > så derfor merker de kartongene med 1L :-)
>
> Det er heldigvis ikke slik det virker. Dette blir kontrollmålt jevnlig, og
> står det en liter på melkekartongen, så er det en liter. Mål gjerne selv.
> Om det skulle vise seg at litermålet ditt sier noe annet, er det
> sansynligvis feil. Det samme gjelder f.eks. en kilo smør. Viser vekten noe
> annet, er den sansynligvis feil.
Skal man sammenlikne med melk, må man jo måle med hvor mye av melken man
faktisk kan få i seg. OK, det råe innholdet i kartongen er 1 liter. Hvor mye
av dette er "overhead" i form av at noen dråper blir igjen inni kartongen,
på innsiden av melkeglasset osv. uten at det kommer innabords? Det varierer
med f.eks. hvor mange glass man bruker - mange små glass gir mere
dråpe-overhead enn å drikke rett fra kartongen.
På samme måte som innholdet i melkekartongen er absolutt og målbar, så er
den rå linjehastigheten absolutt og målbar. Overhead, og dermed inntaket av
melk eller overføringshastighet på linje, er variabel.
Jeg tror jammen jeg skal skrive et brev til forbrukerrådet og klage på at
jeg ikke får 1 liter melk, så Tine må begynne å inkludere noen prosent
ekstra for å ta høyde for hvor mye som blir hengende igjen i kartongen og i
glassene mine...
/leg
Carl Stefan Grøtter
> [Carl Stefan Grøtter]
>
>> Det er forøvrig litt merksnodig at folk begynner å klage over
>> disse få prosentene med en gang de får en "fastlinje" med høy
>> hastighet til en billig penge, mens de samme menneskene aldri har
>> klaget over at de "mister" nesten 8 kbps på sin trege, men
>> kjempedyre, ISDN-linje.
>
> dette må du forklare for meg. kvar forsvinn desse 8 kbps?
>
De forsvinner til såkalt overhead (akkurat det samme som det forsvinner til
når man har ADSL, kabelmodem eller liknende). Altså informasjon som legges
med i hver eneste pakke om hvor mange pakker du sender, hvor de skal til,
hvor de kommer fra, informasjon om hvordan de skal settes sammen igjen,
hvilken rute de har tatt, osv, osv, osv...
Kjetil Torgrim Homme
> Kjetil Torgrim Homme <kjet...@haey.ifi.uio.no> wrote:
>
> > [Carl Stefan Grøtter]
> >
> >> Det er forøvrig litt merksnodig at folk begynner å klage over
> >> disse få prosentene med en gang de får en "fastlinje" med høy
> >> hastighet til en billig penge, mens de samme menneskene aldri har
> >> klaget over at de "mister" nesten 8 kbps på sin trege, men
> >> kjempedyre, ISDN-linje.
> >
> > dette må du forklare for meg. kvar forsvinn desse 8 kbps?
>
> De forsvinner til såkalt overhead (akkurat det samme som det
> forsvinner til når man har ADSL, kabelmodem eller liknende). Altså
> informasjon som legges med i hver eneste pakke om hvor mange
> pakker du sender, hvor de skal til, hvor de kommer fra,
> informasjon om hvordan de skal settes sammen igjen, hvilken rute
> de har tatt, osv, osv, osv...
det må du nesten belegge meir nøyaktig. etter mine utrekningar er det
2 kbps overhead for ein TCP-straum over 64 kbps ISDN. dette skriv seg
frå 40 oktettar per 1500 TCP/IP-pakke, og 8 oktettar PPP per pakke.
kva har eg gløymt? (ved MTU på 376 oktettar er overhead 8 kbps, men
det er i såfall eit val brukaren har gjort sjølv.)
Thore Harald Hoye
> Skal man sammenlikne med melk, må man jo måle med hvor mye av melken man
> faktisk kan få i seg. OK, det råe innholdet i kartongen er 1 liter. Hvor mye
> av dette er "overhead" i form av at noen dråper blir igjen inni kartongen,
> på innsiden av melkeglasset osv. uten at det kommer innabords? Det varierer
> med f.eks. hvor mange glass man bruker - mange små glass gir mere
> dråpe-overhead enn å drikke rett fra kartongen.
Det er riktig, ikke gi deg! :)
Carl Stefan Grøtter
news:1rpu145...@einn.ifi.uio.no:
Så i detalj kjenner ikke jeg TCP/IP-protokollen så der har jeg ikke noe
grunnlag for å diskutere med deg. Jeg har bare lært en gang, at for en
gjennomsnittlig bruker vil overhead normalt være ca 10% av den totale
båndbredden. En gjennomsnittlig bruker utnytter som kjent ikke linjen
optimalt til enhver tid.
Dette stemmer ganske godt overens med mine egne observasjoner, og jeg har
derfor antatt at det var omtrent riktig. Om du derimot kan vise at jeg tar
feil, og at normal bruk kun fører til 2 % overhead, så er jeg villig til å
endre mitt syn.
Kjetil Torgrim Homme
> Så i detalj kjenner ikke jeg TCP/IP-protokollen så der har jeg
> ikke noe grunnlag for å diskutere med deg. Jeg har bare lært en
> gang, at for en gjennomsnittlig bruker vil overhead normalt være
> ca 10% av den totale båndbredden. En gjennomsnittlig bruker
> utnytter som kjent ikke linjen optimalt til enhver tid.
det er ved bulkoverføringar at brukarane merkar at ting tek tid, og då
vert overhead slik som eg viste. ved interaktiv bruk (t.d. SSH eller
Citrix) vil overhead vere større, nettopp fordi gjennomsnittleg
pakkestorleik vil minke. likevel tør eg påstå at folk flest vil rekne
dette problemet som irrelevant så lenge dei kan laste ned musikk og
film så raskt som tenestetilbydaren lovar.
--
Kjetil T. [ nerd #4 -- http://nerdquiz.thathost.com ]
Bjørn Nordbø
> In article <Hdbt8.3471$dm4....@news2.ulv.nextra.no>, Bjørn Nordbø wrote:
> Ja - vi køyrer ethernet over ATM same som Telenor, men Telenor køyrer
> også PPPoE på det laget i tillegg.
Overheadet på PPPoE er omtrent null og niks. Hvis ikke jeg husker
feil ligger det på ca. 0.5% for store (~1500 bytes) rammer.
Jarle H Knudsen
wrote:
>Overheadet på PPPoE er omtrent null og niks. Hvis ikke jeg husker
>feil ligger det på ca. 0.5% for store (~1500 bytes) rammer.
Men http://www.dslreports.com/speed sier at du kan vente en nedgang på
5-25% i makshastighet hvis du brukler PPPoE.
--
Jarle H. K nudsen
Roy-Magne Mo
> Men http://www.dslreports.com/speed sier at du kan vente en nedgang på
> 5-25% i makshastighet hvis du brukler PPPoE.
Og i følge Telenor er det ein ubetydeleg nedgang som 90% av brukarane
aldri vil merke noko til :)
--
Roy-Magne Mo
Bjørn Mork
Vel, det er ganske enkelt sprøyt.
Overhead ved bruk av PPPoE er 8 byte per 1500 byte pakke, som gir deg
0,5%. Det aller meste av det du ser av overhead på en ADSL-linje
skyldes ATM-laget. Dette slipper du ikke unna ved å bruke noe annet
enn PPPoE.
Bjørn
--
You sound like a real quiche-eater.
Roy-Magne Mo
> Overhead ved bruk av PPPoE er 8 byte per 1500 byte pakke, som gir deg
> 0,5%. Det aller meste av det du ser av overhead på en ADSL-linje
> skyldes ATM-laget. Dette slipper du ikke unna ved å bruke noe annet
> enn PPPoE.
Og ved ein pakkestorleik på 64 byte, er vi oppe i 9%. Uansett korleis
du ser på det, så er det overhead.
--
Roy-Magne Mo
Bjørn Nordbø
Nei, faktisk ikke. En 64 byte stor pakke blir splittet opp i to ATM-
celler enten den enkapsuleres i PPPoE eller ei.
Uansett; get a life. Dersom du dytter avgårde så små pakker må du
være forberedt på grasat mye overhead samme hvordan du gjør det.
Roy-Magne Mo
> Nei, faktisk ikke. En 64 byte stor pakke blir splittet opp i to ATM-
> celler enten den enkapsuleres i PPPoE eller ei.
Stemmer :)
> Uansett; get a life. Dersom du dytter avgårde så små pakker må du
> være forberedt på grasat mye overhead samme hvordan du gjør det.
Eg skal slutte å bruke dns!
--
Roy-Magne Mo
Terje Krogdahl
En privatperson har et rimelig sært bruksområde for en xDSL-linje hvis man
bare skal frakte DNS-pakker. Poenget er vel litt det at for endel typer
trafikk spiller faktisk ikke overhead noen praktisk rolle.
--
Terje Krogdahl
- Peace, love and interoperability
Bjørn Mork
Ved en pakkestørrelse på 64 byte er PPPoE-overhead faktisk eksakt 0%
når du bruker det over ATM.
Bjørn
--
Man, don't you realise that people are dying every day?
Kjetil Torgrim Homme
> Nei, faktisk ikke. En 64 byte stor pakke blir splittet opp i to
> ATM- celler enten den enkapsuleres i PPPoE eller ei.
kva legg du i pakkestorleik?
viss det er nyttedata, må du leggje til 52 oktettar for TCP-header (12
av dei er for valfrie, men svært vanlege, TCP time stamps). så kjem
evt. 8 oktettar PPP, deretter 14 oktettar Ethernet-ramme. totalt skal
138 oktettar sendast. dette må puttast inn i ATM-celler som kvar har
ein fast storleik på 48 oktettar med 5 oktettar header. her må ein
til med tre celler, eller 1272 bits. dette vert sendt i rammer på 193
bits, med 1 bit overhead. alt i alt vert det sendt 1279 bits for å
overføre den opprinnelege meldinga på 512 bits.
viss det var snakk om ein DNS-pakke, så vert det brukt UDP i staden
for TCP, noko som sparar 32 oktettar overhead. i ein slik situasjon
gjer PPP-innkapslinga skilnaden mellom 2 eller 3 ATM-celler, og ein
klarer seg med å overføre 853 bits. (dette illustrerer Bjørn Morks
poeng...)
for å ta reknestykka igjen, denne gongen med ein full pakke med 1448
(BlueCom/NGT) eller 1440 (Telenor) oktettar nyttelast. dette er ein
ganske typisk situasjon for FTP, HTTP og anna bulkoverføring over TCP.
NextGenTel:
1448+52+8 => 32 celler => 13639 bits
utnyttingsgrad: 1448*8/13639 == 84,93%
Bluecom:
1448+52+14 => 32 celler => 13639 bits
utnyttingsgrad: 1448*8/13639 == 84,93%
Telenor ADSL
1440+8+52+14 => 32 celler => 13639 bits
utnyttingsgrad: 1440*8/13639 == 84,46%
eg har tidlegare i denne gruppa presentert reknestykkje som ikkje tok
hensyn til svinn i ATM-cellene, og då kome fram til ein annan
konklusjon som i større grad er til fordel for NGT. eg beklagar
feilinformasjonen.
det som er ganske interessant er at brukaren kan redusere svinnet ved
å justere ned MTU.
NGT, MTU 1480, nyttelast 1428 => 31 celler => 86,46%
Bluecom, MTU 1466, nyttelast 1414 => 31 celler => 85,62%
Telenor, MTU 1458, nyttelast 1406 => 31 celler => 85,13%
(ein del trafikk brukar ikkje så store pakkar som MTU tillet uansett,
noko som gjer at overhead vert større for dei forbindelsane.)
for meg som er NGT-brukar er skilnaden ca. eitt minutt for ei
nedlasting som varer ein time ;-)
> Uansett; get a life.
hah!
Jarle H Knudsen
For å sitere siden: "PPPoE adds a little bit more header to every
packet, but it adds quite a bit more CPU requirement to the process of
sending data. Depending on the PPPoE stack in use, and how fast your
ADSL was before PPPoE arrived, you can expect to see a 5-25%
degradation in maximum speed."
De tar altså hensyn til annet enn bare overhead.
--
Jarle H. Knudsen
Steinar Haug
| For å sitere siden: "PPPoE adds a little bit more header to every
| packet, but it adds quite a bit more CPU requirement to the process of
| sending data. Depending on the PPPoE stack in use, and how fast your
| ADSL was before PPPoE arrived, you can expect to see a 5-25%
| degradation in maximum speed."
CPU-forbruket *kan* tenkes å være relevant for en billig hjemmeruter som
ofte har ganske langsom CPU. Det må betraktes som helt irrelevant hvis
man gjør PPPoE prosesseringen på en av dagens PCer med CPU som kjører på
på mange hundre MHz.
(Reality check: En Pentium 166 eller deromkring klarer å *mette* et 100
Mbps Ethernet med data når den kjører FreeBSD, antagelig også med Linux.
ADSL hastighet er normalt 2 Mbps eller mindre, og dagens PCer kjører på
500 Mhz eller mer. Jeg tror man skal slite hardt for å lage en så lite
effektiv PPPoE stakk at prosessering av 2 Mbps betyr noe som helst ved
500 Mhz eller mer.)
Steinar Haug, Nethelp consulting, sth...@nethelp.no
B. Johannessen
> (Reality check: En Pentium 166 eller deromkring klarer å *mette* et 100
> Mbps Ethernet med data når den kjører FreeBSD, antagelig også med Linux.
> ADSL hastighet er normalt 2 Mbps eller mindre, og dagens PCer kjører på
> 500 Mhz eller mer. Jeg tror man skal slite hardt for å lage en så lite
> effektiv PPPoE stakk at prosessering av 2 Mbps betyr noe som helst ved
> 500 Mhz eller mer.)
til informasjon/referanse:
jeg kjoerte en pentium 66 som adsl router/firewall en stund, med
en userspace pppoe implementasjon, og denne brukte ca 50% cpu (load
0.5) naar jeg benyttet all inngaaende baandbredde (1mbit). dette paa
linux 2.4.something.
Bob
Bjørn Nordbø
> [Bjørn Nordbø]
>
>> Nei, faktisk ikke. En 64 byte stor pakke blir splittet opp i to
>> ATM- celler enten den enkapsuleres i PPPoE eller ei.
>
> kva legg du i pakkestorleik?
I dette tilfellet bare en klump med data. Dette er for å slippe å
regne ut hvor stor en pakke faktisk er med n oktetter nyttedata og
overhead i IP, TCP, 802.3, PPPoE og AAL5/SNAP.
Latskap? Uten tvil; jeg lever tross alt av å tagge Perl... :)
Thore Harald Hoye
> NGT, MTU 1480, nyttelast 1428 => 31 celler => 86,46%
Jeg testet mot ftp.no.debian.org, og wget oppgav disse hastighetene:
MTU KB/s
1460: 123,60
1470: 124,43
1476: 125,03
1478: 125,28
1479: 121,33
1480: 121,45
1490: 122,45
1500: 123,23
Jeg brukte wget på en 4,4 MB fil, minst to ganger på hver mtu, og
resultatet varierte med +/- 0.03% på det meste, men stort sett mindre enn
0.01%.
Noen som vet om wgets K er 1024 eller 1000 bytes?
# traceroute ftp.no.debian.org
traceroute to spheniscus.uninett.no (158.36.2.10), 30 hops max, 38 byte
packets
1 router (10.0.0.1) 0.957 ms 0.868 ms 0.846 ms
2 213-145-178-1.dd.nextgentel.com (213.145.178.1) 15.012 ms 13.537 ms
17.199 ms
3 217-13-7-65.dd.nextgentel.com (217.13.7.65) 13.529 ms 14.775 ms
14.499 ms
4 217-13-7-36.dd.nextgentel.com (217.13.7.36) 14.556 ms 14.001 ms
13.788 ms
5 217-13-7-93.dd.nextgentel.com (217.13.7.93) 14.201 ms 13.735 ms
13.766 ms
6 oslo-gw1.uninett.no (193.156.90.1) 14.530 ms 15.590 ms 15.486 ms
7 spheniscus.uninett.no (158.36.2.10) 15.354 ms 15.215 ms 15.434 ms
Thore Harald Hoye
> resultatet varierte med +/- 0.03% på det meste, men stort sett mindre enn
> 0.01%.
Beklager, det skal være 0,3 og 0,1%.
Kjetil Torgrim Homme
> In article <1rr8ley...@thrir.ifi.uio.no>, Kjetil Torgrim Homme wrote:
> > NGT, MTU 1480, nyttelast 1428 => 31 celler => 86,46%
>
> Jeg testet mot ftp.no.debian.org, og wget oppgav disse hastighetene:
> MTU KB/s
> 1460: 123,60
> 1470: 124,43
> 1476: 125,03
> 1478: 125,28
> 1479: 121,33
> 1480: 121,45
> 1490: 122,45
> 1500: 123,23
takk! hmm. skal tru kvar dei to oktettane kjem inn? der er kanskje
noko AAL5-greier eller liknande som eg ikkje veit om.
> Jeg brukte wget på en 4,4 MB fil, minst to ganger på hver mtu, og
> resultatet varierte med +/- 0.03% på det meste, men stort sett
> mindre enn 0.01%.
>
> Noen som vet om wgets K er 1024 eller 1000 bytes?
: [kjetilho@false ~/tmp/wget-1.5.3]; src grep KB
./src/retr.c: sprintf (res, "%.2f KB/s", dlrate / 1024.0);
Bjørn Mork
> [Thore Harald Hoye]
>
>> In article <1rr8ley...@thrir.ifi.uio.no>, Kjetil Torgrim Homme wrote:
>> > NGT, MTU 1480, nyttelast 1428 => 31 celler => 86,46%
>>
>> Jeg testet mot ftp.no.debian.org, og wget oppgav disse hastighetene:
>> MTU KB/s
>> 1460: 123,60
>> 1470: 124,43
>> 1476: 125,03
>> 1478: 125,28
>> 1479: 121,33
>> 1480: 121,45
>> 1490: 122,45
>> 1500: 123,23
>
> takk! hmm. skal tru kvar dei to oktettane kjem inn? der er kanskje
> noko AAL5-greier eller liknande som eg ikkje veit om.
AAL5 gir deg en 8 byte CPCS-trailer per payload. Men PPP er mer effektiv
enn du regner med; den krever bare 2 byte ekstra. Så målingen stemmer
veldig bra med teorien. Morsomt å se det demonstrert så tydelig.
Bjørn
--
It takes a communist jerk like you to say that young people don't get
married to mentally retarded people because they can't spray paint
that small, but feminist people are sick.
Kjetil Torgrim Homme
> [Thore Harald Hoye]
>
> > Kjetil Torgrim Homme wrote:
> > > NGT, MTU 1480, nyttelast 1428 => 31 celler => 86,46%
> >
> > Jeg testet mot ftp.no.debian.org, og wget oppgav disse hastighetene:
> > MTU KB/s
> > 1478: 125,28
> > 1480: 121,45
>
> AAL5 gir deg en 8 byte CPCS-trailer per payload. Men PPP er mer
> effektiv enn du regner med; den krever bare 2 byte ekstra.
takk for info!
> Så målingen stemmer veldig bra med teorien. Morsomt å se det
> demonstrert så tydelig.
ja, men det stemmer ikkje heilt med utnyttingsgradsreknestykket mitt :-/
Thore har NGT Charlie, marknadsført som 1024, men i røynda 1184 kbps.
det skulle ha vore 124,79 og 121,06 respektive i fylgje mitt
reknestykkje. at han fekk mindre kunne eg forstått (t.d. småtrafikk
ved sida av), men her får han faktisk bandbreidde som tilsvarar 1188
kbps brutto. vel vel, det er ei pølse i slaktetida, men litt
irriterande likevel.
--
Kjetil T. [ http://www.petitiononline.com/warcrime/petition.html ]
Bjørn Mork
> Thore har NGT Charlie, marknadsført som 1024, men i røynda 1184 kbps.
> det skulle ha vore 124,79 og 121,06 respektive i fylgje mitt
> reknestykkje. at han fekk mindre kunne eg forstått (t.d. småtrafikk
> ved sida av), men her får han faktisk bandbreidde som tilsvarar 1188
> kbps brutto. vel vel, det er ei pølse i slaktetida, men litt
> irriterande likevel.
Serveren bruker nok ikke noen TCP options. Det er slett ikke uvanlig å
se 20 bytes TCP-headere fra http-servere.
Bjørn
--
I have many dead friends.
Kjetil Torgrim Homme
> Serveren bruker nok ikke noen TCP options. Det er slett ikke
> uvanlig å se 20 bytes TCP-headere fra http-servere.
dessverre, han testa mot ftp.no.debian.org == ftp.uninett.no, og dei
brukar TCP time stamps. han sa vel ikkje eksplisitt at han brukte
FTP-protokoll, og eg fekk ikkje teste HTTP no sidan spheniscus var
nede :/
Thore Harald Hoye
> dessverre, han testa mot ftp.no.debian.org == ftp.uninett.no, og dei
> brukar TCP time stamps. han sa vel ikkje eksplisitt at han brukte
> FTP-protokoll, og eg fekk ikkje teste HTTP no sidan spheniscus var
> nede :/
Det var FTP, ja. Jeg brukte wget siden det gjorde det enkelt å
halv-automatisere det.
Anders Brenden
"Bjørn H" <hel...@bluezone.no> skrev i melding
news:rdGs8.107$R05.6...@rdr1.wms.teleglobe.net...
> Nå ser det endelig ut til at vi som bruker Bluecom skal få det produktet
vi
> betaler for.
> Les denne: http://www.bluecom.no/index.php?cat=2768&id=44454
>
> Hilsen Bjørn
>
>
Poenget her er jo at det er Telenor som setter opp hastigheten på alle
samband med 20%!! Bluecom er jo en kunde av Telenor og vil også få en økning
på sine samband. I denne annonsen ser det jo ut som om det er Bluecom som
har ordnet hele biffen, men det er feil!! Det er Telenor som har tatt hele
initiativet i denne saken.
Oppgraderingene starter så smått denne uken. Når vi ser at det går bra, vil
alle samband bli tatt fortløpenede.
Marius Bernklev
> Poenget her er jo at det er Telenor som setter opp hastigheten på
> alle samband med 20%!!
På privatlinjer også? I så fall, tøft.
Da gjenstår det å se bare én liten ting, jeg har nemlig såpass lang
linjelengde at jeg ikke fikk kjøpe noe annet enn 384kbs. Det jeg
lurer på, er, hvis kobberet er for dårlig, om dette oppdages fort
(hvis ikke, vet jeg hvor gøy det er med masse packet loss. jippi!), og
i så fall om man prøver på en gradvis nedtrapping eller bare setter
den tilbake til 384. Stay tuned. :-)
Marius
--
<URL: http://www.stud.ifi.uio.no/~mariube/>
Newsere mot X-No-Archive
Roy-Magne Mo
> Poenget her er jo at det er Telenor som setter opp hastigheten på alle
> samband med 20%!! Bluecom er jo en kunde av Telenor og vil også få en økning
> på sine samband. I denne annonsen ser det jo ut som om det er Bluecom som
> har ordnet hele biffen, men det er feil!! Det er Telenor som har tatt hele
> initiativet i denne saken.
Kven er i dette tilfellet «Telenor»? Du utbasunerar at Telenor er eit konsern,
skal ikkje Telenor vere fleire firma?
Telenor har gitt etter for press frå marknaden, der Bluecom arbeidar
aktivt med sine leverandørar for å kunne tilby sine kundar eit godt
produkt.
--
Roy-Magne Mo
Anders Brenden
"Roy-Magne Mo" <r...@sunnmore.net> skrev i melding
news:slrnac947...@gaupe.sunnmore.no...
Telenor i dette tilfelle er Telenor Network Services. Det er de som eiger
nettet. Telenor er kun er ISP på lik linje med Bluecom, Tiscali etc for oss
som jobber med ADSL i Networks
Anders Brenden
"Marius Bernklev" <mar...@ifi.uio.no> skrev i melding
news:3cfbscb...@sex.ifi.uio.no...
Bare ta det med ro, dette vil merkes med en gang!
Disse endringene kjøres i Batch om natten, ene og en sentral. De som feiler
kommer ut som avvik som blir rettet morgenen etter. Feiler den på 464 kbit,
vil den bli satt tilbake til 384 kbit. Da dette er ferdiglagde profiler som
blir brukt mot management systemene til DSLAM!