Userbase

Lord Utopia schreef:

TomG schreef:Ook waar (anders gaan klanten zich terug gediscrimineerd voelen, denk maar aan ADSL versus ADSL2).

Niet daarom. Maar omdat bepaalde frequenties om bijvoorbeeld hoge uploadsnelheden te halen (full duplux - 30/30 Mbps bijvoorbeeld) de frequenties van ADSL2+ zou beïnvloeden, ofzo.

Dit is niet correct. Bij VDSL(1) klopt dit wel, maar niet voor VDSL2. Eerst en vooral wordt er met DPBO (downstream power back off) gewerkt om de ADSL en ADSL2+ lijnen niet te storen. Anderzijds liggen de frequenties voor upstream (en zeker voor 30 Mbps upstream) volledig buiten het spectrum van de andere DSL technologieën.

Blijkbaar moet onze nieuwsposter zich beter informeren alvorens iemand anders op de vingers te tikken.

quistnix schreef:Dit is niet correct. Bij VDSL(1) klopt dit wel, maar niet voor VDSL2. Eerst en vooral wordt er met DPBO (downstream power back off) gewerkt om de ADSL en ADSL2+ lijnen niet te storen. Anderzijds liggen de frequenties voor upstream (en zeker voor 30 Mbps upstream) volledig buiten het spectrum van de andere DSL technologieën.

Mijn uitleg heb ik gelezen hier op het forum van een Belgacom technieker.

Lord Utopia schreef:

quistnix schreef:Dit is niet correct. Bij VDSL(1) klopt dit wel, maar niet voor VDSL2. Eerst en vooral wordt er met DPBO (downstream power back off) gewerkt om de ADSL en ADSL2+ lijnen niet te storen. Anderzijds liggen de frequenties voor upstream (en zeker voor 30 Mbps upstream) volledig buiten het spectrum van de andere DSL technologieën.

Mijn uitleg heb ik gelezen hier op het forum van een Belgacom technieker.

Dan weet die blijkbaar niet te veel af van DSL. Mijn uitleg komt van een persoon in het DSL Expert team !

Welk forum mag dat wezen Lord Utopia?

Trojan schreef:Welk forum mag dat wezen Lord Utopia?

Dit. Was toen eens een hele uitleg over.

Lord Utopia schreef:
quistnix schreef:
Dit is niet correct. Bij VDSL(1) klopt dit wel, maar niet voor VDSL2. Eerst en vooral wordt er met DPBO (downstream power back off) gewerkt om de ADSL en ADSL2+ lijnen niet te storen. Anderzijds liggen de frequenties voor upstream (en zeker voor 30 Mbps upstream) volledig buiten het spectrum van de andere DSL technologieën.
Mijn uitleg heb ik gelezen hier op het forum van een Belgacom technieker. Dan weet die blijkbaar niet te veel af van DSL. Mijn uitleg komt van een persoon in het DSL Expert team !

Als ADSL1 en ADSL2+ lijnen worden afgeschaft is het spectrum voor VDSL2 groter en kunnen er nog grotere snelheden bereikt worden

Lord Utopia schreef:

Trojan schreef:Welk forum mag dat wezen Lord Utopia?

Dit. Was toen eens een hele uitleg over.

Sorry, welk forum ?

quistnix schreef:

Lord Utopia schreef:

Trojan schreef:Welk forum mag dat wezen Lord Utopia?

Dit. Was toen eens een hele uitleg over.

Sorry, welk forum ?

wow, nog niet goed wakker zeker?
Dit forum zou http://userbase.be/forum wel eens kunnen zijn zeker?

En heb je ook een link naar de specifieke thread in dat forum ?

Zo goed als elke VDSL2-thread.

Als je er de VDSL2 bandplan image eens bijpakt:


Zie je dat de onderste band inderdaad voor downstream gebruikt wordt.

qless schreef:Als je er de VDSL2 bandplan image eens bijpakt:


Zie je dat de onderste band inderdaad voor downstream gebruikt wordt.

En dat bewijst wat ?

Dat het (meer) gebruiken van 130 khz tot 2.2 Mhz (ADSL2+ deel ) niet veel aan upstream gaat helpen

qless schreef:Dat het (meer) gebruiken van 130 khz tot 2.2 Mhz (ADSL2+ deel ) niet veel aan upstream gaat helpen

Als men tot 17 Mhz gaat gebruiken voor bijkomende dragers (carriers) dan komen er 2 banden bij op het einde van het spectrum, US3 en DS4. De upstream 3 band is van 8517 tot 12000 kHz en de downstream 4 band is van 12006 kHz tot 17245 kHz. Dit is dus mijlen ver van de door jouw opgegeven frequenties. Hoe zouden deze bijkomende banden in godsnaam kunnen interferen met de door ADSl en ADSL2+ gebruikte banden ? Niet dus

gr4vity schreef:Het profiel gaat naar 30Mbit. Dit wil niet zeggen dat de snelheid omhoog gaat

Wel bij VDSL2, want dat zit anders ineen dan ADSL.
Als ze hem op 30 zetten dan haal je ook 30.

Of men ook 100u/100d gaat halen durf ik wel te betwijfelen, maar 50/50 mag geen probleem zijn.

BasMSI schreef:Wel bij VDSL2, want dat zit anders ineen dan ADSL.
Als ze hem op 30 zetten dan haal je ook 30.

Waar haal je die wijsheid? Pro compact heeft sowieso een maximaal profiel en is maar 20Mbit - 1,4/1,8Mbit
Als men over gaat naar het 17Mhz spectrum en 30Mbit als profiel neemt (wat ik betwijfel gezien men ook hoger kan gaan) zal er altijd een deel voor Belgacom TV over blijven. En Belgacom gaat zeker en vast de OLO's niet meer geven als ze zelf aanbieden

BasMSI schreef:

gr4vity schreef:Het profiel gaat naar 30Mbit. Dit wil niet zeggen dat de snelheid omhoog gaat

Wel bij VDSL2, want dat zit anders ineen dan ADSL.
Als ze hem op 30 zetten dan haal je ook 30.

Of men ook 100u/100d gaat halen durf ik wel te betwijfelen, maar 50/50 mag geen probleem zijn.

Juist en fout. Het wil niet zeggen dat je op 30Mbit kan synchroniseren dat je ook zo snel kan surfen.

BasMSI schreef:

gr4vity schreef:Het profiel gaat naar 30Mbit. Dit wil niet zeggen dat de snelheid omhoog gaat

Wel bij VDSL2, want dat zit anders ineen dan ADSL.
Als ze hem op 30 zetten dan haal je ook 30.

Of men ook 100u/100d gaat halen durf ik wel te betwijfelen, maar 50/50 mag geen probleem zijn.

Incorrect. Surfsnelheid hangt uiteraard af van de sync snelheid. Maar in in het beste geval kan je surfen op - wat men noemt - syncrate. Dé beperkende factor is wat er in de BAS is voorzien qua configuratie. In het geval van VDSL2 wordt er naar de login gegevens bekeken in de BAS en die worden dan naar de radius server(s) verstuurd. De radius server bekijkt dan of het paswoord overeenkomt met de login. Als dit juist blijkt, dan wordt de PPP sessie goedkeurd (in het andere geval "rejected") en wordt er een parameter gestuurd naar de BAS die dan het juiste QOS (Quality Of Service) profiel gebruikt. Bvb. voor een Go (ondertussen Favorite) is dit dan een qos-policing-policy "rule" van 1500 in upstream en een qos-queuing-policy "rule" van 20000 in downstream. Daardoor is de werkelijke surfsnelheid in upstream 1,5 Mbit/s en de downstream surfsnelheid 20 Mbit/s.

Bovendien, als men Belgacom TV gebruikt, dan snoept die stream van de benodigde (downstream) bandbreedte af.

Weet iemand ondertussen wanneer dit juist gaat gebeuren? Er werd vermeld 1 april, maar dit blijkt dus niet zo te zijn

Ah natuurlijk niet, dat was ne vis hé.

quistnix schreef: Surfsnelheid hangt uiteraard af van de sync snelheid. Maar in in het beste geval kan je surfen op - wat men noemt - syncrate. Dé beperkende factor is wat er in de BAS is voorzien qua configuratie. In het geval van VDSL2 wordt er naar de login gegevens bekeken in de BAS en die worden dan naar de radius server(s) verstuurd. De radius server bekijkt dan of het paswoord overeenkomt met de login. Als dit juist blijkt, dan wordt de PPP sessie goedkeurd (in het andere geval "rejected") en wordt er een parameter gestuurd naar de BAS die dan het juiste QOS (Quality Of Service) profiel gebruikt.
Bvb. voor een Go (ondertussen Favorite) .... is de werkelijke surfsnelheid in upstream 1,5 Mbit/s en de downstream surfsnelheid 20 Mbit/s.

quitsnix
Dank voor deze begrijpbare uitleg...
Zoals je zegt wordt de surf snelheid bepaald op het niveau van de PPPOE sessie. Als je dus 2 PPPOE sessies draait, neem ik aan dat de beschikbare bandbreedte verdeeld wordt over die 2 sessies: dus max 20 Mbit/s per sessie, beperkt tot 30 Mbit/s voor de 2 sessies samen ??

Wat betreft de werkelijke surfsnelheid:
Hoe komt het dat niemand de 20 / 1.5 Mbit/s haalt, maar maximaal iets van 18.80 Mbits/s download en 1.40 Mbits/s upload? (zie de veel gepubliceerde speedtests).
Het lijkt erop dat de snelheden op een lager niveau geknijpt worden dan de beloofde 20 / 1.5 ?
Ik vind het bedrieglijke reclame om snelheden aan te kondigen die onmogelijk zijn en door niemand gehaald worden.
Bij ADSL kon BGC zich nog verbergen achter de leuze dat dit het maximum is, en afhankelijk is van de lijnafstand, de binnenbekabeling enz. Bij VDSL gaat dit echter niet meer op. Wat is nu de verklaring ?
Als er werkelijk 6% "verloren" gaat (overhead?) dan moeten ze het profiel in de BAS maar verhogen tot 21.2 Mbit/s download en 1.6 Mbits/s upload ??

[EDIT]
Ik wil hier niet echt een polemiek over starten, het verschil tussen 18.80 Mbit/s en 20 Mbit/s is klein (6%) en dus verwaarloosbaar.
Het is meer het principe (wat je belooft moet je waarmaken) - en ik vraag me gewoon af wat de reden is ...

Philippe.

Ja alleen het is nu nog geen 30 mbps he.

Overigens zal er altijd een verschil zijn tussen netto en bruto.

Stel je hebt nu een 20 Mbps profiel, dan heeft een 2e ppp sessie geen zin, behalve mischien voor die kleine 0.5 mbps meer upload.
Zou je een 30 Mbps profiel hebben, dan kun je inderdaad totaal bijna 30 mbps halen, beide PPP sessies zullen dan rond de 14,5 mbps halen

philippe.deleye schreef:Als er werkelijk 6% "verloren" gaat (overhead?) dan moeten ze het profiel in de BAS maar verhogen tot 21.2 Mbit/s download en 1.6 Mbits/s upload ??

En dan gaan ze zagen dat ze maar 20 ipv 21,5Mbit halen.

De overhead gaat volgens mij van de synchro snelheid af niet van het profiel op de bas.

Die 1.5Mbit up klopt ook niet altijd - bij mij is het 18.88down/1.88up (Mbps) en ik ben niet de enige, geloof ik, al zit ik bij Scarlet. De syncs staan op 20/2 voor internet (25/3.1 met TV).

Hoe sneller, hoe meer verspilling, dus van mij hoeft het niet sneller te gaan als de limiet hetzelfde blijft. Ieder videoke/whatever trekt ge volledig binnen tegen de tijd dat je doorhebt dat het stom is (138MB/minuut), en als je durft skippen of refreshen, download je het vaak meerdere keren.

philippe.deleye schreef:Ik wil hier niet echt een polemiek over starten, het verschil tussen 18.80 Mbit/s en 20 Mbit/s is klein (6%) en dus verwaarloosbaar.
Het is meer het principe (wat je belooft moet je waarmaken) - en ik vraag me gewoon af wat de reden is ...

Philippe.

De reden van de overhead van 6 á 7 procent is de omzetting van IP pakketten naar Ethernet frames, PPPOE is PPP Over Ethernet. Overigens is de overhead van ADSL en ADSL2+ die nog over de ATM backbone verloopt (is ondertussen wel zeer miniem geworden door het GENT project (Gigabit Ethernet Network Terminator) nog groter. Dan is de overhead namelijk minstens 10 procent door het feit dat een ATM cel altijd 53 bytes lang is en waar er 48 bytes data zijn, de zogenaamde "payload" en 5 bytes aan header informatie. Zie link. Je kunt die 20 en 1,5 een beetje vergelijken met de waarde van Gigabytes die de fabrikanten opgeven in miljarden i.p.v. de correctere veelvouden van 1024.

philippe.deleye schreef:Als je dus 2 PPPOE sessies draait, neem ik aan dat de beschikbare bandbreedte verdeeld wordt over die 2 sessies: dus max 20 Mbit/s per sessie, beperkt tot 30 Mbit/s voor de 2 sessies samen ??

Als je 2 sessies hebt, dan heb je 2 maal 10 Mbit/s

quistnix schreef:De reden van de overhead van 6 á 7 procent is de omzetting van IP pakketten naar...

Uiteindelijk zal je dat worst wezen als klant... of zou je ook tevreden zijn als je flesje bier 6 a 7% minder bevat dan aangegeven, en je dan een verhaaltje krijgt dat het komt omdat men voor de aflevering het ergens moet omzetten naar flesjes ?

quistnix schreef:Als je 2 sessies hebt, dan heb je 2 maal 10 Mbit/s

Naargelang hoe je dit leest zou je zeggen dat je met een 2de sessie aan te maken plots maar tegen 10 Mbit kan op die sessie (als de andere wel actief is, maar slechts voor een deel belast) maar dat is niet waar.
Uw snelheid die je kan halen met uw pc wordt gedeeld, zoals ze gedeeld zou worden moest je 1 sessie hebben en 3 computers achter een router.

cptKangaroo schreef:Hoe sneller, hoe meer verspilling, dus van mij hoeft het niet sneller te gaan als de limiet hetzelfde blijft. Ieder videoke/whatever trekt ge volledig binnen tegen de tijd dat je doorhebt dat het stom is (138MB/minuut), en als je durft skippen of refreshen, download je het vaak meerdere keren.

Je kan natuurlijk de snelheid op uw pc limiteren en de overschot dan laten voor andere gebruikers ... (als er nog andere gebruikers zijn)

r2504 schreef:

quistnix schreef:De reden van de overhead van 6 á 7 procent is de omzetting van IP pakketten naar...

Uiteindelijk zal je dat worst wezen als klant... of zou je ook tevreden zijn als je flesje bier 6 a 7% minder bevat dan aangegeven, en je dan een verhaaltje krijgt dat het komt omdat men voor de aflevering het ergens moet omzetten naar flesjes ?

En wat als je harde schijf van 500 Giga blijkaar maar 465 Gigabyte is ??

BBB schreef:Naargelang hoe je dit leest zou je zeggen dat je met een 2de sessie aan te maken plots maar tegen 10 Mbit kan op die sessie (als de andere wel actief is, maar slechts voor een deel belast) maar dat is niet waar.
Uw snelheid die je kan halen met uw pc wordt gedeeld, zoals ze gedeeld zou worden moest je 1 sessie hebben en 3 computers achter een router.

Stel, je bent met uTorrent iets aan het binnen halen met een eerste sessie op een PC. Er zijn zeer veel seeders en leechers en je snelheid benaderd de 20 Mb/s. Als je nu op een andere PC een nieuwe sessie maakt en hetzelfde bestand begint te downloaden als op de eerste PC. Wat zal je dan zien ? De snelheid zal na verloop van enige tijd op elke PC ongeveer 10 Mb/s worden. Dit effect van "loadbalancing" komt er eenvoudigweg door het TCP protocol in de TCP/IP stack.

quistnix schreef:Stel, je bent met uTorrent iets aan het binnen halen met een eerste sessie op een PC. Er zijn zeer veel seeders en leechers en je snelheid benaderd de 20 Mb/s. Als je nu op een andere PC een nieuwe sessie maakt en hetzelfde bestand begint te downloaden als op de eerste PC. Wat zal je dan zien ? De snelheid zal na verloop van enige tijd op elke PC ongeveer 10 Mb/s worden. Dit effect van "loadbalancing" komt er eenvoudigweg door het TCP protocol in de TCP/IP stack.

Ja ik heb het misschien niet goed verwoord. Wat ik wilde zeggen is dat je als de ene sessie maar 10 kB/s gebruikt de andere niet op 10 Mbit gaat werken omdat het een tweede sessie is.
De volledige snelheid kan altijd benut worden, waarmee ik wil zeggen dat ze niet automatisch op 10 Mbps wordt afgeknepen omdat het een tweede sessie is.

Volledig mee eens

quistnix schreef:En wat als je harde schijf van 500 Giga blijkaar maar 465 Gigabyte is ??

Dat staat los van overhead, maar heeft gewoon met het gebruik van een andere eenheid te maken.

quistnix schreef: Dit effect van "loadbalancing" komt er eenvoudigweg door het TCP protocol in de TCP/IP stack.

Ah bon ? Heb je hier referenties van ? Volgens mij kan één TCP sessie alles dichttrekken.

quistnix schreef:Je kunt die 20 en 1,5 een beetje vergelijken met de waarde van Gigabytes die de fabrikanten opgeven in miljarden i.p.v. de correctere veelvouden van 1024.

http://nl.wikipedia.org/wiki/Veelvouden_van_bytes

De fabrikant heeft het bij het rechte eind. Zij gebruiken de juiste benaming.

BBB schreef: Ja ik heb het misschien niet goed verwoord. Wat ik wilde zeggen is dat je als de ene sessie maar 10 kB/s gebruikt de andere niet op 10 Mbit gaat werken omdat het een tweede sessie is.
De volledige snelheid kan altijd benut worden, waarmee ik wil zeggen dat ze niet automatisch op 10 Mbps wordt afgeknepen omdat het een tweede sessie is.

Dit is juist zolang de sync 20Mbit/s bedraagt, en zolang je per sessie max 20Mbit/s krijgt.
Maar van zodra de sync omhoog gaat (binnenkort naar 30 Mbit/s), dan zal je nog altijd per sessie max. 20 Mbit/s krijgen (beperkt door de BAS), maar je zoals je zegt de volledige snelheid kan altijd benut worden, met andere woorden: gemiddeld 15 Mbit/s per sessie.
Met één sessie (die beperkt is tot 20 Mbit/s), kan je dan niet de volledige syncsnelheid benutten...

De discussie ging hier niet echt over load balancing, of wat iedere sessie afzonderlijk krijgt, maar hoe je het max. uit de verbinding kan halen (totaal van de sessies)...

Philippe.

r2504 schreef:

quistnix schreef:En wat als je harde schijf van 500 Giga blijkaar maar 465 Gigabyte is ??

Dat staat los van overhead, maar heeft gewoon met het gebruik van een andere eenheid te maken.

Man toch, je enige reacties zijn anti Belgacom. Ik doe mijn best om het een en ander (technisch) duidelijk te maken voor mensen op dit forum. Door mensen als jij zal ik minder om minder dit forum gaan gebruiken (om te helpen), want wat Belgacom ook doet, je zal je gal blijven spuien. Triestig ...

quistnix schreef: Man toch, je enige reacties zijn anti Belgacom. Ik doe mijn best om het een en ander (technisch) duidelijk te maken voor mensen op dit forum. Door mensen als jij zal ik minder om minder dit forum gaan gebruiken (om te helpen), want wat Belgacom ook doet, je zal je gal blijven spuien. Triestig ...

quitsnix
Laat je niet ontmoedigen door wat kritiek op Belgacom, wat je ook doet, die kritiek zal er altijd wel blijven.
Neem dat ook niet te persoonlijk, het is geen commentaar op jou.
Wij appreciëren allemaal de duidelijke technische uitleg die je ons hier geeft. Niet opgeven en kritiek gewoon negeren is de boodschap.
Philippe.

Bedankt man, ik meen het.

VOiD schreef:

quistnix schreef: Dit effect van "loadbalancing" komt er eenvoudigweg door het TCP protocol in de TCP/IP stack.

Ah bon ? Heb je hier referenties van ? Volgens mij kan één TCP sessie alles dichttrekken.

VOiD schreef:

quistnix schreef: Dit effect van "loadbalancing" komt er eenvoudigweg door het TCP protocol in de TCP/IP stack.

Ah bon ? Heb je hier referenties van ? Volgens mij kan één TCP sessie alles dichttrekken.

Ooit al eens een gevordere cursus gevolgd inzake TCP/IP, backbone apparatuur, xDSL sessies ? Blijkbaar niet, het is veel eenvoudiger om iemand met ervaring aan te vallen, Jezus toch ! Referenties ? Geef mij eens een goede referentie om aan te tonen dat ik ongelijk heb !!