[Ziggo] Ervaringen Topic - Deel 9

[stormfly]

Anoniem: 757487 schreef op zaterdag 16 april 2016 @ 22:40:
De T4 schiet wel uit zijn slof...kan iemand mij uitleggen wat dat inhoud?


Upstream Bonded Channels

Channel Lock Status US Channel Type Symbol Rate Frequency Power
1 Locked ATDMA 5120 Ksym/sec 36000000 Hz 51.0 dBmV
2 Locked ATDMA 5120 Ksym/sec 52000000 Hz 51.0 dBmV
3 Locked ATDMA 5120 Ksym/sec 44500000 Hz 51.0 dBmV
4 Locked ATDMA 5120 Ksym/sec 58800000 Hz 51.0 dBmV


Counter

T3 Timeout 0
T4 Timeout 2086

Jouw kabel is niet goed je Upstream waarde is hoog waardoor je T4 meldingen krijgt. Er zullen pakketen verloren gaan neem ik aan als de monteur dit in zijn kabelmeting ziet.

Nu afwachten tot de kabel vervangen is en dan nog eens goed naar je Upstream waardes kijken, ik ben benieuwd!

[ Voor 5% gewijzigd door stormfly op 17-04-2016 08:02 ]

[ANdrode]

Anoniem: 757487 schreef op zaterdag 16 april 2016 @ 22:40:
Nu ging hij even met zijn meet apparatuur de groene kabel meten en warempel zag hij op een afstand van 3 meter 80 van het AOP een uitschieter op de lijn die gewoon strak moet zijn. Er is nu afgesproken dat ze de kabel gaan vervangen tot aan die uitschieter en dan moet het probleem opgelost zijn. Duimen maar weer.

Een buiten monteur . Daar heb ik ook goede ervaringen mee.

Die meter (gele koffer, klassiek B/W LCD scherm?) kijkt naar reflecties tussen jouw huisaansluiting en de straatkast. In de straatkast zit dan ook een speciaal apparaat aangesloten.

Monteur was geweldig en daar was ik al superblij mee. Hieronder nog even de waardes na de vervanging van het AOP. De T4 schiet wel uit zijn slof...kan iemand mij uitleggen wat dat inhoud?

....

T4 Timeout 2086

Een T4 timeout is niet goed en betekent in de praktijk dat je een aantal seconden geen verbinding hebt. Is het modem gereset sinds de monteur er was/hij even geen signaal had?

[ArChie]

Anoniem: 757487 schreef op zaterdag 16 april 2016 @ 22:40:
Gelukkig na vervanging was het nog niet perfect maar wel weer verbetering van de waardes in mijn modem. Nu ging hij even met zijn meet apparatuur de groene kabel meten en warempel zag hij op een afstand van 3 meter 80 van het AOP een uitschieter op de lijn die gewoon strak moet zijn. Er is nu afgesproken dat ze de kabel gaan vervangen tot aan die uitschieter en dan moet het probleem opgelost zijn. Duimen maar weer. Monteur was geweldig en daar was ik al superblij mee. Hieronder nog even de waardes na de vervanging van het AOP. De T4 schiet wel uit zijn slof...kan iemand mij uitleggen wat dat inhoud?

Ik hoop wel dat je je de volgende zaken realiseert:
- Je zit momenteel weer op DOCSIS downstream frequentie set 2 (242 MHz - 298 MHz) in jouw coaxsegment die eerder ook al een verbetering liet zien t.o.v. frequentie set 1 (178 MHz - 234 MHz) aangezien die eerste frequentie set je modem nogal een probleem heeft met de internet downstream op 226 MHz. De kans bestaat dat je na een eerst volgende harde reset weer in frequentie set 1 terechtkomt vanwege de loadbalancing van de CMTS waardoor je weer een verslechtering zal krijgen;
- Het benodigde upstream vermogen nog steeds te hoog is waardoor de kans bestaat dat je weer terugvalt naar één upstream i.p.v. vier upstreams;
- Je binnenkomend signaal is nog steeds van slechte kwaliteit gezien het groot aantal Correctables/Uncorrectables;
- T3/T4 waarden horen niet zo hoog te zijn.

Gezien de informatie die je modem verstrekt over de signaal kwaliteit kan ik het qua resultaat dus nauwelijks een verbetering noemen. Vermoedelijk zal je ook nog steeds oplopende BER waarden hebben op de frequenties die gebruikt worden voor digitale RTV doorgifte wat resulteert in blokjes door ontbrekende MPEG data omdat de DVB-C tuner af en toe geen kaas kan maken van het binnenkomende signaal.

Voor het DOCSIS internet zou ik je normaal adviseren om je modem een harde reset te geven en in de gaten te houden of die Correctables/Uncorrectables en T3/T4 waarden nog steeds blijven oplopen als je verder niet meer aan de bekabeling rommelt, maar in jouw geval bestaat dan de kans dat je dan weer in frequentie set 1 terecht komt die waarschijnlijk zorgt voor een nog slechter resultaat. Je kan dus maar beter hopen dat ze snel die kabel repareren.

Voor de volledigheid nog de informatie van Volpe over de T4 timeouts:

T4 Timeout ( Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received )

Explanation: The cable modem did not received a station maintenance opportunity in which to transmit a Ranging Request (RNG-REQ) message within the T4 timeout period (30 to 35 seconds). The cable modem is resetting its cable interface and restarting the registration process. Typically, this indicates an occasional, temporary loss of service, but if the problem persists, check for possible service outages or maintenance activity on this particular headend system. This error message is DOCSIS event message is R04.0, Ranging Request.

[ArChie]

stormfly schreef op zondag 17 april 2016 @ 08:02:
Er zullen pakketen verloren gaan neem ik aan als de monteur dit in zijn kabelmeting ziet.

Ik denk dat je te veel van de kennis en kunde van de Ziggo/UPC monteurs verwacht. Na een node spiltsing om het coaxsegment te verkleinen werden we wekenlang als gevolg van regelmatig veel corrupte packets op alle digitale RTV transport streams met onderstaand beeld geconfronteerd:



En op de DOCSIS downstreams ook veel missing packets. Ziggo/UPC kon niets vinden, want de signaal sterkte was volgens hun metertjes in orde. Werd door een monteur uiteindelijk toegeschreven aan een niet lekkere glasvezel verbinding in het wijkcentrum, maar het geeft je te denken als ze dergelijk grote hoeveelheden packet corruptie op alle digitale RTV en DOCSIS frequenties niet eens kunnen waarnemen na de controle van hun eigen werkzaamheden. En dit was niet de eerste keer dat deze provider de mist in ging door onderhoudswerkzaamheden. Alle grote storingen die ik hier gehad heb sinds ik klant ben van Multikabel, Zesko (Casema/Multikabel), Ziggo (@Home/Casema/Multikabel en Ziggo/UPC waren telkens weer het gevolg van onderhoud en monteurs die niet in staat bleken te zijn om het signaal na hun eigen werkzaamheden te controleren.

Het is overigens nog steeds niet 100% in orde hier na die node splitsing, maar je wordt al bang als Ziggo/UPC weer onderhoud aankondigt of wanneer je weer een busje van Ziggo/UPC in de straten ziet rondrijden. Langdurige metingen van Ziggo/UPC zelf hebben niets opgeleverd, maar ze zagen ook niet die grote hoeveelheden corrupte packets. We moeten er dus maar mee leren leven.

[commentator]

Iemand een suggestie waar in de technicolor TC7210 die t3/t4 meldingen te vinden zijn?
In Cisco staat het netjes op de pagina waar ook:
Downstream Channel

Channel Lock Status Modulation Channel ID Symbol Rate Frequency Power SNR

1 Locked QAM256 11 6952000 308000000 Hz 4.8 dBmV 40.2 dB

2 Locked QAM256 1 6952000 228000000 Hz 5.5 dBmV 40.3 dB

3 Locked QAM256 2 6952000 236000000 Hz 5.1 dBmV 40.2 dB

4 Locked QAM256 3 6952000 244000000 Hz 4.8 dBmV 40.1 dB

5 Locked QAM256 4 6952000 252000000 Hz 4.8 dBmV 40.0 dB

6 Locked QAM256 5 6952000 260000000 Hz 4.8 dBmV 40.2 dB

7 Locked QAM256 6 6952000 268000000 Hz 4.9 dBmV 39.2 dB

8 Locked QAM256 7 6952000 276000000 Hz 4.9 dBmV 40.2 dB

9 Locked QAM256 8 6952000 284000000 Hz 4.9 dBmV 40.2 dB

10 Locked QAM256 9 6952000 292000000 Hz 4.9 dBmV 40.2 dB

11 Locked QAM256 10 6952000 300000000 Hz 4.9 dBmV 40.2 dB

12 Locked QAM256 12 6952000 316000000 Hz 4.8 dBmV 40.2 dB

13 Locked QAM256 13 6952000 324000000 Hz 4.8 dBmV 40.2 dB

14 Locked QAM256 14 6952000 332000000 Hz 4.7 dBmV 40.0 dB

15 Locked QAM256 15 6952000 340000000 Hz 4.8 dBmV 35.8 dB

16 Locked QAM256 16 6952000 348000000 Hz 4.8 dBmV 40.1 dB

Upstream Channel

Channel Lock Status Modulation Channel ID Symbol Rate Frequency Power

1 Locked QAM64 2 5120 Ksym/sec 44500000 Hz 40.0 dBmV

2 Locked QAM64 1 5120 Ksym/sec 52000000 Hz 40.5 dBmV

3 Locked QAM64 3 5120 Ksym/sec 36000000 Hz 39.0 dBmV

4 Locked QAM64 4 5120 Ksym/sec 58800000 Hz 41.0 dBmV

[Jim423]

ArChie schreef op zondag 17 april 2016 @ 11:55:
[...]En op de DOCSIS downstreams ook veel missing packets. Ziggo/UPC kon niets vinden, want de signaal sterkte was volgens hun metertjes in orde. Werd door een monteur uiteindelijk toegeschreven aan een niet lekkere glasvezel verbinding in het wijkcentrum, maar het geeft je te denken als ze dergelijk grote hoeveelheden packet corruptie op alle digitale RTV en DOCSIS frequenties niet eens kunnen waarnemen na de controle van hun eigen werkzaamheden. En dit was niet de eerste keer dat deze provider de mist in ging door onderhoudswerkzaamheden. Alle grote storingen die ik hier gehad heb sinds ik klant ben van Multikabel, Zesko (Casema/Multikabel), Ziggo (@Home/Casema/Multikabel en Ziggo/UPC waren telkens weer het gevolg van onderhoud en monteurs die niet in staat bleken te zijn om het signaal na hun eigen werkzaamheden te controleren.

Het is overigens nog steeds niet 100% in orde hier na die node splitsing, maar je wordt al bang als Ziggo/UPC weer onderhoud aankondigt of wanneer je weer een busje van Ziggo/UPC in de straten ziet rondrijden. Langdurige metingen van Ziggo/UPC zelf hebben niets opgeleverd, maar ze zagen ook niet die grote hoeveelheden corrupte packets. We moeten er dus maar mee leren leven.

Wanneer dit vaak optreedt moet dit gewoon te vinden zijn. DOCSIS is een ander verhaal maar RTV mits met regelmaat aanwezig is zelfs met een fieldservicemeter gewoon te vinden. Gewoon blijven klagen uiteindelijk moeten ze wel hogerop gaan kijken. Wanneer het echt aan de nodesplitsing ligt dan zou het kunnen zijn dat er een probleem in de glasvezel ligt maar de monteur moet dan ook gewoon kunnen aangeven wat de vervolgactie wordt. Eerder ligt het probleem in de zender/ontvanger hub/wijk of de bekabeling hiernaartoe. De tijdmeting zal echt uitgevoerd moeten worden met een meter in de wijk of nog beter bij jou thuis is dit gebeurd of ''op afstand''?

[rick77]

commentator schreef op zondag 17 april 2016 @ 12:04:
Iemand een suggestie waar in de technicolor TC7210 die t3/t4 meldingen te vinden zijn?

T3/T4 errors zijn te vinden in het Event log: http://192.168.178.1/RgEventLog.asp

Correctables/uncorrectables zijn niet te vinden op de TC7210.

[garp]

Heb je toevallig sinds je dit issue hebt een chromecast aan je TV hangen, of in de buurt van je TV? Zo ja, trek de (voeding) van de chromecast er eens een tijdje uit en kijk dan hoe het gaat. Die krengen storen op o.a. RTL4 en Veronica, maar ook op een aantal andere zenders (blijkbaar).

Heb je geen chromecast dan heb ik niets gezegd.....

Heb hier 2 monteurs gehad recentelijk en alles was na hun werkzaamheden perfect. Nieuw AOP, Kabel opnieuw aangesloten (zat maar met 1 sliertje van de mantel aan het AOP gemonteerd, heeft jarenlang perfect gewerkt). Bleek uiteindelijk de chromecast het issue te zijn. Die stoort op de digitale ontvanger....

ArChie schreef op zondag 17 april 2016 @ 11:55:
[...]


Ik denk dat je te veel van de kennis en kunde van de Ziggo/UPC monteurs verwacht. Na een node spiltsing om het coaxsegment te verkleinen werden we wekenlang als gevolg van regelmatig veel corrupte packets op alle digitale RTV transport streams met onderstaand beeld geconfronteerd:
[afbeelding]
[afbeelding]

En op de DOCSIS downstreams ook veel missing packets. Ziggo/UPC kon niets vinden, want de signaal sterkte was volgens hun metertjes in orde. Werd door een monteur uiteindelijk toegeschreven aan een niet lekkere glasvezel verbinding in het wijkcentrum, maar het geeft je te denken als ze dergelijk grote hoeveelheden packet corruptie op alle digitale RTV en DOCSIS frequenties niet eens kunnen waarnemen na de controle van hun eigen werkzaamheden. En dit was niet de eerste keer dat deze provider de mist in ging door onderhoudswerkzaamheden. Alle grote storingen die ik hier gehad heb sinds ik klant ben van Multikabel, Zesko (Casema/Multikabel), Ziggo (@Home/Casema/Multikabel en Ziggo/UPC waren telkens weer het gevolg van onderhoud en monteurs die niet in staat bleken te zijn om het signaal na hun eigen werkzaamheden te controleren.

Het is overigens nog steeds niet 100% in orde hier na die node splitsing, maar je wordt al bang als Ziggo/UPC weer onderhoud aankondigt of wanneer je weer een busje van Ziggo/UPC in de straten ziet rondrijden. Langdurige metingen van Ziggo/UPC zelf hebben niets opgeleverd, maar ze zagen ook niet die grote hoeveelheden corrupte packets. We moeten er dus maar mee leren leven.

[ Voor 9% gewijzigd door garp op 17-04-2016 18:43 ]

[Anoniem: 757487]

Klopt dat de BER omhoog gaat en dan vooral op de zender van TV WEST. Monteur vertelde mij ook dat de echte verbetering en oplossing van mijn probleem pas echt is verholpen als ze vanuit mijn voortuin de kabel doorknippen en dan een nieuwe kabel erop lassen die dan weer via de voorgevel naar binnen wordt gevoerd en op mijn AOP aangesloten wordt. Ik heb geen harde reset meer gedaan nadat de monteur wegging. Ik wacht de vernieuwing van de kabel af en hoop dan echt dat ik van alle shit verlost ben. De verbetering bedoelde ik mee dat de downstream nr 7 nu wel op locked stond en de waardes van de power ook sterk veranderd waren. Monteur zei ook dat het nog helemaal niet top was maar dat dat na de vernieuwing van de kabel wel zal zijn.


Downstream Bonded Channels

Channel Lock Status Modulation Frequency Power SNR Microreflections
1 Locked QAM256 242000000 Hz -0.6 dBmV 41.3 dB -32 dBc
2 Locked QAM256 250000000 Hz 0.0 dBmV 41.5 dB -29 dBc
3 Locked QAM256 258000000 Hz -0.9 dBmV 40.9 dB -32 dBc
4 Locked QAM256 266000000 Hz -0.7 dBmV 40.8 dB -27 dBc
5 Locked QAM256 274000000 Hz 0.4 dBmV 41.3 dB -24 dBc
6 Locked QAM256 282000000 Hz 0.3 dBmV 41.3 dB -29 dBc
7 Locked QAM256 290000000 Hz 0.9 dBmV 41.8 dB -27 dBc
8 Locked QAM256 298000000 Hz -0.5 dBmV 40.8 dB -32 dBc


Correctables Uncorrectables
4901233 1478


Upstream Bonded Channels

Channel Lock Status US Channel Type Symbol Rate Frequency Power
1 Locked ATDMA 5120 Ksym/sec 36000000 Hz 51.0 dBmV
2 Locked ATDMA 5120 Ksym/sec 52000000 Hz 51.0 dBmV
3 Locked ATDMA 5120 Ksym/sec 44500000 Hz 51.0 dBmV
4 Locked ATDMA 5120 Ksym/sec 58800000 Hz 51.0 dBmV


Counter

T3 Timeout 0
T4 Timeout 6468

ArChie schreef op zondag 17 april 2016 @ 11:31:
[...]

Ik hoop wel dat je je de volgende zaken realiseert:
- Je zit momenteel weer op DOCSIS downstream frequentie set 2 (242 MHz - 298 MHz) in jouw coaxsegment die eerder ook al een verbetering liet zien t.o.v. frequentie set 1 (178 MHz - 234 MHz) aangezien die eerste frequentie set je modem nogal een probleem heeft met de internet downstream op 226 MHz. De kans bestaat dat je na een eerst volgende harde reset weer in frequentie set 1 terechtkomt vanwege de loadbalancing van de CMTS waardoor je weer een verslechtering zal krijgen;
- Het benodigde upstream vermogen nog steeds te hoog is waardoor de kans bestaat dat je weer terugvalt naar één upstream i.p.v. vier upstreams;
- Je binnenkomend signaal is nog steeds van slechte kwaliteit gezien het groot aantal Correctables/Uncorrectables;
- T3/T4 waarden horen niet zo hoog te zijn.

Gezien de informatie die je modem verstrekt over de signaal kwaliteit kan ik het qua resultaat dus nauwelijks een verbetering noemen. Vermoedelijk zal je ook nog steeds oplopende BER waarden hebben op de frequenties die gebruikt worden voor digitale RTV doorgifte wat resulteert in blokjes door ontbrekende MPEG data omdat de DVB-C tuner af en toe geen kaas kan maken van het binnenkomende signaal.

Voor het DOCSIS internet zou ik je normaal adviseren om je modem een harde reset te geven en in de gaten te houden of die Correctables/Uncorrectables en T3/T4 waarden nog steeds blijven oplopen als je verder niet meer aan de bekabeling rommelt, maar in jouw geval bestaat dan de kans dat je dan weer in frequentie set 1 terecht komt die waarschijnlijk zorgt voor een nog slechter resultaat. Je kan dus maar beter hopen dat ze snel die kabel repareren.

Voor de volledigheid nog de informatie van Volpe over de T4 timeouts:

[...]

[ArcticWolf]

Anoniem: 757487 schreef op zondag 17 april 2016 @ 18:29:
*knip*

Counter

T3 Timeout 0
T4 Timeout 6468


[...]

Ik zou toch even een factory reset uitvoeren @ modem met die waardes... met zoveel T4 timeouts kun je toch niet normaal internetten?

[Anoniem: 757487]

Het blijft een vreemde situatie maar met internetten totaal geen probleem. Speedtest is ook nog steeds 200/20

ArcticWolf schreef op zondag 17 april 2016 @ 19:11:
[...]

Ik zou toch even een factory reset uitvoeren @ modem met die waardes... met zoveel T4 timeouts kun je toch niet normaal internetten?

[ArChie]

Jim423 schreef op zondag 17 april 2016 @ 13:09:
Wanneer dit vaak optreedt moet dit gewoon te vinden zijn.

Lijkt mij ook, maar de realiteit blijkt anders.

DOCSIS is een ander verhaal maar RTV mits met regelmaat aanwezig is zelfs met een fieldservicemeter gewoon te vinden.

DOCSIS en digitale RTV maken beide gebruik van DVB-C voor de doorgifte van transport streams, dus ik zie het verschil niet qua mogelijke onderzoeksmethoden voor een slecht signaal.

Een voorbeeld van een digitale RTV transport stream waarbij DVB-C gebruikt wordt:


En een voorbeeld van een DOCSIS downstream waarbij DVB-C gebruikt wordt:


In beide gevallen leiden niet herstelbare packets tot missing packets waardoor de ontvanger niet in de gelegenheid is om de data te reconstrueren zoals door de verzender werd doorgegeven via de stream. Digitale RTV rapporteert dat als BER en DOCSIS als Correctables/Uncorrectables.

Gewoon blijven klagen uiteindelijk moeten ze wel hogerop gaan kijken.

Dat is uiteraard gedaan inclusief mail aan de CTO.

Wanneer het echt aan de nodesplitsing ligt dan zou het kunnen zijn dat er een probleem in de glasvezel ligt maar de monteur moet dan ook gewoon kunnen aangeven wat de vervolgactie wordt.

De problemen begonnen na destijds het aangekondigde onderhoud voor kabel internet en uiteraard heb ik persoonlijk vastgesteld dat het om node splitsing ging aangezien het aantal kabelmodems met een derde verminderd was na dat onderhoud en de missing packets met grote aantallen binnenkwamen. Gezien de vele hardnekkige storingsmeldingen op de Ziggo site voor mijn postcode was ik zeker niet de enige die problemen ervaarde na dit onderhoud en uiteraard stopte dat allemaal nadat ik uiteindelijk van een monteur te horen kreeg dat een glasvezel verbinding de oorzaak was. Toen waren we al een paar weken verder met aanhoudende klachten.

De tijdmeting zal echt uitgevoerd moeten worden met een meter in de wijk of nog beter bij jou thuis is dit gebeurd of ''op afstand''?

Heeft destijds allemaal plaatsgevonden door verschillende monteurs. Omdat de storingen die keer zeer hardnekkig bleven aanhouden heb ik toen ook bij wijze van uitzondering ook tijd vrijgemaakt om een monteur aan huis te laten meten. Onnodig natuurlijk want ook bij Ziggo had toen gezien het groot aantal storingsmeldingen bekend moeten zijn dat de oorzaak lag bij de uitgevoerde onderhoudswerkzaamheden in de wijk. Hoeveel keer moet je klanten lastig vallen terwijl je natuurlijk ook in de wijk met wat meetapparatuur kan vaststellen dat de te verzenden data corrupt is. Garbage in is garbage out.

Ik heb het uiteindelijk maar opgegeven. Ik heb als hobbyist helaas geen tooling die exact de tijdstippen kan registreren waarop het signaal dusdanig corrupt is dat er sprake is van missing packets zodat de monteur(s) dat aan hun eigen metingen zouden kunnen relateren. Helaas hier dus niet meer dezelfde signaal kwaliteit als voor die node spiltsing.

[ArChie]

garp schreef op zondag 17 april 2016 @ 18:29:
Heb je toevallig sinds je dit issue hebt een chromecast aan je TV hangen, of in de buurt van je TV? Zo ja, trek de (voeding) van de chromecast er eens een tijdje uit en kijk dan hoe het gaat. Die krengen storen op o.a. RTL4 en Veronica, maar ook op een aantal andere zenders (blijkbaar).

Heb je geen chromecast dan heb ik niets gezegd.....

Nee, hier geen Chromecast. Zoals eerder aangegeven was de oorzaak van bovenstaand beeld op alle kanalen een niet goed gelukte nodesplitsing waarbij er iets mis was gegaan met de glasvezel.

[Anoniem: 757487]

De waardes na een reset...us lampje brandt weer BLAUW...


Docsis
This page displays the docsis information.


Startup Procedure

Acquired Downstream Status Completed
Upstream Ranging Status Completed
Docsis DHCP Status Completed
Docsis TFTP Status Completed
Docsis TOD Status Completed
Security Status Enabled / BPI+


Downstream Bonded Channels

Channel Lock Status Modulation Frequency Power SNR Microreflections
1 Locked QAM256 178000000 Hz -2.3 dBmV 35.6 dB -11 dBc
2 Locked QAM256 186000000 Hz -2.0 dBmV 37.5 dB -33 dBc
3 Locked QAM256 194000000 Hz -2.5 dBmV 37.7 dB -33 dBc
4 Locked QAM256 202000000 Hz -2.4 dBmV 37.8 dB -28 dBc
5 Locked QAM256 210000000 Hz -1.5 dBmV 39.3 dB -32 dBc
6 Locked QAM256 218000000 Hz -0.9 dBmV 39.9 dB -31 dBc
7 Locked unknown 226000000 Hz -1.2 dBmV 0.0 dB -0 dBc
8 Locked QAM256 234000000 Hz -1.8 dBmV 41.4 dB -31 dBc


Correctables Uncorrectables
6383 45


Upstream Bonded Channels

Channel Lock Status US Channel Type Symbol Rate Frequency Power
1 Locked ATDMA 5120 Ksym/sec 44500000 Hz 57.0 dBmV
2 Not Locked Unknown 0 Ksym/sec 0 Hz 0.0 dBmV
3 Not Locked Unknown 0 Ksym/sec 0 Hz 0.0 dBmV
4 Not Locked Unknown 0 Ksym/sec 0 Hz 0.0 dBmV


Counter

T3 Timeout 0
T4 Timeout 0

ArcticWolf schreef op zondag 17 april 2016 @ 19:11:
[...]

Ik zou toch even een factory reset uitvoeren @ modem met die waardes... met zoveel T4 timeouts kun je toch niet normaal internetten?

[Dzine]

Sinds een aantal dagen een slechte verbinding, waar al een jaar prima ging met de Ubee EVW321B in bridge en Airport Extreme / TC als eindbaas.

Ik lees iets over upgrades van de Ubee en ik wil even checken of alles OK staat, maar via 192.168.178.1 of 192.168.100.1 kan ik hem niet bereiken (via wifi). Andere adressen/ideeen?

[ArChie]

Anoniem: 757487 schreef op zondag 17 april 2016 @ 21:28:
De waardes na een reset...us lampje brandt weer BLAUW...

Je modem is weer terug gezet op frequentie set 1. Zoals verwacht geeft dat problemen met de downstream op 226 MHz. Ook moet het modem wat meer vermogen voor de upstream aanwenden waardoor er drie uitgeschakeld worden.

[Jerrythafast]

Dzine schreef op zondag 17 april 2016 @ 21:33:
Sinds een aantal dagen een slechte verbinding, waar al een jaar prima ging met de Ubee EVW321B in bridge en Airport Extreme / TC als eindbaas.

Ik lees iets over upgrades van de Ubee en ik wil even checken of alles OK staat, maar via 192.168.178.1 of 192.168.100.1 kan ik hem niet bereiken (via wifi). Andere adressen/ideeen?

Kabel van laptop of PC in de LAN1 poort prikken en nog eens proberen?

[Baldertt]

Hier waren er afgelopen vrijdag ook problemen. Ik had de laatste maanden wel af en toe dat het signaal van de modem wegviel, maar na een reset deed ie het dan altijd wel weer. Afgelopen vrijdag bleven de lampjes (DS en US) blauw.

Na een nietszeggend gesprek met de klantenservice ("is de modem goed aangesloten?") is er een monteur langsgeweest en die heeft de groene kabel opnieuw gestript en de wanddoos vervangen. Het signaal ging van -5 dBmV naar +7dBmV en TV signaalsterkte van rond de 30% naar >50% met BER waarde strak op 0. Internetverbinding is een stuk stabieler nu (speedtest geeft iedere keer continue snelheid tjidens de test van 41.2mbps down en 4.2mbps up, via wifi).

[matthijst]

Hier de splitter er tussenuit gehaald (die er van UPC ooit tussen moest omdat het signaal te sterk zou zijn). Sinds vrijdag geen wegvallende verbinding meer gehad en sites laden opeens vlotjes

[ArcticWolf]

Anoniem: 757487 schreef op zondag 17 april 2016 @ 21:28:
De waardes na een reset...us lampje brandt weer BLAUW...


*knip*
[...]

Hopen dat ze snel die kabel gaan vervangen
Die monteur heeft geen datum genoemd zeker?

[Anoniem: 757487]

Nee nog geen datum... maar gezegd dat ik binnen nu en twee weken geholpen ga worden. Je klinkt niet positief hahaha...

ArcticWolf schreef op maandag 18 april 2016 @ 08:32:
[...]

Hopen dat ze snel die kabel gaan vervangen
Die monteur heeft geen datum genoemd zeker?

[Wildfire]

Fijn zo'n RIPE Atlas probe. Dan vallen dingen zoals dit opeens op:


Ping to k.root-servers.net (193.0.14.129)


Zo rond 09:15 uur. Iets in Ziggo routering veranderd of gewoon iets aan de kant van de rootservers zelf?

[Jerrythafast]

Wildfire schreef op maandag 18 april 2016 @ 16:28:
Fijn zo'n RIPE Atlas probe. Dan vallen dingen zoals dit opeens op:


Ping to k.root-servers.net (193.0.14.129)
[afbeelding]

Zo rond 09:15 uur. Iets in Ziggo routering veranderd of gewoon iets aan de kant van de rootservers zelf?

C:\Users\Jerry>tracert 2001:7fd::1

Tracing route to k.root-servers.net [2001:7fd::1]
over a maximum of 30 hops:

  1     *        *        *     Request timed out.
  2     9 ms     9 ms     9 ms  gv-rc0052-cr102-xe-1-0-5-0.core.as9143.net [2001:b88:0:e6f::1]
  3    16 ms    11 ms    13 ms  asd-tr0610-cr101-ae58-0.core.as9143.net [2001:b88:0:101::1]
  4    16 ms    13 ms    12 ms  2001:7f8:1::a502:3148:2
  5    15 ms    20 ms    12 ms  2001:4868:0:8000::22a
  6    30 ms    27 ms    28 ms  2001:4868:0:8000::266
  7    28 ms    27 ms    27 ms  2001:4868:0:8000::261
  8   120 ms   121 ms   121 ms  2001:4868:0:8000::c5
  9   141 ms   137 ms   136 ms  2001:4868:0:8000::39
 10   132 ms   132 ms   132 ms  2001:4868:0:8000::12
 11   133 ms   132 ms   131 ms  router.us-mia.k.ripe.net [2001:4868:100:40::2]
 12   131 ms   131 ms   131 ms  k.root-servers.net [2001:7fd::1]

Trace complete.

C:\Users\Jerry>tracert 193.0.14.129

Tracing route to k.root-servers.net [193.0.14.129]
over a maximum of 30 hops:

  1     1 ms    <1 ms    <1 ms  ubee.evw321b.net
  2     *        *        *     Request timed out.
  3     8 ms    16 ms     9 ms  gv-rc0011-cr101-xe-1-0-3-0.core.as9143.net [213.51.181.169]
  4    12 ms    10 ms    10 ms  asd-tr0042-cr101-ae8-0.core.as9143.net [213.51.158.12]
  5    11 ms    11 ms    10 ms  80.249.211.145
  6   125 ms   126 ms   126 ms  85.112.0.140
  7   126 ms   124 ms   125 ms  85.112.0.174
  8   125 ms   126 ms   126 ms  85.112.0.145
  9   128 ms   128 ms   128 ms  t0-1-0-1.br2.mia.terremark.net [66.165.160.85]
 10   130 ms   135 ms   128 ms  t0-1-0-7.br2.mia.terremark.net [66.165.161.137]
 11   126 ms   126 ms   125 ms  t9-1.gw1.mia.terremark.net [66.165.161.94]
 12   125 ms   127 ms   127 ms  router.us-mia.k.ripe.net [204.51.68.250]
 13   124 ms   124 ms   128 ms  k.root-servers.net [193.0.14.129]

Trace complete.

Wie liep er nou te klagen dan IPv6 adressen zo lang zijn? Korter dan IPv4...

[ANdrode]

Wildfire schreef op maandag 18 april 2016 @ 16:28:
Zo rond 09:15 uur. Iets in Ziggo routering veranderd of gewoon iets aan de kant van de rootservers zelf?

Die probes zijn gaaf

Het lijkt alleen vanuit jouw perspectief te komen als ik de tools van Ripe gebruik.

[ Voor 47% gewijzigd door ANdrode op 18-04-2016 20:53 . Reden: Link is nu geen lege tekst meer :X ]

[Wildfire]

ANdrode schreef op maandag 18 april 2016 @ 19:27:
[...]


Die probes zijn gaaf

Het lijkt alleen vanuit jouw perspectief te komen als ik de tools van Ripe goed gebruik:

Weet niet wat je hier precies wilde laden, maar er wordt niets getoond

Als ik naar mijn andere grafieken kijk, blijven die gewoon normaal. Het is alleen deze ene die opeens verandert rond 09:15 uur. Ben gewoon benieuwd waar het probleem ligt: andere routering ofzo van Ziggo, of toch een probleem aan de kant van k.root-servers.net?

Niet dat het voor m'n verbinding zelf iets uitmaakt

[ Voor 9% gewijzigd door Wildfire op 18-04-2016 19:48 ]

[hcQd]

Het lijkt erop dat het vanuit Ziggo naar de k-root in Miami wordt verstuurd. Waarom begrijp ik niet, die in Amsterdam is iig up:

admin@RT-AC66U-0B00:/tmp/home/root# traceroute 193.0.14.129
traceroute to 193.0.14.129 (193.0.14.129), 30 hops max, 38 byte packets
 1  1-0-201-31.ftth.glasoperator.nl (31.201.0.1)  2.974 ms  2.934 ms  2.938 ms
 2  10.10.80.6 (10.10.80.6)  4.214 ms  4.230 ms  3.519 ms
 3  *  router.nl-ams.k.ripe.net (80.249.208.240)  4.200 ms  4.135 ms
 4  k.root-servers.net (193.0.14.129)  4.358 ms  5.077 ms  4.418 ms

[ANdrode]

Wildfire schreef op maandag 18 april 2016 @ 19:35:
[...]
Weet niet wat je hier precies wilde laden, maar er wordt niets getoond

De forum software vind de link niet leuk. Nieuwe poging: https://goo.gl/FnQHWq

[RenaldoN]

Hier sinds 2 weken ook heel veel storing op de tv. de voorgaande 2 maanden dat ik hier nu woon geen problemen gehad. vandaag dus een monteur langsgehad en deze heeft naar 90minuten ploeteren nog steeds geen oplossing gevonden nadat die alles vervangen had. kabels binnenhuis zijn allemaal van ziggo. setup: hoofdaansluiting-mcp03 splitter-kabel naar tv (ziggokabel) kabel naar modem. ik maar gebruik van een ci+ module maar ook zonder deze module storing op tv, het lijkt meer te worden zodra het internet belast wordt) zodra ik de splitter loskoppel is het beeld wel storingsvrij.


downstream:

Receiver # Channel ID Lock Status Frequency Modulation Symbol Rate SNR Power
1 86 Locked 410750000 256QAM 6952000 39.0 3.5
2 81 Locked 370750000 256QAM 6952000 39.0 3.3
3 82 Locked 378750000 256QAM 6952000 39.0 3.3
4 83 Locked 386750000 256QAM 6952000 38.9 3.2
5 84 Locked 394750000 256QAM 6952000 38.7 3.4
6 85 Locked 402750000 256QAM 6952000 38.7 3.5
7 87 Locked 418750000 256QAM 6952000 38.6 3.5
8 88 Locked 426750000 256QAM 6952000 38.7 3.3

Upstream
Transmitter # Channel ID Lock Status Frequency Modulation Symbol Rate Channel Type Power
1 1 Locked 44000000 64QAM 5120000 ATDMA 48.0
2 2 Locked 37100000 64QAM 5120000 ATDMA 48.0
3 3 Locked 31800000 64QAM 2560000 ATDMA 48.0
4 4 Locked 28600000 64QAM 2560000 ATDMA 48.0

nu lees ik ook dit maar geen idee wat er met het filter bedoeld wordt.

Anoniem: 693050 schreef op donderdag 27 augustus 2015 @ 10:20:
Daarnaast had ik last van blokken in het beeld
Dit werd veroorzaakt door het Ziggo/UPC kabelmodem.
Heb dit opgelost door een Tratec RF high-pass filter tussen de TV output van Cable optimizer en TV input te plaatsen.
Zit al 25 jaar in het technische deel van kabeltv wereldje, dus voor mij makkelijk aan te komen

Ziggo/UPC levert een cable optimizer mee die je op de CAI wandcontactdoos plaatst.
Hierdoor krijg je dan een aparte TV/Radio en modem aansluiting.
Gebleken is dus dat de ontkoppeldemping van het TV sigaal en het retoursignaal (0-65MHz) niet voldoende is en dit dus de storing (regelmatig blokken) veroorzaakt.

[Jerrythafast]

RenaldoN schreef op maandag 18 april 2016 @ 20:58:
Hier sinds 2 weken ook heel veel storing op de tv. de voorgaande 2 maanden dat ik hier nu woon geen problemen gehad. vandaag dus een monteur langsgehad en deze heeft naar 90minuten ploeteren nog steeds geen oplossing gevonden nadat die alles vervangen had. kabels binnenhuis zijn allemaal van ziggo. setup: hoofdaansluiting-mcp03 splitter-kabel naar tv (ziggokabel) kabel naar modem. ik maar gebruik van een ci+ module maar ook zonder deze module storing op tv, het lijkt meer te worden zodra het internet belast wordt) zodra ik de splitter loskoppel is het beeld wel storingsvrij.


downstream:

Receiver # Channel ID Lock Status Frequency Modulation Symbol Rate SNR Power
1 86 Locked 410750000 256QAM 6952000 39.0 3.5
2 81 Locked 370750000 256QAM 6952000 39.0 3.3
3 82 Locked 378750000 256QAM 6952000 39.0 3.3
4 83 Locked 386750000 256QAM 6952000 38.9 3.2
5 84 Locked 394750000 256QAM 6952000 38.7 3.4
6 85 Locked 402750000 256QAM 6952000 38.7 3.5
7 87 Locked 418750000 256QAM 6952000 38.6 3.5
8 88 Locked 426750000 256QAM 6952000 38.7 3.3

Upstream
Transmitter # Channel ID Lock Status Frequency Modulation Symbol Rate Channel Type Power
1 1 Locked 44000000 64QAM 5120000 ATDMA 48.0
2 2 Locked 37100000 64QAM 5120000 ATDMA 48.0
3 3 Locked 31800000 64QAM 2560000 ATDMA 48.0
4 4 Locked 28600000 64QAM 2560000 ATDMA 48.0

nu lees ik ook dit maar geen idee wat er met het filter bedoeld wordt.


[...]

Hmm, klinkt inderdaad wel alsof je modem het veroorzaakt. Als je je modem van de stroom haalt (dus de stroomstekker eruit, maar wel de COAX aangesloten laten), houd je dan storing op TV? Zo nee, dan is je modem de storingsbron. Zo ja, dan kan het nog zijn dat het modem wel storing van buitenaf naar je kabel laat lekken. Maar een goede splitter zou dat niet naar de TV's moeten doorlaten.

[Onbekend]

En als je de splitter wel aansluit, maar de modem niet aan de splitter. Heb je dan ook goed beeld?

[RenaldoN]

Jerrythafast schreef op maandag 18 april 2016 @ 22:09:
[...]

Hmm, klinkt inderdaad wel alsof je modem het veroorzaakt. Als je je modem van de stroom haalt (dus de stroomstekker eruit, maar wel de COAX aangesloten laten), houd je dan storing op TV? Zo nee, dan is je modem de storingsbron. Zo ja, dan kan het nog zijn dat het modem wel storing van buitenaf naar je kabel laat lekken. Maar een goede splitter zou dat niet naar de TV's moeten doorlaten.

ik heb het zojuist een keer geprobeerd. beeld was goed. ik heb daarna de modem weer opgestart en tijdens het opstarten van de modem was het beeld kut. toen die eenmaal opgestart was had ik geen storing. paar minuten later nogmaals hetzelfde gedaan en toen had ik na het opstarten van de modem wel weer storing. modem en splitter zijn vandaag ook al een keer vervangen. het grootste mysterie aan dit alles is denk ik nog wel dat mijn 2 jaar oude lg televisie nergens last van heeft als ik deze op de coax aansluit

[ArcticWolf]

Klinkt alsof er iets niet goed zit in de aarding

[Yash100]

Heeft iemand enig idee waarom Ziggo Ziggo Sport Select en Ziggo Sport Voetbal weer uit de Horizon Go app heeft verwijderd? Was dit een test?

[daxy]

hcQd schreef op maandag 18 april 2016 @ 19:55:
Het lijkt erop dat het vanuit Ziggo naar de k-root in Miami wordt verstuurd. Waarom begrijp ik niet, die in Amsterdam is iig up:

admin@RT-AC66U-0B00:/tmp/home/root# traceroute 193.0.14.129
traceroute to 193.0.14.129 (193.0.14.129), 30 hops max, 38 byte packets
 1  1-0-201-31.ftth.glasoperator.nl (31.201.0.1)  2.974 ms  2.934 ms  2.938 ms
 2  10.10.80.6 (10.10.80.6)  4.214 ms  4.230 ms  3.519 ms
 3  *  router.nl-ams.k.ripe.net (80.249.208.240)  4.200 ms  4.135 ms
 4  k.root-servers.net (193.0.14.129)  4.358 ms  5.077 ms  4.418 ms

Dit is vreemd inderdaad. Ik zie hetzelfde, vanuit Ziggo gaat hij naar Miami.
Vanaf mijn werk (Geo IP in UK) gaat hij naar London/LINX.

[PauseBreak]

Zo. Ik ben weer online. Eerst dat ellenlange gezeur met een wegvallende verbinding, toen een nieuw modem dat 2 of 3 dagen heeft gewerkt, toen een blikseminslag en nu weer een nieuw modem. Dure week zo voor Ziggo

Nu heb ik de TC7210 hier staan, in bridge mode, en dat bevalt tot nu toe prima. Wel valt me op dat de signaalwaardes wat minder zijn dan wat de Cisco rapporteerde. Ik neem aan dat deze waardes wel gewoon prima zijn? Internet is in ieder geval weer stabiel, maar dat is gemeten over een periode van 1 dag, dus ik ben wat achterdochtig nog


Downstream Channel
Channel Lock Status Modulation Channel ID Symbol Rate Frequency Power SNR
1 Locked QAM256 194 6952000 249000000 Hz -3.5 dBmV 39.4 dB
2 Locked QAM256 193 6952000 241000000 Hz -3.4 dBmV 39.8 dB
3 Locked QAM256 195 6952000 257000000 Hz -3.4 dBmV 39.8 dB
4 Locked QAM256 196 6952000 265000000 Hz -3.3 dBmV 39.9 dB
5 Locked QAM256 197 6952000 273000000 Hz -3.0 dBmV 38.7 dB
6 Locked QAM256 198 6952000 281000000 Hz -2.9 dBmV 40.1 dB
7 Locked QAM256 199 6952000 289000000 Hz -2.8 dBmV 40.2 dB
8 Locked QAM256 200 6952000 297000000 Hz -2.5 dBmV 40.2 dB
9 Locked QAM256 201 6952000 305000000 Hz -2.3 dBmV 40.3 dB
10 Locked QAM256 202 6952000 313000000 Hz -2.2 dBmV 40.3 dB
11 Locked QAM256 203 6952000 321000000 Hz -1.7 dBmV 40.4 dB
12 Locked QAM256 204 6952000 329000000 Hz -1.4 dBmV 40.3 dB
13 Locked QAM256 205 6952000 337000000 Hz -1.3 dBmV 40.7 dB
14 Locked QAM256 206 6952000 345000000 Hz -1.2 dBmV 36.8 dB
15 Locked QAM256 207 6952000 353000000 Hz -0.9 dBmV 41.0 dB
16 Locked QAM256 208 6952000 361000000 Hz -0.8 dBmV 41.0 dB


Upstream Channel
Channel Lock Status Modulation Channel ID Symbol Rate Frequency Power
1 Locked QAM64 3 5120 Ksym/sec 36000000 Hz 42.2 dBmV
2 Locked QAM64 1 5120 Ksym/sec 52000000 Hz 42.3 dBmV
3 Locked QAM64 2 5120 Ksym/sec 44500000 Hz 42.3 dBmV
4 Locked QAM64 4 5120 Ksym/sec 58800000 Hz 42.3 dBmV


Het enige dat vervelend zou kunnen zijn is dat er zo ongeveer om de 6 uur een T4 en T3 timeout in de Eventlog staat, maar daar merk ik verder vrij weinig van in de praktijk.

[ArcticWolf]

T3/T4 timeouts zijn niet goed

[PauseBreak]

ArcticWolf schreef op dinsdag 19 april 2016 @ 17:09:
T3/T4 timeouts zijn niet goed

Nee nou ja, ik leef niet in de illusie dat die problemen door mij oplosbaar zijn. Temeer het blijkbaar op een locatie fout gaat waar Ziggo van in de veronderstelling verkeert dat het niet fout kán gaan op die plek in het netwerk, dus dat ga ik ze niet aan het verstand gepeuterd krijgen.

[Jim423]

Een enkele timeout is ook niet zo'n groot probleem. Ik merk er tenminste niets van tijdens online gamen of in mijn video streams. Pas wanneer het echt op gaat lopen (zeg vele T4's per dag) zou ik je pas zorgen gaan maken. Wanneer je verder geen problemen ervaart maar je telkens blind gaat staren op die 2 tellertjes schiet het ook niet echt op

[ArcticWolf]

Ik heb sinds kort wel wat minor package loss @ Ziggo gateway... T3 en T4 nog steeds op 0. (Status
System Up Time 31 days 19h:25m:47s)
Afgelopen nacht tussen 1:20 en 1:40 was het wel wat erger dan gemiddeld.

[stormfly]

ArcticWolf schreef op dinsdag 19 april 2016 @ 20:43:
Ik heb sinds kort wel wat minor package loss @ Ziggo gateway... T3 en T4 nog steeds op 0. (Status
System Up Time 31 days 19h:25m:47s)
Afgelopen nacht tussen 1:20 en 1:40 was het wel wat erger dan gemiddeld.

Ja dat heb ik ook wel eens met smokeping 0,1 of hooguit 0,2% eigenlijk altijd in de nacht. IPv6 met de Ubee heeft elke nacht packetloss van 0,1% dat viel me wel op. Via de HE tunnel 0,0 dus mijn meting is OK.

[poor Leno]

Hahaha beetje offtopic, maar ik kwam dit stukje tegen in een video van John Oliver..
Deed me zo hard aan UPC/Ziggo denken

vanaf 04:55

Hier het hele filmpje (op Tweakers kun je niet 'vanaf tijd' linken..)

Als je de tijd hebt, kijk m.. geniaal!

ooooooh landlines!

[ Voor 3% gewijzigd door poor Leno op 20-04-2016 10:06 ]

[Raven]

poor Leno schreef op woensdag 20 april 2016 @ 10:03:
op Tweakers kun je niet 'vanaf tijd' linken

Daar zijn vaak genoeg requests voor aangemaakt, zonder succes

[TFHfony]

TFHfony schreef op vrijdag 15 april 2016 @ 10:44:
[...]

Grappig Toch eens een aanvraag de deur uit gedaan (Tegen beter weten in...)
Ik ben benieuwd wanneer en of ik wat te horen krijg

Bovenstaande post was i.v.m. de aanvraag van een probe voor de RIPE Atlas: Ik krijg net een e-mail dat er eentje deze kant op komt, dus...
Weer een meetpuntje er bij in het Ziggo netwerk.

[ Voor 5% gewijzigd door TFHfony op 21-04-2016 09:20 ]

[ArcticWolf]

Al die RIPE backdoors

Kep m'n Benext domotica hub ook maar op een ander vlan geplaatst voor het geval dat.

[TFHfony]

ArcticWolf schreef op donderdag 21 april 2016 @ 09:40:
Al die RIPE backdoors

Kep m'n Benext domotica hub ook maar op een ander vlan geplaatst voor het geval dat.

Had ik hier met mijn Sam Know's Whitebox ook gedaan. Alleen heb ik die inmiddels weer losgekoppeld, omdat de resultaten zo erg niet in overeenstemming waren met de realiteit. Heb het ding hier nog in de kast liggen...

[Wildfire]

TFHfony schreef op donderdag 21 april 2016 @ 10:30:
[...]

Had ik hier met mijn Sam Know's Whitebox ook gedaan. Alleen heb ik die inmiddels weer losgekoppeld, omdat de resultaten zo erg niet in overeenstemming waren met de realiteit. Heb het ding hier nog in de kast liggen...

Week het zoveel af dan?

-- Edit:

To return the unit to SamKnows should I no longer wish to be involved (SamKnows to pay reasonable postage costs).

Foei, stuur dat ding terug


--- Edit #2:

Na ruim 7 dagen en 19 uur zit het modem nu op 4732 correctable errors, 3700 uncorrectable errors en 5 T3 time-outs.

Het vervangen van alle kabels door Technetix RLA++ kabels en het vervangen van de Technetix TOF-01 door de Technetix TOF-02KK heeft dus maar weinig effect gehad, het lijkt allemaal wel iets minder vaak te gebeuren, dat wel. En op de Humax decoder kom ik nu op zo'n 6 procentpunt hogere signaalsterktes uit.

Enige wat ik me kan bedenken is het AOP zelf... toch maar eens Ziggo vragen die te vervangen.

[ Voor 52% gewijzigd door Wildfire op 21-04-2016 11:32 ]

[krakendmodem]

poor Leno schreef op woensdag 20 april 2016 @ 10:03:
Hahaha beetje offtopic, maar ik kwam dit stukje tegen in een video van John Oliver..
Deed me zo hard aan UPC/Ziggo denken

vanaf 04:55

Hier het hele filmpje (op Tweakers kun je niet 'vanaf tijd' linken..)

Als je de tijd hebt, kijk m.. geniaal!

[video]


ooooooh landlines!

KPN doet dat ook net zo goed. Krijg je een gratis telefoonlijn bij je Internet pakket (zonder TV). Maar als je vervolgens een extra telefoonnummer wilt kun je extra dokken

[TFHfony]

Wildfire schreef op donderdag 21 april 2016 @ 11:11:
[...]
Week het zoveel af dan?

Yep. Volgens hun testmethode donderde elke avond mijn snelheid in elkaar naar 20mbit/sec, terwijl als ik het zelf testte op verschillende sites gewoon stabiel 200mbit bleef. Ze hebben me 2 keer verhuisd naar een andere test-server van hun, waarna het weer goed ging, voor een paar weken....

Foei, stuur dat ding terug

Ze al 2 keer de keus gegeven wat ze willen:

* Dat ik hem terugstuur (tegen kostprijs natuurlijk)
* Dat ze het mij laten weten als de troubles zijn opgelost en dan sluit ik hem weer aan...

Maar het is al enige maanden radiostilte vanuit hun kant, dus...
Ik zit er aan te denken om hem maar terug te flashen met de originele firmware en hem maar aan iemand te geven, zodat hij nog zinvol gebruikt wordt ipv in mijn kast stof je liggen vergaren. Het is gewoon een complete TL-WDR3600 ;-)

[stormfly]

Wildfire schreef op donderdag 21 april 2016 @ 11:11:
[...]

Na ruim 7 dagen en 19 uur zit het modem nu op 4732 correctable errors, 3700 uncorrectable errors en 5 T3 time-outs.

Dat zijn toch fantastische waardes voor bijna 8 dagen uptime?

Wat ervaar je als gebruiker voor impact?

[ArcticWolf]

TFHfony schreef op donderdag 21 april 2016 @ 10:30:
[...]

Had ik hier met mijn Sam Know's Whitebox ook gedaan. Alleen heb ik die inmiddels weer losgekoppeld, omdat de resultaten zo erg niet in overeenstemming waren met de realiteit. Heb het ding hier nog in de kast liggen...

De Benext hub is een domotica hub voor m'n stadsverwarming aansturing
Maar ik vertrouw 3rd party hw niet 123, ze kunnen gewoon zo op je thuis netwerk dus sowieso is het aanbevolen om 3rd party hw op een andere vlan te zetten.

[Wildfire]

stormfly schreef op donderdag 21 april 2016 @ 11:58:
[...]

Dat zijn toch fantastische waardes voor bijna 8 dagen uptime?

Wat ervaar je als gebruiker voor impact?

En waarom zijn dat "fantastische" waardes? Ik weet dat de errors oplopen op het moment dat er via de Humax'en in huis storing is te zien, dus er is duidelijk ergens nog iets niet 100% in orde...

[stormfly]

Wildfire schreef op donderdag 21 april 2016 @ 13:13:
[...]


En waarom zijn dat "fantastische" waardes? Ik weet dat de errors oplopen op het moment dat er via de Humax'en in huis storing is te zien, dus er is duidelijk ergens nog iets niet 100% in orde...

Van die waardes schrik ik echt niet, ik heb fases gehad dat ze bij mij ook zo hoog waren en smokeping niets liet zien. Hooguit wat latency verhoging maar geen packetloss.

Maar je ziet dus storing op de humax, dat is je echte impact op je dienstverlening. Is alles geaard, ik heb mijn AOP aan de aardrail gehangen in de meterkast.

[Wildfire]

stormfly schreef op donderdag 21 april 2016 @ 13:52:

[...]

Van die waardes schrik ik echt niet, ik heb fases gehad dat ze bij mij ook zo hoog waren en smokeping niets liet zien. Hooguit wat latency verhoging maar geen packetloss.

Maar je ziet dus storing op de humax, dat is je echte impact op je dienstverlening. Is alles geaard, ik heb mijn AOP aan de aardrail gehangen in de meterkast.

AOP Zit bij ons in de huiskamer. Randaarde hebben we alleen in de keuken, bijkeuken en schuur, rest van het huis niet. Apparatuur bij de AOP is dus niet geaard.

Randaarde aanleggen gaat 'm niet worden helaas.

Ik laat het maar zo, storingen op de Humax zijn erg infrequent nu dus ik kan er zo prima mee leven. Het was meer het principe dat ik errors zie bij het modem en mijn tweakersaard kan daar niet tegen

Ik moet ook eerlijk zeggen, bij het internetten ervaar ik geen problemen. Alles gaat prima, geen haperingen ofzo, downloaden gaat (als de bron het aan kan) ook netjes fullspeed op 200mbit/sec.

[ Voor 10% gewijzigd door Wildfire op 21-04-2016 14:04 ]

[Jerrythafast]

Jerrythafast schreef op woensdag 06 april 2016 @ 23:19:
[...]

Het vervolg van bovenstaande reeks!

code:

Wed Apr  6 01:18:01 UTC 2016    84083   94359
Wed Apr  6 01:19:01 UTC 2016    84084   94359
Wed Apr  6 02:23:01 UTC 2016    84085   94359
Wed Apr  6 04:45:01 UTC 2016    84086   94359
Wed Apr  6 06:02:01 UTC 2016    84087   94359
Wed Apr  6 06:08:01 UTC 2016    84088   94359
Wed Apr  6 08:11:01 UTC 2016    84090   94359
Wed Apr  6 09:02:01 UTC 2016    84091   94359
Wed Apr  6 10:29:01 UTC 2016    84092   94359
Wed Apr  6 12:43:01 UTC 2016    84093   94359
Wed Apr  6 14:26:01 UTC 2016    84094   94359
Wed Apr  6 15:31:01 UTC 2016    84095   94359
Wed Apr  6 18:05:01 UTC 2016    84096   94359
Wed Apr  6 18:48:01 UTC 2016    84097   94359
Wed Apr  6 19:12:01 UTC 2016    84098   94359
Wed Apr  6 20:17:01 UTC 2016    84099   94359
Wed Apr  6 20:36:01 UTC 2016    84101   94359
Wed Apr  6 21:14:01 UTC 2016    84101   94359

Een hele dag nagenoeg foutloos dus.

Even hierop terugkomend... moet je kijken wat er vanmiddag gebeurde.

code:

Date and time              Correctables Uncorrectables
Thu Apr 21 10:40:01 UTC 2016    84525   94359
Thu Apr 21 10:41:01 UTC 2016    84567   94361

Uncorrectables!

Mijn uptime is nu (as we speak) 25 days 00h:00m:41s. Heb 84779 correctables en 94361 uncorrectables op de teller staan nu.

stormfly schreef op donderdag 21 april 2016 @ 11:58:
[...]

Dat zijn toch fantastische waardes voor bijna 8 dagen uptime?

Wat ervaar je als gebruiker voor impact?

Bij mij dus in 15 dagen tijd (sinds 5 april) 0 uncorrectables en in 25 dagen tijd nog helemaal geen T3 of T4 timeouts. De impact van die timeouts die je ervaart als gebruiker is een korte downtime, hoewel je die downtime natuurlijk niet merkt als zo'n timeout toevallig 's nachts plaatsvindt. Uncorrectables kunnen leiden tot connection resets en lagspikes.

[ Voor 1% gewijzigd door Jerrythafast op 21-04-2016 20:53 . Reden: Kolom headers erbij gezet ]

[voske]

Gisteren in een spontane bui de klantenservice van Ziggo gebeld (ik had beter eerst dit topic kunnen lezen, maar goed ...): de internetverbinding viel de afgelopen weken heel vaak kort weg, met name overdag. Volgens de medewerker van de klantenservice zou het in bridge modus zetten van de modem het probleem oplossen. Dat is echter niet het geval. Mijn eerste ingeving is om de coax-kabel tussen het AOP en de modem morgen te vervangen en, als dat niet helpt, weer contact op te nemen met de klantenservice.

De score over de afgelopen 19 uur:
6739 correctables
6908 uncorrectables
10 T3 timeouts (waarvan 4 tussen 23.30 uur en 06.30 uur)
1 T4 timeout

Downstream Channels
Power Level: Signal to Noise Ratio:
Channel 1: -7.2 dBmV 40.4 dB
Channel 2: -6.4 dBmV 40.0 dB
Channel 3: -6.4 dBmV 40.3 dB
Channel 4: -6.7 dBmV 39.9 dB
Channel 5: -6.8 dBmV 39.9 dB
Channel 6: -6.7 dBmV 40.9 dB
Channel 7: -6.5 dBmV 40.9 dB
Channel 8: -6.3 dBmV 40.8 dB

Upstream Channels
Power Level:
Channel 1: 44.0 dBmV
Channel 2: 43.5 dBmV
Channel 3: 44.0 dBmV
Channel 4: 44.5 dBmV

[ArcticWolf]

Die waardes zijn niet eens zo slecht... lijkt net of Ziggo sinds kort opeens op meerdere plekken in NL een capaciteitstekort heeft.

[stormfly]

ArcticWolf schreef op vrijdag 22 april 2016 @ 07:52:
Die waardes zijn niet eens zo slecht... lijkt net of Ziggo sinds kort opeens op meerdere plekken in NL een capaciteitstekort heeft.

150Mbit upgrade ;-)

[ArChie]

ArcticWolf schreef op vrijdag 22 april 2016 @ 07:52:
Die waardes zijn niet eens zo slecht... lijkt net of Ziggo sinds kort opeens op meerdere plekken in NL een capaciteitstekort heeft.

Correctables en Uncorrectables zijn een indicatie voor de kwaliteit van het signaal en hebben als zodanig niets met capaciteit van doen. T3 en T4 zouden ook onafhankelijk moeten zijn van de capaciteit aangezien dergelijk DOCSIS management verkeer natuurlijk de hoogste prioriteit zou moeten hebben om ervoor te zorgen dat de verbindingen tussen CMTS en de modems in het coaxsegment niet telkens opnieuw geïnitialiseerd moeten worden.

[stormfly]

ArChie schreef op vrijdag 22 april 2016 @ 08:29:
[...]

Correctables en Uncorrectables zijn een indicatie voor de kwaliteit van het signaal en hebben als zodanig niets met capaciteit van doen. T3 en T4 zouden ook onafhankelijk moeten zijn van de capaciteit aangezien dergelijk DOCSIS management verkeer natuurlijk de hoogste prioriteit zou moeten hebben om ervoor te zorgen dat de verbindingen tussen CMTS en de modems in het coaxsegment niet telkens opnieuw geïnitialiseerd moeten worden.

Mooi om te zien hoe snel jij meeleest ;-)

Maar uit eerdere posts van jou had ik zelf geconcludeerd dat T3 en T4 wel met capaciteit problemen te maken zou kunnen hebben. Vol=vol waardoor ook deze mgmt pakketten niet aankomen op de juiste bestemmingen?

Blijft dat een valide uitspraak?

[Jim423]

Behalen jullie ook de snelheid niet op de ziggo speedtest in de avonduren dan? Want als je je snelheid gewoon continu haalt is de kans erg klein dat het met een capaciteitstekort te maken heeft.

[supermlt]

ArcticWolf schreef op vrijdag 22 april 2016 @ 07:52:
Die waardes zijn niet eens zo slecht... lijkt net of Ziggo sinds kort opeens op meerdere plekken in NL een capaciteitstekort heeft.

Ik weet het niet, gisteren was het een drama. Meerdere keren per uur uitval. Smokeping leek wel een spam bot.

Capaciteits probleem zal haast niet kunnen zal je denken sinds ze met terugloop van klanten te maken hebben (volgens berichten in media)

Ik heb het idee dat Ziggo geen idee heeft wat de problemen veroorzaakt.
Die indruk krijg ik niet vanuit ziggo en het contact wat ik heb met Ziggo.
Nu moet ik mijn modem weer uit bridge halen en testen. Voelt een beetje als trial & error.
Ziggo verzocht om de modem waardes en logs van modems in mijn buurt ook eens preventief uit te lezen. Nog geen reactie.

Ik lees in diverse foras mensen met dezelfde problematiek, maar tot dusver geen oplossing.

Bij mij begint het inmiddels wel een irritatie punt te worden.

[supermlt]

Jim423 schreef op vrijdag 22 april 2016 @ 08:41:
Behalen jullie ook de snelheid niet op de ziggo speedtest in de avonduren dan? Want als je je snelheid gewoon continu haalt is de kans erg klein dat het met een capaciteitstekort te maken heeft.

Ik behaal,als ik speedtest uitvoer, bijna altijd de volledige download snelheid en upload snelheid haal ik altijd (200/20).

Wel T3 en T4 meldingen in modem en geregeld korte uitval (10 à 15 sec) dat het gateway adres van mijn Ziggo subnet niet te bereiken is. (monitor het met Smokeping)

[ArChie]

stormfly schreef op vrijdag 22 april 2016 @ 08:34:
Maar uit eerdere posts van jou had ik zelf geconcludeerd dat T3 en T4 wel met capaciteit problemen te maken zou kunnen hebben. Vol=vol waardoor ook deze mgmt pakketten niet aankomen op de juiste bestemmingen?

Dat is dan de verkeerde conclusie. De CMTS is de regiseur van het data verkeer tussen CMTS en de modems in de wijk. De CMTS bepaalt als zodanig waarvoor de upstream en downstream capaciteit in een coaxsegment wordt aangewend. Data verkeer krijgt prioriteiten afhankelijk van het soort verkeer. Als een CMTS bijvoorbeeld Ranging Request van een modem via de upstream ontvangt weet de CMTS dat er binnen X tijd een Ranging Response via de downstream terug moet worden gestuurd naar het modem omdat het modem het anders opnieuw gaat proberen en na X pogingen een T3 timeout rapporteert in de logging en overgaat op een herregistratie bij de CMTS. De CMTS zal dergelijke packets dus voorrang geven bij de plaatsing in de downstream.

Ook zorgt de CMTS ervoor dat de modems de gelegenheid krijgen om hun verplichte DOCSIS management berichten in de upstream te plaatsen door daarvoor zendtijd te reserveren. Zoals ik al eerder heb aangegeven wordt zendtijd in de upstream voor verschillende toepassingen toegewezen:
•Request
•Initial Maintenance
•Station Maintenance
•Advanced PHY Short Data Grant
•Advanced PHY Long Data Grant
•Advanced PHY Unsolicited Grant

De CMTS zendt via de downstreams Upstream Bandwidth Allocation DOCSIS management berichten naar de modems zodat de modems weten op welk moment ze een bepaalde upstream voor een bepaalde toepassing mogen aanwenden en door wie.

Naast DOCSIS management berichten krijgt bijvoorbeeld ook telefonie data verkeer een hogere prioriteit (QoS) dan ander data verkeer om ervoor te zorgen dat het gesprek niet gaan stotteren of door vertragingen lastig te voeren wordt.

[Ploink]

Ik werd zojuist gebeld door Ziggo op mijn vaste telefoon, maar ik vermoed dat het om een scam gaat.
Telefoontje was afkomstig van het nummer 06-55717847 en een man probeerde mij een Ziggo zakelijk abbo aan te smeren omdat hij wist dat ik een KvK nummer heb. Ik ben er niet op in gegaan en toen ik het nummer probeerde te googelen kon ik niks vinden. Ik ben geen klant van Ziggo.
Iemand die dit kan bevestigen? Ziggo maakt toch geen gebruik van vage 06 nummers en medewerkers bellen toch niet met hun mobiel ofzo?

Ik heb een melding gedaan op wieheeftgebeld.nl

[Timmert]

Ploink schreef op vrijdag 22 april 2016 @ 09:05:
Ik werd zojuist gebeld door Ziggo op mijn vaste telefoon, maar ik vermoed dat het om een scam gaat.
Telefoontje was afkomstig van het nummer 06-55717847 en een man probeerde mij een Ziggo zakelijk abbo aan te smeren omdat hij wist dat ik een KvK nummer heb. Ik ben er niet op in gegaan en toen ik het nummer probeerde te googelen kon ik niks vinden. Ik ben geen klant van Ziggo.
Iemand die dit kan bevestigen? Ziggo maakt toch geen gebruik van vage 06 nummers en medewerkers bellen toch niet met hun mobiel ofzo?

Ik heb een melding gedaan op wieheeftgebeld.nl

Ziggo Zakelijk maakt gebruik van een partner systeem. Mogelijk heeft 1 van de ZZ partners uit jouw omgeving gebeld? In principe mogen die ook acquisitie doen namelijk.

[ArChie]

supermm958 schreef op vrijdag 22 april 2016 @ 08:43:
[...]
Capaciteits probleem zal haast niet kunnen zal je denken sinds ze met terugloop van klanten te maken hebben (volgens berichten in media)

Die klanten terugloop heeft toch niet alleen in jouw coaxsegment plaatsgevonden zodat er nu opeens geen overboeking meer in je coaxsegment is? Vergeet niet dat Ziggo bezig is om de abonnementssnelheden te verhogen terwijl daar veelal geen infrastructuur aanpassingen tegenover staan met als gevolg dat de overboeking van de capaciteit nog verder oploopt.

[ArcticWolf]

ArChie schreef op vrijdag 22 april 2016 @ 09:01:
[...]

Dat is dan de verkeerde conclusie. De CMTS is de regiseur van het data verkeer tussen CMTS en de modems in de wijk. De CMTS bepaalt als zodanig waarvoor de upstream en downstream capaciteit in een coaxsegment wordt aangewend. Data verkeer krijgt prioriteiten afhankelijk van het soort verkeer. Als een CMTS bijvoorbeeld Ranging Request van een modem via de upstream ontvangt weet de CMTS dat er binnen X tijd een Ranging Response via de downstream terug moet worden gestuurd naar het modem omdat het modem het anders opnieuw gaat proberen en na X pogingen een T3 timeout rapporteert in de logging en overgaat op een herregistratie bij de CMTS. De CMTS zal dergelijke packets dus voorrang geven bij de plaatsing in de downstream.

Ook zorgt de CMTS ervoor dat de modems de gelegenheid krijgen om hun verplichte DOCSIS management berichten in de upstream te plaatsen door daarvoor zendtijd te reserveren. Zoals ik al eerder heb aangegeven wordt zendtijd in de upstream voor verschillende toepassingen toegewezen:
•Request
•Initial Maintenance
•Station Maintenance
•Advanced PHY Short Data Grant
•Advanced PHY Long Data Grant
•Advanced PHY Unsolicited Grant

De CMTS zendt via de downstreams Upstream Bandwidth Allocation DOCSIS management berichten naar de modems zodat de modems weten op welk moment ze een bepaalde upstream voor een bepaalde toepassing mogen aanwenden en door wie.

Naast DOCSIS management berichten krijgt bijvoorbeeld ook telefonie data verkeer een hogere prioriteit (QoS) dan ander data verkeer om ervoor te zorgen dat het gesprek niet gaan stotteren of door vertragingen lastig te voeren wordt.

Maar dat gebeurt dus niet in dit geval anders zou het modem geen T3 timeouts registreren, dus ik nam even aan dat de CMTS "overbelast" is (als dat al mogelijk is?) en dus niet in staat is alle requests af te handelen. Jij geeft aan dat het waarschijnlijk aan een verstoord signaal in de lijn ligt, verdwijnt die request dan door interferentie?

[Jim423]

Interferentie kleine kans maar het kan wel komen door ingress. Dat is dus noise op de upstream band. Maar er kunnen meer oorzaken zijn, defecte retourmodule, config CMTS, CMTS overbelast maar dat is speculeren.

[supermlt]

ArChie schreef op vrijdag 22 april 2016 @ 09:14:
[...]

Die klanten terugloop heeft toch niet alleen in jouw coaxsegment plaatsgevonden zodat er nu opeens geen overboeking meer in je coaxsegment is? Vergeet niet dat Ziggo bezig is om de abonnementssnelheden te verhogen terwijl daar veelal geen infrastructuur aanpassingen tegenover staan met als gevolg dat de overboeking van de capaciteit nog verder oploopt.

Dat is waar, terug loop hoeft hier inderdaad niet plaatsgevonden te hebben. Echter de problemen spelen al sinds vorig jaar.
Helaas weet Ziggo het ook nog niet wat de oorzaak zal kunnen zijn. Meerdere monteurs over de vloer gehad.....
Binnenshuis en tot aan de EV alles dik in orde volgens ziggo. Ik heb alleen niet het idee dat Ziggo verder kijkt, ook niet naar herhaaldelijk vragen om hier of iemand eens te laten kijken.

[ArChie]

ArcticWolf schreef op vrijdag 22 april 2016 @ 09:21:
Maar dat gebeurt dus niet in dit geval anders zou het modem geen T3 timeouts registreren, dus ik nam even aan dat de CMTS "overbelast" is (als dat al mogelijk is?) en dus niet in staat is alle requests af te handelen.

Het zou niet best zijn als de CMTS niet in staat is om de beschikbare capaciteit te verdelen over de gevraagde capaciteit door de modems. De capaciteit is eindig, dus als de gezamelijke vraag van de modems de beschikbare capaciteit overstijgt gaat de CMTS gewoon knijpen.

Jij geeft aan dat het waarschijnlijk aan een verstoord signaal in de lijn ligt, verdwijnt die request dan door interferentie?

Het modem geeft aan dat er sprake is van een verstoord signaal op de downstreams middels die Correctable/Uncorrectable waarden. Via die downstreams worden ook DOCSIS management requests en responses van de CMTS naar de modems verzonden, dus is het mogelijk dat berichten niet aankomen als een deel van berichten als verminkt (uncorrectable) door het modem worden aangemerkt. Op DOCSIS niveau is er geen sprake van een garantie dat berichten worden afgeleverd.

Misschien komt een deel van de verwarring omdat niet duidelijk is wat nu eigenlijk een stream is? Een stream is een eindeloze bitreeks van enen en nullen die in één richting van zender naar ontvanger gaan. Bij een upstream zijn de modems de zenders en de CMTS de ontvanger en bij een downstream is de CMTS de zender en de modems de ontvangers. 8 opeenvolgende bits maakt samen een byte en 204 opeenvolgende bytes maakt één packet. 16 van die bytes van ieder packet zijn voor de Reed-Solomon error correctie (Correctable/Uncorrecable) waardoor er uiteindelijk dus 188 bytes overblijven voor het packet dat door DOCSIS wordt gebruikt.

Ieder packet dat bij de ontvanger binnenkomt bevat een vaste header. Op basis van die header bepaalt de ontvanger of het om een DOCSIS packet of om een NULL packet gaat. Die NULL packets zitten in de stream om de bitrate constant te houden. De naam NULL packets komt van de hexadecimale waarde 0x00 die iedere payload byte in een dergelijk NULL packet heeft. Dergelijke NULL packets worden door de ontvanger genegeerd. De DOCSIS packets worden uiteraard wel verwerkt waarbij de ontvanger voor ieder packet zal controleren of het bestemd is voor de ontvanger. Als dat niet het geval is zal de ontvanger dat packet ook negeren. DOCSIS heeft een aantal packet soorten gedefinieerd zoals o.a. packets voor DOCSIS management berichten en packets voor de doorgifte van andere protocollen. In de praktijk zal een ontvanger meerdere DOCSIS packets moeten combineren om bijvoorbeeld tot een DOCSIS Management bericht of TCP packet te komen. Als dan één van die onderliggende DOCSIS packets corrupt is (uncorrectable) dan gaat het hogere level bericht dat uit meerdere DOCSIS packets bestaat dus in zijn geheel verloren.

In de downstreams gaat dit proces continu door ongeacht of er nu wel of niet van het modem gebruik wordt gemaakt door de klant. Als er niet gebruik wordt gemaakt van het modem dan zal het gros van de packets berichten worden genegeerd omdat er nagenoeg niets bestemd is voor het modem en/of aan het modem gekoppelde apparaten. Een ongebruikt modem blijft echter wel met vaste intervallen DOCSIS management berichten verzenden via de upstream naar de CMTS en ontvangt ook via de downstreams DOCSIS management berichten en reacties terug van de CMTS.

[martijnm71]

God, wat een drama is de technicolor 7210 in dagelijks gebruik, heb stabieler WiFi gehad in hotels in derde wereld landen.

Kortom tijd om er een eigen router achter te hangen.

[Timmert]

martijnm71 schreef op vrijdag 22 april 2016 @ 10:29:
God, wat een drama is de technicolor 7210 in dagelijks gebruik, heb stabieler WiFi gehad in hotels in derde wereld landen.

Kortom tijd om er een eigen router achter te hangen.

Op 2.4 of 5GHz?

[TFHfony]

martijnm71 schreef op vrijdag 22 april 2016 @ 10:29:
God, wat een drama is de technicolor 7210 in dagelijks gebruik, heb stabieler WiFi gehad in hotels in derde wereld landen.

Kortom tijd om er een eigen router achter te hangen.

nieuws: Ziggo-klanten klagen over wegvallende wifi op 2,4GHz

Is een firmware issue... En Ziggo (lees: Technicolor) lijkt er geen haast mee te hebben. Het probleem is nog steeds niet opgelost.

[alex3305]

martijnm71 schreef op vrijdag 22 april 2016 @ 10:29:
God, wat een drama is de technicolor 7210 in dagelijks gebruik, heb stabieler WiFi gehad in hotels in derde wereld landen.

Kortom tijd om er een eigen router achter te hangen.

Hier werkt de wifi over het algemeen gewoon goed. Echter op 5GHz valt de verbinding ongeveer een keer per dag weg. Het enige wat lijkt te helpen is een modem reboot. 2.4GHz blijft vrolijk doorpruttelen.

Vreemd genoeg blijft het SSID gewoon in beeld en blijf ik 'verbonden', alleen zakt de signaalsterkte compleet in als ik het zie gebeuren. Meestal is dat na 15 - 30 minuten weer zoals het zou moeten, alleen blijf ik dan het probleem houden dat de verbinding periodiek wegvalt. Dat is dan tevens ook op alle apparaten die met 5GHz verbonden zijn.

[martijnm71]

alex3305 schreef op vrijdag 22 april 2016 @ 10:48:
[...]

Hier werkt de wifi over het algemeen gewoon goed. Echter op 5GHz valt de verbinding ongeveer een keer per dag weg. Het enige wat lijkt te helpen is een modem reboot. 2.4GHz blijft vrolijk doorpruttelen.

Vreemd genoeg blijft het SSID gewoon in beeld en blijf ik 'verbonden', alleen zakt de signaalsterkte compleet in als ik het zie gebeuren. Meestal is dat na 15 - 30 minuten weer zoals het zou moeten, alleen blijf ik dan het probleem houden dat de verbinding periodiek wegvalt. Dat is dan tevens ook op alle apparaten die met 5GHz verbonden zijn.

Erg vergelijkbaar met wat ik heb, alleen dan meerdere keren per dag en zowel op 2.4 en 5 ghz.

En ziggo haalt de schouders op en heeft zoiets van tja we zijn niet verantwoordelijk voor hoe je wifi het doet.

Iemand nog goeie tips voor een router en of accessoire die stabieler is want na 3 dagen ben ik het eigenlijk wel beu.

[Jim423]

Misschien kun je het TPLink AP met korting krijgen gezien de problemen? Zal qua prijs niks tegenop kunnen dan. Kun je eventueel ook nog originele firmware in flashen mocht je ziggo firmware niks vinden.

[TFHfony]

Jim423 schreef op vrijdag 22 april 2016 @ 11:09:
Misschien kun je het TPLink AP met korting krijgen gezien de problemen? Zal qua prijs niks tegenop kunnen dan. Kun je eventueel ook nog originele firmware in flashen mocht je ziggo firmware niks vinden.

Mijn ervaring is inderdaad dat als je belt met klachten over de WiFi dat ze je de TP Link aanbieden voor 30 euro. Het is het proberen waard wellicht

[martijnm71]

Dan gaan we dat maar eens proberen. Dank voor de tips en het meedenken

[ArcticWolf]

mm, krijg net melding (email) dat m'n gateway plat ligt, website doet het ook niet meer
Ben benieuwd of het modem of de stroom is uitgevallen

edit;
wel lastig als je op je werk zit en je kan niks...

[ Voor 31% gewijzigd door ArcticWolf op 22-04-2016 11:30 ]

[xares]

Ploink schreef op vrijdag 22 april 2016 @ 09:05:
Ik werd zojuist gebeld door Ziggo op mijn vaste telefoon, maar ik vermoed dat het om een scam gaat.
Telefoontje was afkomstig van het nummer 06-55717847 en een man probeerde mij een Ziggo zakelijk abbo aan te smeren omdat hij wist dat ik een KvK nummer heb. Ik ben er niet op in gegaan en toen ik het nummer probeerde te googelen kon ik niks vinden. Ik ben geen klant van Ziggo.
Iemand die dit kan bevestigen? Ziggo maakt toch geen gebruik van vage 06 nummers en medewerkers bellen toch niet met hun mobiel ofzo?

Ik heb een melding gedaan op wieheeftgebeld.nl

Laatst ook 2x keer over gebeld door 2 verschillende personen. 3 maanden gratis, betere uptime garantie, betere service desk etc. etc.
Meneer was ook nog geïrriteerd omdat ik zijn aanbod afwees.

Weet alleen niet of het ook dit 06-nummer was.

[Jerrythafast]

ArcticWolf schreef op vrijdag 22 april 2016 @ 11:25:
mm, krijg net melding (email) dat m'n gateway plat ligt, website doet het ook niet meer
Ben benieuwd of het modem of de stroom is uitgevallen

edit;
wel lastig als je op je werk zit en je kan niks...

Als je je gateway adres uit je hoofd weet kan ik wel kijken of het pingbaar is vanaf hier

[ArcticWolf]

Jerrythafast schreef op vrijdag 22 april 2016 @ 11:53:
[...]

Als je je gateway adres uit je hoofd weet kan ik wel kijken of het pingbaar is vanaf hier

Nee m'n ip adres is sowieso niet pingbaar, maar ik blijf maar meldingen krijgen dat m'n internet plat is en ook weer dat een reconnect heeft plaatsgevonden

edit:
doh... gateway is bereikbaar, vaag

[ Voor 6% gewijzigd door ArcticWolf op 22-04-2016 12:46 ]

[martijnm71]

Niet gelukt, wel prima geholpen door een verder vriendelijk en vakkundige medewerker. Dan zelf maar eens geld gaan uitgeven.

[stormfly]

ArcticWolf schreef op vrijdag 22 april 2016 @ 12:42:
[...]

Nee m'n ip adres is sowieso niet pingbaar, maar ik blijf maar meldingen krijgen dat m'n internet plat is en ook weer dat een reconnect heeft plaatsgevonden

edit:
doh... gateway is bereikbaar, vaag

Iets wat je website polst zoals pingdom oid?

Om klapperingen uit te sluiten doe ik altijd twee checks. (Uptimerobot.com en pingdom en dan icmp en http)

[Pietervs]

Afgelopen woensdag konden we ineens alleen nog maar Nederland 1, 2 en 3 ontvangen via onze Humax 5400. Van alle andere zenders kregen we geen beeld, maar wel geluid.
Ook gisteren was dat niet beter.
Nu hebben we een tweede Humax met kaart, dus die overgezet en kregen we wel weer alle zenders. Dus de oorsponkelijke kaart er weer in gedaan, en via de website op "herstel" geklikt. Na een minuut of 10 deed alles het weer zoals het hoort, maar ik vraag me af hoe zoiets komt? Heeft dit ook te maken met de upgrade van de internet-snelheden of staat dat er los van?

[ArcticWolf]

stormfly schreef op vrijdag 22 april 2016 @ 13:03:
[...]


Iets wat je website polst zoals pingdom oid?

Om klapperingen uit te sluiten doe ik altijd twee checks. (Uptimerobot.com en pingdom en dan icmp en http)

Blijkt dus dat de domotica hub geen verbinding kan maken met de 3rd party server (Leaseweb)... niks aan de hand met m'n eigen internet, blijkbaar heb ik de portforwarding ook verkeerd staan, tijdje geleden de ip's gewijzigd van m'n apparaten /noob

Status
System Up Time 34 days 12h:11m:14s

Correctables Uncorrectables
41 0

Counter
T3 Timeout 0
T4 Timeout 1

[ Voor 11% gewijzigd door ArcticWolf op 22-04-2016 13:29 ]

[Anoniem: 757487]

Na een week nog niks gehoord te hebben het nummer van de BAM maar ff gegoogeld en binnen 10 minuten een afspraak gemaakt voor volgende week vrijdag. Ongelofelijk dat het allemaal zo lang moet duren. Ik hoop nu echt dat ik volgende week vrijdag geen enkel blokje meer in mijn beeld heb en dat de waardes in mijn modem goed zijn en blijven. Ik hou jullie op de hoogte.

ArcticWolf schreef op maandag 18 april 2016 @ 08:32:
[...]

Hopen dat ze snel die kabel gaan vervangen
Die monteur heeft geen datum genoemd zeker?

[martijnm71]

Zo mijn probleem ook opgelost, router gekocht bij de lokale computerwinkel

Had geen zin om Ziggo ook nog eens te belonen voor een brakke modem/router door bij hun iets te kopen, dan geef ik liever iets meer uit en ondersteun een lokale computerwinkel.

[voske]

voske schreef op vrijdag 22 april 2016 @ 06:49:
Gisteren in een spontane bui de klantenservice van Ziggo gebeld (ik had beter eerst dit topic kunnen lezen, maar goed ...): de internetverbinding viel de afgelopen weken heel vaak kort weg, met name overdag. Volgens de medewerker van de klantenservice zou het in bridge modus zetten van de modem het probleem oplossen. Dat is echter niet het geval. Mijn eerste ingeving is om de coax-kabel tussen het AOP en de modem morgen te vervangen en, als dat niet helpt, weer contact op te nemen met de klantenservice.

De score over de afgelopen 19 uur:
6739 correctables
6908 uncorrectables
10 T3 timeouts (waarvan 4 tussen 23.30 uur en 06.30 uur)
1 T4 timeout

Misschien te vroeg geklaagd: afgelopen 14 uur zijn er geen time-outs meer bijgekomen en ook de (un)correctables vallen heel erg mee.

Nu alleen nog even een router halen waar ik de DNS op kan instellen (ervan uitgaande dat dat werkt bij een modem in bridge modus, daar lees ik verschillende berichten over).

[stormfly]

voske schreef op vrijdag 22 april 2016 @ 20:47:
[...]


Nu alleen nog even een router halen waar ik de DNS op kan instellen (ervan uitgaande dat dat werkt bij een modem in bridge modus, daar lees ik verschillende berichten over).

Als jij er een modem achter zet met een eigen DHCP server dan zal je daar 99% zeker ook een DNS server mee kunnen propageren naar je clients. Als je clients direct een publieke DNS server krijgen dan bypass je de eigen router en het bridge modem qua DNS.

Dus ja het kan

[stormfly]

ArChie schreef op vrijdag 22 april 2016 @ 10:14:
[...]
DOCSIS heeft een aantal packet soorten gedefinieerd zoals o.a. packets voor DOCSIS management berichten en packets voor de doorgifte van andere protocollen. In de praktijk zal een ontvanger meerdere DOCSIS packets moeten combineren om bijvoorbeeld tot een DOCSIS Management bericht of TCP packet te komen. Als dan één van die onderliggende DOCSIS packets corrupt is (uncorrectable) dan gaat het hogere level bericht dat uit meerdere DOCSIS packets bestaat dus in zijn geheel verloren.

Even samenvattend of ik de materie goed begrijp:

Om het even tastbaar te maken een TCP/IP packet kan +/- 1470 bytes aan payload hebben en DOCSIS 188 dus je hebt 8 DOCSIS packets nodig voor 1 TCP packet. Stel dat packet 3 van 8 nu wegvalt dan weet DOCSIS hier toch niets van? Maar omdat TCP op een hogere laag detecteert dat het TCP packet niet klopt vraagt het clients OS om een retransmit. En dan komt het hele TCP packet weer in 8 DOCSIS packets naar je toe.

DOCSIS is eigenlijk (als je het vergelijkt) UDPachtig, waarbij je geen controle hebt over de correctheid van de ontvangen berichten aan de overzijde. Het is een bulk stream van data, thats it? Het modem kan wel zelf beslissen (lokale beslissing) dat een pakket corrupt is wat hij zojuist ontving? Begrijp ik jouw tekst dan goed dat in de payload van 188bytes zowel DOCSIS momt pakketten kunnen zitten + eventuele datapaletten van de gebruiker? Of zijn die altijd gescheiden maar kunnen wel uit meerdere unieke DOCSIS packets bestaan?

Wat merk je als gebruiker van een T3 error en dezelfde vraag voor een T4 error? Want dit kan ook slechts een administratieve handeling/foutmelding zijn terwijl je datapackets wel goed aan kwamen op dat specifieke moment maar je mgmt packets niet.

[Aggressor]

Aggressor schreef op dinsdag 05 april 2016 @ 16:49:
Ik had me ook aangemeld voor ziggo.
Dag later kreeg ik de bevestigingsmail en hier stond een heel ander adres op... Ergens in het zuiden van het land. Terwijl ik in het noorden woon...

Het viel mij op door het netnummer van de vaste telefonie..Ben toen ik naar onderen scrolde zag ik het.... (Rest klopte wel. Naam, Bankrekeningnummer enz)

Vervolgens meteen ziggo weer gebeld... En deze zou geannuleerd worden en ik moest me weer opnieuw aanmelden.
30min aan de lijn gehangen met ziggo.

Hopelijk wordt niet alles 2x afgeschreven straks..... ( ze zeggen van niet)

Nou, ik heb wel 3x achteraangebeld...
ze beloofden dat alles goed zou komen ....

En nu kijk ik bij mijn Rabobank, en dan zie ik een automatisch incasso met het oude/verkeerde klantnummer......
alles wordt straks gewoon 2x afgeschreven ... wat nu????

morgen kan ik wel weer bellen, maar heeft iemand nog tips?

[ Voor 6% gewijzigd door Aggressor op 22-04-2016 22:21 ]

[hjs]

Webcare op twitter of facebook.
En ik zou het stoneren.

[Aggressor]

Ja ,, weer met de klantenservice gebeld.. volgens mij komt het weer neit goed.. ik word er echt gek van...
Pff

zal zo maar eens een twitter aanmaken voor de webcare. (ik heb geen fb en twitter)
Maar een dag later zag ik dus dat er totaal een verkeerd adres opstond... (adres ken ik helemaal neit)
Meteen gebeld, en toen beloofde ze dat alles goed zou komen. (deze klantnr verwijderen en een nieuwe aanmaken)

En een week later wordt het pakketje gewoon verstuurd naar het onbekend adres... en een dag later ook naar het goeie adres. (dus 2 klantnummers) .. zag ik via de tracktrace link die ik in mijn email kreeg.

[ArChie]

stormfly schreef op vrijdag 22 april 2016 @ 21:13:

Om het even tastbaar te maken een TCP/IP packet kan +/- 1470 bytes aan payload hebben en DOCSIS 188 dus je hebt 8 DOCSIS packets nodig voor 1 TCP packet.

Het exacte aantal benodigde packets kan mogelijk anders zijn, want ieder packet van 188 bytes (is een MPEG packet) heeft ook nog die vaste MPEG header van 4 bytes en voor DOCSIS zelf is er ook nog sprake van een header waarin o.a. de MAC adressen van zender en ontvanger zijn vermeldt, het type DOCSIS packet en de grootte. Voor je voorbeeld gaan we uit van 8 packets.

Onderstaande screenshot laat 4 van die MPEG packets zien:


De MPEG header van 4 bytes is blauw gemarkeerd en de 0xFF bytes aan het einde van sommige packets zijn filler bytes om de DOCSIS payload op te vullen tot een volledig MPEG packet van 188 bytes. MPEG packet #1 en #4 bevatten beide een vrij kleine DOCSIS packet als payload en MPEG packets #2 en #3 bevatten samen als payload een DOCSIS packet dat net niet past in één MPEG packet.

Stel dat packet 3 van 8 nu wegvalt dan weet DOCSIS hier toch niets van?

DOCSIS weet daar wel van omdat de onderliggende hardware/firmware het packet niet konden herstellen (een uncorrectable). Er zitten allerlei controle mogelijkheden ingebouwd in de packets. Omdat de stream een eindeloze bitreeks is heeft de ontvanger dat ook nodig om bij verstoringen weer opzoek te gaan naar een nieuw begin van een MPEG packet. De 0x47 byte (is de sync byte) die je als eerste byte in de blauw gemarkeerde header van elk MPEG packet ziet heeft de ontvanger daarvoor bijvoorbeeld nodig. Ook klopt de volgnummering van de MPEG packets niet meer. De DOCSIS specificatie zegt er het volgende over:

C.2 MPEG Header Synchronization and Recovery in the European Technology Option
When implementing the second physical layer technology option referred to in Section 1 (1.1 Introduction and Purpose) and specified in Annex B, modifications described in EN 300 429 [EN 300 429] apply to the transport stream format.
The MPEG-2 packet stream SHOULD be declared "in frame" (i.e., correct packet alignment has been achieved) when five consecutive correct sync bytes, each 188 bytes from the previous one, have been received.
The MPEG-2 packet stream SHOULD be declared "out of frame", and a search for correct packet alignment started, when nine consecutive incorrect sync bytes are received.

Alleen volledige DOCSIS packets die zijn samengesteld uit één of meerdere MPEG packets worden verder verwerkt door de volgende protocol implementatie lagen.

Maar omdat TCP op een hogere laag detecteert dat het TCP packet niet klopt vraagt het clients OS om een retransmit. En dan komt het hele TCP packet weer in 8 DOCSIS packets naar je toe.

In geval van het TCP voorbeeld mist de TCP laag dus een volledig TCP packet en zal vragen om een retransmit. Bij andere protocollen zal er geen sprake te zijn van een retransmit als er bij zo'n protocol geen sprake is van een gegarandeerde aflevering.

DOCSIS is eigenlijk (als je het vergelijkt) UDPachtig, waarbij je geen controle hebt over de correctheid van de ontvangen berichten aan de overzijde. Het is een bulk stream van data, thats it? Het modem kan wel zelf beslissen (lokale beslissing) dat een pakket corrupt is wat hij zojuist ontving?

Klopt.

Begrijp ik jouw tekst dan goed dat in de payload van 188bytes zowel DOCSIS momt pakketten kunnen zitten + eventuele datapaletten van de gebruiker? Of zijn die altijd gescheiden maar kunnen wel uit meerdere unieke DOCSIS packets bestaan?

Een nieuw DOCSIS packet begint altijd als payload van een nieuw MPEG packet (vandaar dat opvullen met 0xFF bytes) zodat iedere ontvanger in het coaxsegment altijd eerst kan synchroniseren op het begin van een MPEG packet en vervolgens op basis van de DOCSIS header kan bepalen of het DOCSIS packet als payload van één of meerdere MPEG packet bestemd is voor het modem of daarop aangesloten apparatuur. Zo niet, dan die MPEG packet reeks genegeerd worden.

Het modem bij de klant is dus ook nooit in rust. Het verwerkt continu MPEG packets met een constante bitrate van iets meer dan 51 Mbps. Zie onderstaand een voorbeeld van de Internet downstream op 338 MHz zoals die binnenkomt op alle AOP's in mijn coaxsegment:


De MPEG packet met PID 0x1FFE bevatten de DOCSIS payload. De packets met PID 0x1FFF kan zijn de NULL packets die door het modem genegeerd kunnen worden. Rechts onder zie je de totale data rate van de stream die dus gebaseerd is op een packet grootte van 188 bytes. De gebruikte DVB-C hardware/firmware/drivers laten dus niet de packets zien voor de Reed-Solomon error correctie wanneer ze nog 204 bytes groot zijn. De gebruikte TS Analyzer tool gaat overigens uit van het DVB protocol en weet dus niet dat deze MPEG packets worden gebruikt voor de doorgifte van het DOCSIS. Vandaar de '?' in de kolom voor de stream type. In de DOCSIS specificatie is aangegeven dat alleen PID 0x1FFE gebruikt wordt terwijl bij DVB allerlei PID's gebruikt worden.

Toevallig had het signaal in mijn coaxsegment zojuist weer even een kleine hickup (uncorrectables) en dan zie je volgende in de gebruikte tool:


Op de MPEG laag is dus door de gebruikte tool vastgesteld dat er 4 MPEG packets ontbreken en bij het opnieuw synchroniseren heeft de tool kennelijk nog een 0x47 sync byte gevonden die een vreemd packet met PID 0x15AC opleverde. Zoals gezegd is de gebruikte tool eigenlijk bedoeld voor DVB analyse, dus zal men zich niet netjes houden aan bovenstaande DOCSIS synchronisatie regel om minimaal 5 opeenvolgende 0x47 bytes te hebben gehad op 188 bytes intervallen.

Wat merk je als gebruiker van een T3 error en dezelfde vraag voor een T4 error? Want dit kan ook slechts een administratieve handeling/foutmelding zijn terwijl je datapackets wel goed aan kwamen op dat specifieke moment maar je mgmt packets niet.

Zoals aangegeven stuurt een modem met vaste intervallen een ranging request via de upstream naar de CMTS en verwacht dan binnen een bepaalde tijd een ranging response van de CMTS terug via de downstream. Als dat niet gebeurt start het modem een retry loop waarbij weer een ranging request naar de CMTS wordt verstuurd en er weer gewacht wordt op een ranging response. Die retry loop wordt dan een aantal keer herhaald (volgens Volpe 16 keer) en als er dan nog steeds geen response binnen is van de CMTS registreert het modem een T3 timeout en moet ervan uit gaan dat de verbinding met de CMTS niet in orde is.

In een poging om dat op te lossen wordt opnieuw het registratie proces bij de CMTS doorlopen waarbij dus ook alle eerder geconfigureerde downstreams en upstreams opnieuw worden gekoppeld (de CMTS bepaalt immers ook van welke streams het modem gebruik van mag maken). Tijdens die registratie wordt er geen gebruiker data verkeer afgehandeld, dus als de gebruiker op een dergelijk moment iets op het internet aan het doen was komt er dan even geen reactie en als er sprake was van actieve verbindingen met servers kan het zijn dat die verbindingen een timeout geven.

Voor een T4 timeout geldt een functioneel gezien een andere DOCSIS aanleiding, maar ook daar is sprake van een aantal keer opnieuw proberen en wil het uiteindelijk nog niet lukken moet het modem weer uitgaan van een slechte verbinding en het registratie proces opnieuw doorlopen. In beide gevallen toont de modem status pagina slechts een telling van het aantal voorkomens van T3/T4 timeouts en moet je op de log pagina van het modem kunnen zien op welk tijdstip de T3/T4 timeout is opgetreden. Dit zal aangemerkt zijn als een critical fout omdat op dergelijke momenten de service voor de gebruiker onderbroken wordt.

Zie de volgende pagina van Volpe voor uitleg van meer DOCSIS timeouts:
http://volpefirm.com/docsis_timout_descriptions/

[Aggressor]

hjs schreef op vrijdag 22 april 2016 @ 22:57:
Webcare op twitter of facebook.
En ik zou het stoneren.

Hjs,

Bedankt voor je advies, ik heb speciaal een twitter account aangemaakt.
En ik heb het hele verhaal in een prive bericht naar de ziggo webcare toegestuurd.
(iets van 3a4 a4tjes vol)
Hij ging er meteen mee bezig, en binnen een uur werd ik teruggebeld....
Hij zei zelf nog van "pff wat een verhaal"

Ook zou hij proberen om het pakket wat naar het verkeerd adres is gestuurd om dit terug te krijgen. (maar dit was niet mijn probleem zei die)

En als compensatie zou hij iets sturen, en dit zou voor Koningsdag nog binnenkomen.
(waarschijnlijk bloemen of iets denk ik?)

Hopelijk is het zo opgelost...

[ANdrode]

ArChie schreef op zaterdag 23 april 2016 @ 09:18:
[...]

Zie de volgende pagina van Volpe voor uitleg van meer DOCSIS timeouts:
http://volpefirm.com/docsis_timout_descriptions/

En ook een blog post van Excentis "Ranging – Feeling the 2 bpm DOCSIS heartbeat".

Deze omschrijft de verschillende scenario's van hoe een T3 timeout kan ontstaan.

Helaas spreken deze twee artikelen elkaar wel tegen . Bij Excentis is elke keer dat een modem niet op tijd een RNG-RESP ontvangt een T3 timeout.

Aan het einde van de blog post wordt er ook kort genoemd wat je met de T3/T4 timeouts van de populatie aan kabelmodems van een CMTS kan zien. Hóe je dat dan gebruikt leggen ze graag uit in een cursus .

[ArChie]

ANdrode schreef op zaterdag 23 april 2016 @ 19:36:
[...]


En ook een blog post van Excentis "Ranging – Feeling the 2 bpm DOCSIS heartbeat".

Deze omschrijft de verschillende scenario's van hoe een T3 timeout kan ontstaan.

Goed gevonden artikel. In mijn coaxsegment zie ik om de ongeveer 15 seconden een ranging response van de CMTS naar ieder modem langskomen. Voor een DOCSIS protocol analyses maak ik daarom altijd captures van 45 seconden van iedere downstream om twee tot drie ranging responses per modem vast te leggen in zo'n capture.

Helaas spreken deze twee artikelen elkaar wel tegen . Bij Excentis is elke keer dat een modem niet op tijd een RNG-RESP ontvangt een T3 timeout.

Inderdaad, het wordt er zo niet duidelijker op. Aangezien Excentis zich ook met testen van DOCSIS apparatuur bezig houdt neig ik nu naar hun uitleg, maar eigenlijk zou daarvoor dieper gespit moeten worden in de DOCSIS specificaties. Wel zijn ze het erover eens dat het modem het na 16 keer voor gezien houdt. Hoe dan ook, lekker is het niet.

[PauseBreak]

supermm958 schreef op vrijdag 22 april 2016 @ 08:43:
[...]


Ik weet het niet, gisteren was het een drama. Meerdere keren per uur uitval. Smokeping leek wel een spam bot.

Capaciteits probleem zal haast niet kunnen zal je denken sinds ze met terugloop van klanten te maken hebben (volgens berichten in media)

Ik heb het idee dat Ziggo geen idee heeft wat de problemen veroorzaakt.
Die indruk krijg ik niet vanuit ziggo en het contact wat ik heb met Ziggo.
Nu moet ik mijn modem weer uit bridge halen en testen. Voelt een beetje als trial & error.
Ziggo verzocht om de modem waardes en logs van modems in mijn buurt ook eens preventief uit te lezen. Nog geen reactie.

Ik lees in diverse foras mensen met dezelfde problematiek, maar tot dusver geen oplossing.

Bij mij begint het inmiddels wel een irritatie punt te worden.

Bij mij zijn die problemen al aanwezig sinds eigenlijk de overname van fZiggo door UPC, en daarna nog verergerd na de DNS-DDoS die ze hadden vorig jaar. Als het signaal uitgelezen wordt is er natuurlijk ook nooit iets zichtbaar (sterker nog, het signaal is vrijwel altijd zo ongeveer perfect wat ze willen zien), en ook in de pingmachines zeggen ze niks te kunnen zien maar de timeouts zijn er wel degelijk (ik krijg niet voor niet een timeout error op verschillende sites en streams gaan niet voor niets 'stotteren' (heel veel bufferen kort na elkaar)).

Maar, eerlijk is eerlijk, met de Technicolor TC7210 in bridgemode is het probleem wel echt met een factor 10 kleiner geworden. Het is zeker niet weg, maar de verbinding is nu in ieder geval weer stabiel genoeg om op te kunnen werken en zonder gedoe Netflix te kunnen streamen.

En als ik zou mogen speculeren, en dat mag ik , gok ik dat er gewoon verkeerd is bezuinigd door UPC. Bij fZiggo zelf had ik echt nooit dit soort problemen, terwijl exact deze problematiek wel voorkwam en voorkomt in UPC-gebieden. Het lijkt mij dus ook dat het gewoon ergens fout zit hoger in het netwerk van UPC zelf. En dus ook dat wij als klanten daar verder niet veel aan kunnen gaan veranderen.

[ANdrode]

ArChie schreef op zaterdag 23 april 2016 @ 20:25:
[...]
Inderdaad, het wordt er zo niet duidelijker op. Aangezien Excentis zich ook met testen van DOCSIS apparatuur bezig houdt neig ik nu naar hun uitleg, maar eigenlijk zou daarvoor dieper gespit moeten worden in de DOCSIS specificaties. Wel zijn ze het erover eens dat het modem het na 16 keer voor gezien houdt. Hoe dan ook, lekker is het niet.

En dan is er nog terminologie; T3-timeout ten opzichte van T3-error. Mogelijk betekent error iets heel anders dan timeout.

n T3 timeouts -> T3 retries exceeded? "Ranging is niet gelukt"
T4 timeout: "Er is geen ranging mogelijkheid aangeboden in het geconfigureerde window."

Gelukkig zijn de standaarden vrij beschikbaar. Dat betekent alleen niet dat het begrijpelijker wordt .