In de BRAS van de provider wordt gewoon een profiel ingesteld. Ook al heb je 200mb download met een compact abonnement krijg je waar voor je betaald 50mb. De upload wordt niet gecapped, waar zouden ze dat dan moeten doen? In de fritzbox? Nehh. Bovendien bij DSL is de upload altijd lager

mijn BVVDSL lijn doet 220/60

Top

De mijne BVDSL 40/4. Tot waarschijnlijk 2023. Toch is mijn webserver en website over deze lijn razend snel.
Ik vind het wel prima zo, alles werkt

Ja. Mits de FB weet wat de beschikbare/toegestane bandbreedte is. Daar is alleen geen standaard mechanisme voor. Volgende deze post op het Duitse IP Phone Forum communiceren sommige Duitse providers (o.a. Deutsche Telekom en 1und1) de bandbreedte in het Message veld van het PPP Authenticate-Ack packet en gebruikt de Fritz!Box die ook (in elk geval bepaalde modellen).

Edit: uiteraard is dit geen harde cap. Die wordt gedaan aan de kant van de provider. Maar het helpt de FB om geen data te sturen die vederop in de traffic shaper van de provider wordt vermalen. Dat is van groot belang als je QoS goed wilt doen.

Also je nu die een op maximaal zet?

Ik ben wel bang dat het niet in DECT en AVM heeft nooit aangegeven wat nu precies in de Plus versie hebben aangepast of heb ik dat gemist?

Ik snap de hele redenatie niet "Upload niet gecapped"? De ene zijn upload is de andere zijn download. Waar wordt mijn download dan gecapped.

Kijk ik kan er in komen wanneer je zegt dat de maximale doorvoersnelheid richting centrale/gateway provider niet gecapped wordt. Maar bij die gateway of snel daarna zal het dmv buffering en druppel, druppel door het kraantje van de provider snel afgelopen zijn. Maar mijn Speedtest.net meet gewoon al jaren 10Mb up terwijl dat voor de snelheidsverhoging naar 40/5 slechts 2Mb up had hoeven zijn.

En wat heeft het voor Xs4all voor een zin om een 20/2 verbinding aan te bieden terwijl het in wekelijkheid een 20/10 is. Commercieel niet slim zou ik zo zeggen.

Hier staat ongetwijfeld het mechanisme in dat ik bedoel. Maar ik heb geen zin om het door te vlooien. https://en.wikipedia.org/wiki/Flow_co...rol_(data)

Hier zit het 'm in; van te voren weet XS4ALL niet wat ze kunnen verwachten qua uploadsnelheid. XS garandeert meestal een tiende van de downloadsnelheid op DSL. als ik mijn adres in de postcodecheck gooi, staat er ook 200 down 20 up, maar ik haal 60 up.



wat ik bedoel met ""niet gecapped" is dat XS4ALL, als het om DSL gaat, geen uploadsnelheden handhaaft per abonnement.

Commercieel misschien niet, juridisch wel: mocht je ooit om de een of andere reden de upload willen gaan afknijpen op het contractuele niveau, dan blijf je leveren wat je beloofd hebt. Maar waarom wordt dan alleen de download gecapped? Simpelweg omdat het gebruik van een consumentenverbinding vrijwel altijd nog asymmetrischer is dan het contract. Het loont gewoon de moeite (en dus de kosten) niet om dat in te regelen.
Nog even afgezien van packet loss, geldt dat alleen voor een gesloten systeem. De wereld als geheel dus. XS4ALL zal op zijn peerings veel meer ingress verkeer (met grote bronnen als NPO, Netflix en Youtube) hebben dan egress verkeer. En dan moet je natuurlijk ook nog naar de servers binnen het XS4ALL netwerk kijken (met name de televisie servers).
In de BRAS van XS4ALL. Bij het opzetten van de PPPoE sessie weet de BRAS wat de parameters van jouw contract zijn en configureert daarmee de traffic shaper voor jouw sessie. XS4ALL zou daar ook je upload kunnen cappen, maar dat loont zoals ik al zei de moeite niet. En als ze het wel zouden doen, dan zouden ze ook weer de maximale datarate op de DSLAM eraan moeten koppelen (zo ging het vroeger ook). Anders gaat het CPE (jouw modem) meer data sturen dan de BRAS accepteert met packet loss als gevolg. Upload niet cappen als daar geen noodzaak voor is, is eenvoudiger en goedkoper. En als de klant meer krijgt dan hij verwacht, is de klant tevreden. Win-win, heet dat

Juridisch kan geen probleem zijn. ISP's geven al jaren een maximum aan voor de download. En ik ben er niet eens zeker van dat de term "maximum" ook niet al op de upload slaat.

Mijn grote bezwaar blijft bestaan tegen het feit dat wordt aangevoerd dat cappen "packet loss" tot gevolg heeft.

"Packet loss" is een "zachte" netwerkfout. "Zacht" met het oog op het feit dat het internet/netwerk is ingericht om dergelijke fouten zelfstandig op te lossen. "Packet loss" kan bijvoorbeeld ontstaan doordat de route waarop een packet verstuurd wordt down kan gaan of dat er anderszins niet meer voor de integriteit van een packet kan worden ingestaan. De oplossing is dan om het packet opnieuw te sturen. Dat is een "dure" maatregel want het levert extra netwerk verkeer op. Vandaar dat dit absoluut niet de manier is om te knijpen. Dat opnieuw versturen hoeft trouwens niet te betekenen dat ik opnieuw moet sturen. Een node upstream van het probleem kan het pakket nog in de cache hebben en tevens aangesloten zijn op een alternatieve route naar het doel. En daarnaast knijpen gebeurt voortdurend. Bijvoorbeeld wanneer ik met mijn 10Mb up iets aan het sturen ben naar een ontvanger die al full speed iets aan het ontvangen is of sowieso een lagere downloadsnelheid aan kan/toestaat.

Het knijpen/"throttelen" van een verbinding gebeurt door heel andere mechanismen in het netwerk, zoals doordat de "ontvangende kant"/"node op de route" aangeeft even geen pakketten meer te willen ontvangen of het tijdelijk bufferen (negatief knijpen) etc.

Het kan voor Xs4all om diverse redenen handig zijn om hogere snelheden toe te staan:
- het draadje ligt er toch en kan het aan
- er is sprake van tijdelijke overcapaciteit verderop in het netwerk
- de bijna 100% wetenschap dat het verkeer er toch komt en dan maar beter gelijk nu omdat er capaciteit is.

Kortom er is Xs4all alles aangelegen om hun eigen stuk van de route zo efficient mogelijk te benutten. Ze zijn mijn pakketten liever kwijt dan rijk. Maar juist dit feit heeft tevens tot gevolg dat "throttelen" noodzakelijk is. Hun eigen netwerk is namelijk 24/7 maximaal uitgenut en pieken moeten dus noodzakelijkerwijs onderdrukt worden. En "packet loss" maakt dat probleem alleen maar erger.

Dus NEE, knijpen heeft geen "packet loss" tot gevolg. Het netwerk zou daar uiterst onstabiel door worden.

Overigens spreek je je in het citaat ook nog tegen. (" … om de een of andere reden de upload willen gaan afknijpen … " ). Knijpen is nu volgens jou dus ineens wel aan de orde.

Vandaag heeft de 7490 die ik achter mijn 7581 gebruik voor DECT en WIFI zijn update naar Fritz!OS 7.01 gehad. Op zich verliep de update vlekkeloos. DECT lijkt nog gewoon te werken na de update. WIFI heeft wel een probleempje. De 7490 geeft de devices nu namen in de stijl van PC-192-168-178-131 i.p.v. de in de 7581 toegekende logischer namen als iPhoneRuud. Dus de naadloze samenwerking tussen 7581 en 7490 lijkt iets minder naadloos te zijn geworden. Ik ben wel benieuwd of de 7581 nu snel volgt.