obey-robots.txt
22 September 2018, 02:15
Navigatie
Advertentie
data-full-width-responsive="true">
Ledenenquête
XS4ALL, ik wil een herhalende reeks opnames kunnen instellen!

Ja.
Ledenenquête: XS4ALL, ik wil een herhalende reeks opnames kunnen instellen! Ja. 78% [156 stemmen]
78% [156 stemmen]

Nee.
Ledenenquête: XS4ALL, ik wil een herhalende reeks opnames kunnen instellen! Nee. 2% [4 stemmen]
2% [4 stemmen]

Maakt niet uit, ik download het wel van internet.
Ledenenquête: XS4ALL, ik wil een herhalende reeks opnames kunnen instellen! Maakt niet uit, ik download het wel van internet. 6% [13 stemmen]
6% [13 stemmen]

Niet van toepassing.
Ledenenquête: XS4ALL, ik wil een herhalende reeks opnames kunnen instellen! Niet van toepassing. 14% [28 stemmen]
14% [28 stemmen]

Stemmen: 201
U dient in te loggen om te stemmen.
Gestart: 05 jun 2012

Enquête-archief
Inloggen / Registreren
Gebruikersnaam

Wachtwoord


Nog geen lid?
Als geregistreerd lid kunt u reageren en alle extra functies gebruiken.
XS4ALL Gebruikers Groep
Wachtwoord vergeten?
Verzoek nieuw wachtwoord.
Onderwerp bekijken
Alle modems geleverd door XS4ALL, waaronder de FRITZ!Box 7170.
 Nieuw onderwerp  Beantwoorden
 Onderwerp afdrukken

FRITZ!Box 7581 problemen

Marcel
Roger schreef:

Er zit in 6.98-60543 bij DECT-toestellen in de tab Kenmerken van het telefonie-apparaat een schuifregelaar Storingsfilter (zit die niet in 6.85-50446?). Ik heb die nu op Uit gezet bij alle toestellen. Eens kijken wat het oplevert. Goede tip.

Edit: dit lost het probleem helaas niet op (maar veroorzaakt het dus waarschijnlijk ook niet). Instelling weer terug naar het midden.


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?
 
data-full-width-responsive="true">
t541hoo
tubejack schreef:

… De upload wordt niet gecapped, waar zouden ze dat dan moeten doen? In de fritzbox? Think Nehh. Bovendien bij DSL is de upload altijd lager ...



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.wikipe...rol_(data)
 
boobies
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 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.
 
Roger
t541hoo schreef:
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.
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.
Ik snap de hele redenatie niet "Upload niet gecapped"? De ene zijn upload is de andere zijn download.
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).
Waar wordt mijn download dan gecapped.
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 Smile
Speedtouch 510i / FB 7170 / FB 7340 / FB 7581 (6.98-60543 BETA)
 
t541hoo
Roger schreef:

… 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. …



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.
 
RuudvanMunster
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.
 
t541hoo
RuudvanMunster schreef: … 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 ...
Al geprobeerd om na loskoppelen van de 7581 al de instellingen van de apparaten en vermeldingen in het netwerk overzicht in de 7490 weg te halen de 7490 opnieuw op te starten en daarna weer aan de 7581 te koppelen.

Ik zie in de WiFi log van de 7581 trouwens vaak de gegenereerde naam verschijnen ipv de toegekende. En dat voor hetzelfde device soms wel en soms niet. Lijkt me een timing kwestie.
 
Roger
Laborversie 6.98-61351 is beschikbaar: https://download....twicklung/

Via de update functie van de FB is deze versie (nog) niet te zien. Er zitten release notes bij, maar die zijn heel algemeen (dus helaas geen gedetailleerde lijst met verbeteringen).

Edit: Ik verwacht niet dat er veel gewijzigd is sinds 6.98-61289: de bouwdatum is slechts één dag later.
Gewijzigd door Roger op 21 september 2018, 16:19
Speedtouch 510i / FB 7170 / FB 7340 / FB 7581 (6.98-60543 BETA)
 
tubejack
Roger schreef:

Laborversie 6.98-61351 is beschikbaar: https://download....twicklung/

Via de update functie van de FB is deze versie (nog) niet te zien. Er zitten release notes bij, maar die zijn heel algemeen (dus helaas geen gedetailleerde lijst met verbeteringen).

Edit: Ik verwacht niet dat er veel gewijzigd is sinds 6.98-61289: de bouwdatum is slechts één dag later.


Dank je PPP kwam opvallend snel op, na sync Smile
 
RuudvanMunster
t541hoo schreef:

RuudvanMunster schreef: … 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 ...
Al geprobeerd om na loskoppelen van de 7581 al de instellingen van de apparaten en vermeldingen in het netwerk overzicht in de 7490 weg te halen de 7490 opnieuw op te starten en daarna weer aan de 7581 te koppelen.

Ik zie in de WiFi log van de 7581 trouwens vaak de gegenereerde naam verschijnen ipv de toegekende. En dat voor hetzelfde device soms wel en soms niet. Lijkt me een timing kwestie.

Ik wacht even af wat ie doet. Zag dat sommige namen na een aantal uren aangepast waren.
 
data-full-width-responsive="true">
Spring naar forum:
 Nieuw onderwerp  Beantwoorden
Gebruik BBcode of HTML om naar; 'FRITZ!Box 7581 problemen', te verwijzen!
BBcode:
HTML:
Vergelijkbare onderwerpen
Onderwerpen Forum antwoorden Laatste bericht
Fritz!OS 7 Fritzbox 132 21 september 2018, 20:43
FRITZ!Box 5490 DNS server werkt niet Fritzbox 1 21 september 2018, 13:25
Fritzbox 7581 - met OS 7 - voor WLAN Mesh Fritzbox 20 21 september 2018, 12:46
Fritzbox 7581 bridge mode Algemeen 8 17 september 2018, 22:44
downloaden event log 7581/7360 Fritzbox 1 13 september 2018, 18:42
Goedenacht bezoeker
FritzBox info
FritzBox infohttps://fritzbox-info.nl/
Inloggen / Registreren
Gebruikersnaam

Wachtwoord



Nog geen lid?
Als geregistreerd lid kunt u reageren en alle extra functies gebruiken.

Wachtwoord vergeten?
Verzoek nieuw wachtwoord.
Laatst geziene leden
| chefke01:14:00
| Gondelier02:11:58
| meppele02:15:43
| rhuijben02:32:13
| GladiusMaximus02:35:41
| Access02:48:35
| lsluijter03:06:02
| noord45303:08:58
| timr201803:13:53
| richard0103:24:57
Shoutbox
U moet ingelogd zijn om een bericht te plaatsen.

15 september 2018, 01:06
test

19 januari 2018, 08:44
Internet&telefoon weer down sinds ca 7:45 in Zwolle, anderen ook?

24 december 2017, 11:47
Is er een snelcode om de Fritzbox 7581 automatisch te herstarten ?

20 december 2017, 13:56
Melding in FB: DNS error.

20 december 2017, 13:53
Geen internet in Den Hoorn, Achterdijkshoorn 30 (2635 MK). En storingsnummer neemt niet op.