1
Vraag
2
Reacties
PeterM030

Level 1
  • 15Posts
  • 1Oplossingen
  • 0Likes

Ten einde raad: VOIP valt regelmatig weg, met regelmaat "Request timeout" in ping

Wij hebben sinds een paar maanden Gigabit internet van Ziggo, lekker snel! Je zou verwachten dat iets redelijk simpels als VOIP daarop prima zou moeten werken, maar inmiddels heb ik wel geleerd dat er meer bij komt kijken dan pure snelheid.

Via DSLReports terecht gekomen bij de term ‘Bufferbloat’, en daarom een nieuwe router gekocht (Netgear R78000) waarbij ik gebruik kan maken van Smart Queue Management. Daarmee dacht ik het probleem wel even op te kunnen lossen. 

Helaas blijft het uitgaande geluid van onze VOIP verbinding af en toe weg vallen, waardoor delen van zinnen niet hoorbaar zijn voor de andere kant, en de DSLReports meting blijft regelmatig een flinke Bufferbloat aangeven…

Situatie:
Ziggo connextbox in bridge modus
Netgear R7800 met OpenWRT (SQM aan of uit, maakt niet zoveel verschil)
Gigaset VOIP toestel via Ethernet aan Netgear
Macbook via Ethernet aan Netgear
(WIFI netwerk uitgeschakeld, om problemen daarmee uit te sluiten)

Nu merk ik het volgende: als ik op mijn Macbook een ping doe op bijvoorbeeld: google.com dan krijg ik prima ping tijden, zo rond de 9ms met soms een uitschieter naar 16ms… helemaal prima. Maar zo nu en dan krijg ik de melding ‘Request timeout for icmp_seq xxx’ En laat dat nu precies tegelijkertijd met het wegvallen van het geluid via het VOIP toestel.

En met zo nu en dan bedoel ik:

--- google.com ping statistics ---

509 packets transmitted, 469 packets received, 7.9% packet loss

round-trip min/avg/max/stddev = 8.173/9.758/18.949/1.727 ms


Hoe kan ik bepalen waar die timeouts vandaan komen, en is er iets dat ik kan doen om dat op te lossen?

Tijdens ‘gewoon’ internetten en netflixen heb je dit niet door, maar tijdens een VOIP gesprek is dit natuurlijk erg vervelend...

Mocht er iemand zijn die hier iets meer verstand van heeft… HELP! 🙂

Oplossing

Geaccepteerde oplossingen
PeterM030
Topicstarter
Level 1
  • 15Posts
  • 1Oplossingen
  • 0Likes

Even een update voor de geïnteresseerden, nadat de monteur van Ziggo langs is geweest vandaag.

Het korte verhaal: mijn grootste probleem is opgelost.
_____________________________________________

Maar met de “techniek van tegenwoordig” is het echte verhaal iets ingewikkelder, en het probleem eigenlijk nog niet helemaal opgelost… maar ik kan er mee leven 😉

De monteur heeft de aansluitingen, koppelstukken etc vervangen. Zoals ik wel vaker lees… bijna standaard procedure. Deze techneuten zijn er op gebrand om de kwaliteit van het signaal an sich te verbeteren… Tegelijkertijd vond hij bij de metingen een probleem in de kabel naar de wijkcentrale. Dat is iets wat met graafwerk waarschijnlijk opgelost gaat worden (wachten op vergunningen en dat soort zaken...)

“Toevallig” had hij ook een Ubee modem bij zich, en hij was wel bereid om de standaard connectbox te vervangen door dit wifi-loze modem. Direct daarna mijn ping weer aan het werk gezet en wat blijkt: 0% packet loss! YAY!

Wat een beetje jammer is, is dat we voor de swap niet even getest hadden. Naast de nieuwe koppelingen had hij ook een puls door de kabel gegeven. Blijkbaar kun je tijdelijk het signaal in de kabel even strak zetten door er een flinke puls doorheen te geven (even in mijn woorden uitgelegd), alleen is dat iets dat langzaam weer uitwerkt en dus slechts voor een korte periode effect heeft.

Alles aardig en wel, met 0% packet loss was ik natuurlijk zo blij als een kind en kon eindelijk storingsvrij Skypen, voip-en etc.

Dat was helaas van korte duur… ineens was de packet loss weer terug.

Conclusie:
Blijkbaar lag het toch niet aan de connectbox (?)
Misschien heeft de kwaliteit van de kabel toch iets met dit probleem te maken(?)

Er wordt in ieder geval een afspraak gemaakt om aan die kabel buiten te gaan werken. 
________________________________________

Maar…. ik geef niet zomaar op. Na een hoop puzzelen heb ik nu twee routers achter mijn Ubee gehangen, één oude waarop het VOIP toestel is aangesloten, en mijn nieuwe Netgear waar de rest van mijn netwerk aan hangt.

Via die oude router haal ik de 1Gigabit internet snelheid niet, maar dat is voor VOIP ook niet nodig. En verrassing: via dit netwerk 0% packet loss!

Via de nieuwe router haal ik die 1Gigabit wel (bijna), met de inmiddels bekende packet loss… maar dat is voor mijn reguliere internet verkeer niet zo’n probleem.

Ik kan nu dus storingsvrij bellen (en gamen) via mijn oude router, dat is een opluchting.

Nieuwe conclusie, hoe verwarrend ook:
Ubee → Oude router → geen packet loss
Ubee → nieuwe router → wel packet loss

Dus dan rijst de vraag: zou het dan ergens aan mijn Netgear router moeten liggen?
In eerste instantie dus niet, want ook daarmee begon het gewoon netjes met volledig stabiel netwerkverkeer…

Waarom het via die oudere router (een Airport Extreme van Apple) dan wel werkt… geen idee… misschien juist omdat die niet zo’n hoge snelheid probeert te halen?


Ik weet het niet, maar de haperende telefoonverbinding is opgelost, en daar ben ik heel blij mee.

In de tussentijd kan ik lekker aan die Netgear router gaan knutselen (firmware aanpassen, instellingen tweaken etc… terwijl mijn VOIP telefoon het doet en via de Airport Extreme internet ook beschikbaar blijft).
_____________________

Hartelijk dank aan iedereen die heeft meegedacht!

Bekijk in context

26 Reacties 26
PeterM030
Topicstarter
Level 1
  • 15Posts
  • 1Oplossingen
  • 0Likes

Na nog wat meer lezen ook geprobeerd om te pingen naar:
Mijn router: 192.168.1.1 → Geen enkele timeout
Mijn connectbox: 192.168.178.1 → Geen enkele timeout

Naar buiten (google.com, 8.8.8.8 etc): 10% of meer packet loss 

Mag ik dan aannemen dat het binnen mijn netwerk op zich netjes is, en dat het probleem verder in het netwerk van Ziggo moet liggen? Of zijn er nog meer dingen waar ik zelf invloed op kan uitoefenen?

jarielcapitain

Level 13
  • 778Posts
  • 31Oplossingen
  • 244Likes

 

Je kan in ieder geval proberen om  de ping te loggen. Enter onderstaande lijn in de terminal.

ping -i 3 8.8.8.8 | while read line ; do echo "$(date): $line" >> ~/Desktop/pinggoogle.txt; done;

Dit log al je ping in een bestand met een timestamp op je desktop met een interval van 3 seconden ( -i 3). Deze kan je aanpassen.

Wanneer je klaar bent met loggen 

grep -e "Request time out" ~/Desktop/pingggoogle.txt > ~/Desktop/result.txt

Als je het bestand bewaren wilt gebruik dan een andere bestandsnaam. 

Controleer vervolgens in de log van de connectbox of er meldingen van uitval zijn op dit tijdstip.

 

PeterM030 wrote:


Mag ik dan aannemen dat het binnen mijn netwerk op zich netjes is, en dat het probleem verder in het netwerk van Ziggo moet liggen? Of zijn er nog meer dingen waar ik zelf invloed op kan uitoefenen?

Je hebt alles geprobeerd. VOIP zou gewoon moeten werken.

PeterM030
Topicstarter
Level 1
  • 15Posts
  • 1Oplossingen
  • 0Likes

Nu ook aan de pingplotter gegaan… dat levert wel een heel onprettig beeld op… Wat zouden jullie hier uit opmaken?

 

 

efok

Level 17
  • 4014Posts
  • 219Oplossingen
  • 1594Likes

Ik zie even inloggen in je modem en de up en downstream waarden daar even bekijken. https://community.ziggo.nl/deel-je-tips-en-suggesties-91/waar-vind-ik-de-up-en-downstreamwaardes-van...
 

Check ook even de logs van je modem.

PeterM030
Topicstarter
Level 1
  • 15Posts
  • 1Oplossingen
  • 0Likes

 

efok wrote:

Ik zie even inloggen in je modem en de up en downstream waarden daar even bekijken. https://community.ziggo.nl/deel-je-tips-en-suggesties-91/waar-vind-ik-de-up-en-downstreamwaardes-van...
 

Check ook even de logs van je modem.

Bij deze…

 

 

ArChie.DVB

Level 1
  • 1306Posts
  • 19Oplossingen
  • 552Likes

Weer een prachtig voorbeeld van het werk van Ziggo/LGI scriptkidies die geen flauw benul hebben waar ze mee bezig zijn anders bied je een apparaat met zoveel fouten in de gebruikersinterface niet aan klanten aan. Wat een prutsers.

PeterM030
Topicstarter
Level 1
  • 15Posts
  • 1Oplossingen
  • 0Likes
ArChie.DVB wrote:

Weer een prachtig voorbeeld van het werk van Ziggo/LGI scriptkidies die geen flauw benul hebben waar ze mee bezig zijn anders bied je een apparaat met zoveel fouten in de gebruikersinterface niet aan klanten aan. Wat een prutsers.

tjah… die gegevens hadden vast wat gebruiksvriendelijker weergegeven kunnen worden… maar het zijn de gegevens waar het om gaan 😉

efok

Level 17
  • 4014Posts
  • 219Oplossingen
  • 1594Likes

Toch kan ik er niet direct uithalen waarom je packet loss zou hebben. Alle streams lijken mij in orde.

ArChie.DVB

Level 1
  • 1306Posts
  • 19Oplossingen
  • 552Likes

Met fouten doel ik natuurlijk niet op de gebruiksvriendelijkheid van de interface, maar op de bruikbaarheid van de informatie in de interface.

Laten we voor de aardigheid de getoonde schermprints onder de loep nemen.

Alle informatie die in deze sectie van de interface getoond wordt heeft betrekking op het (Euro)DOCSIS modem deel van het apparaat, dus Modem status i.p.v. Router status. Verder zou je gezien het vertalen van de labels op tabbladen Status en Configuratie ook mogen verwachten dat het Netwerk log is i.p.v. Networklog. Overigens een slechte naam voor de gegevens die op dat tabblad getoond worden, want al die meldingen zijn afkomstig van het modem deel van het apparaat, dus DOCSIS log is een benaming die overeenkomt met de daadwerkelijke inhoud.

 

 

De eerste kolom Kanaal is een volgorde nummering van de kanalen zoals die door het modem gehanteerd wordt voor de te koppelen kanalen. Dit modem kan 32 EuroDOCSIS 3.0 kanalen koppelen, dus verwachten we een volgnummering van 1 tot 32. Waar is kanaal 1 gebleven en waarom gaan ze opeens de volgorde aanpassen? Hier is duidelijk een bug in de interface zichtbaar. Uitgaande van de specifieke gegevens die hier getoond worden en wat kennis van de frequentieplannen die door Ziggo gehanteerd worden is namelijk af te leiden dat het modem initieel op kanaal 1 de downstream met frequentie 602 MHz (602000000 Hz) had gekoppeld als primary downstream. Later is heeft het modem kennelijk de instructie gekregen om de downstream op frequentie 618 MHz te gaan gebruiken als primary downstream en heeft men in de interface de regel voor de downstream op 602 MHz overschreven. Ofwel we moeten nu een interpretatie gaan toepassen om een volledig beeld te krijgen van hetgeen het modem gekoppeld heeft en wat nu de primary downstream is. Aangezien de primary downstream in DOCSIS een zeer belangrijk concept is nogal een behoorlijke interface bug die gemist is door Ziggo/LGI.

De Frequentie kolom toont de waarden in Hz. Gelukkig komen in dit geval de waarden in de kolom overeen, maar eigenlijk niet erg leesbaar. Met iets meer moeite had men van die 618000000 Hz in de gebruikersinterface ook 618000 kHz van kunnen maken.

De Vermogen kolom toont de waarden in dBmV. De waarden worden hier met een nauwkeurigheid van maar liefst 6 cijfers achter de komma getoond. Dit heeft niets van doen met de nauwkeurigheid van het modem om de downstream signaalsterkte te kunnen meten, maar is gewoon luiheid om in de gebruikersinterface de boel even netjes af te ronden op 1 cijfer achter de komma. Zelfde geldt voor de kolom met SNR waarden in dB.

De laatste Kanaalnummer kolom toont de DOCSIS identificatie nummers van de downstream kanalen die door de CMTS worden bepaald. Daarom had Kanaal ID een betere naam geweest voor de informatie die hier getoond wordt en had vermoedelijk ook de bug kunnen voorkomen die nu de Ziggo/LGI scriptkiddie op het verkeerde been heeft gezet en er voor gezorgd heeft dan downstream kanaal met frequentie 602 MHz uit de interface is verdwenen.

 

Wederom: waar is de informatie van kanaal 1 gebleven en hoe kan het dat dit niemand van Ziggo opvalt? Wordt er niet getest?

In de RxMER kolom worden de waarden in dB getoond. Is een RxMER van 0 dB normaal of is dit weer door Ziggo/LGI gemiste bug? Ik denk het laatste. Wat is een RxMER van 203892515 dB. Weer een bug. Wederom moeten we maar wat gaan interpretatie toepassen naar wat voor waarden we hier eigenlijk zitten te kijken. Zouden dit soms de Fouten voor RS zijn en heeft men dus gewoon de informatie in de verkeerde kolommen geplaatst. Dan zullen de waarden in de kolom Fouten voor RS wel thuishoren in de kolom Fouten na RS. Nog meer gemiste bugs. Lekker testwerk van Ziggo/LGI en goede informatie voor de monteurs…

 

Dit modem kan twee DOCSIS 3.1 downstream kanalen en twee DOCSIS 3.1 upstream kanalen koppelen. Dit is qua techniek niet te vergelijken met de werking EuroDOCSIS 3.0 kanalen. Waarom Ziggo/LGI er voor kiest om bij de volgnummering in de eerste komen door te nummeren is mij en raadsel. Noem dat gewoon Kanaal 1 en 2 en toon ook de niet gekoppelde kanalen, want met alle bugs die de scriptkiddies van Ziggo/LGI veroorzaken zou het misschien zomaar kunnen zijn dat er wel twee DOCSIS 3.1 kanalen zijn. Nu kunnen we er alleen maar naar raden. En waarom besluit het scriptkiddie dat in in elkaar geprutst heeft om in de het tweede deel van de informatie de kolom Kanaal nu opeens weer Kanaalnummer te noemen. In vergelijking met de EuroDOCSIS 3.0 kanalen bevatte Kanaalnummer toch het ID van het dwonstream kanaal? Daar is bij DOCSIS 3.1 geen sprake van. Nog meer verwarring.

In de kolom Kanaalbreedte worden de waarden dit keer in MHz getoond. Waarom niet in Hz zoals in de rest van de gebruikers interface? Is de kleinst mogelijke kanaalbreedte voor een DOCSIS 3.1 kanaal wel in MHz uit te drukken of worden de waarden dan met één of meer cijfers achter de komma getoond?

Aantal actieve subcarriers had ook volledig vertaald kunnen worden in Aantal actieve hulpdraaggolven. In de kolom Eerste Actieve Subcarrier worden de waarde in Hz getoond. Natuurlijk is de eerst actieve hulpdraaggolf van dit DOCSIS 3.1 kanaal niet te vinden op 879 Hz, maar op 879000000 Hz en dat gecombineerd met de informatie over de kanaalbreedte in MHz leert ons dus dat Ziggo het eerste DOCSIS 3.1 kanaal doorgeeft in het frequentiegebied van 879 MHz tot 1009 MHz. Waarom ze dit frequentiegebied gekozen hebben is mij overigen ook een raadsel. Als ze er namelijk bewust voor zouden kiezen om dat eerste DOCSIS 3.1 downstream kanaal binnen de 1006 MHz te houden dat volgens de EuroDOCSIS 3.0 specificaties ook kan worden ingezet als optioneel frequentiegebied voor downstream kanalen, dan overschreiden ze die bovengrens nu met 3 MHz. Nu maar hopen dat er in de coax infrastructuur tussen CMTS en AOP geen versterkers staan die alleen geschikt en getest zijn voor die EuroDOCSIS 3.0 uitbreiding. Hier in mijn omgeving komen in de straatkasten nog voldoende Hirschmann versterkers voor die tot 1006 MHz ondersteunen volgens de specificaties van Hirschmann. Hopelijk leidt dat straks niet tot allerlei verstoringen in het DOCSIS 3.1 kanaal…

De RxMER Data in dB kolom is leeg. Weer een bug? PLC Power in dBmV netjes met één cijfer achter de komma. Ze kunnen het dus toch wel als ze het willen. Tja en dan de naamgeving van de Correcteds en Uncorrectables kolommen. Waarom heet dat niet Correcteds en Uncorrecteds?

 

Bij de EuroDOCSIS 3.0 upstream kanalen zijn veelal dezelfde opmerkingen te plaatsen. Dit keer lukt het ze wel om de kanaal volgorde in de Kanaal kolom netjes oplopend te laten zijn. Ook hier geldt dat in de laatste Kanaalnummer kolom de ID’s van de upstream kanalen worden getoond zoals geconfigureerd door de CMTS. Dus Kanaal ID is een beter label dan Kanaalnummer.

Hoewel voor de leesbaarheid de waarden in de frequentie kolom wel in kHz getoond zouden kunnen worden heeft het in voor de upstream wel meerwaarde om de waarden Hz te tonen aangezien de CMTS het modem opdracht kan geven om met een kleine offset t.o.v. van de standaard geconfigureerde waarden te zenden. Een monteur kan dan uit afwijkende upstream frequentie waarden afleiden dat het modem upstream problemen heeft.

Ook hier weer veel te veel cijfers achter de komma bij de waarden in de Vermogen kolom. Maakt de boel alleen maar onleesbaar en de hardware het modem heeft helemaal niet een dergelijke nauwkeurigheid. Afronden op twee cijfers achter de komma is meer dan genoeg.

In de kolom Symbol Rate worden de waarden in ksps getoond. Waarom is Symbol Rate niet vertaald in Symboolsnelheid? En waarom toont men nu weer opeens ook een eenheid bij de waarden in de kolom? Die staat toch tussen haakjes boven de kolom? ksps is namelijk hetzelfde als kSym/sec (let op: met een kleine ‘k’ i.p.v. hoofdletter ‘K’). Dus voor de leesbaarheid gewoon de waarde 5120 i.p.v. 5120 KSym/sec.

Ook lachwekkend op hoeveel verschillende manier met het modulatie soort toont. Bij de downstream kanalen zetten ze het getal achter de QAM en bij de upstream kanalen ervoor. Schrijfwijze is gewoon 64-QAM of 256-QAM.

 

 

Zo te zien hebben we bij dit modem weer heel andere EuroDOCSIS 3.0 kanaal soorten dan bij andere EuroDOCSIS 3.0 modems. Onzin natuurlijk, men vindt het kennelijk teveel moeite om dit soort niet standaard DOCSIS programmeer constante waarden van de fabrikant in de API om te zetten in leesbare standaard DOCSIS termen.

 

Ik ga ze niet apart benoemen, maar ook in deze sectie weer een mengelmoes van Nederlands en Engels.

 

Je toont de kolom namen niet, maar ik vermoed dat de getallen het foutmeldingsniveau is. Waarom het teveel moeite was om dat om te zetten in nette labeltjes is mij een raadsel. Misschien een poging om critical meldingen te verbergen in de gebruikersinterface?

 

Conclusie: de gegevens in deze gebruikers interface zijn nauwelijks bruikbaar voor probleem analyses en daar zijn normaliter dergelijke gegevens wel voor bedoeld.

Bert

Level 21
T.E.A.M.
  • 75177Posts
  • 5145Oplossingen
  • 21925Likes

Kun je een foto hier plaatsen van de eerste plaats waar Ziggo je huis binnenkomt met eventuele splitters en versterkers op de foto?

PeterM030
Topicstarter
Level 1
  • 15Posts
  • 1Oplossingen
  • 0Likes

Oeps, per ongeluk aangegeven dat Archie ‘het antwoord’ heeft gegeven… Ach, in ieder geval het meest uitgebreide antwoord ?

PeterM030
Topicstarter
Level 1
  • 15Posts
  • 1Oplossingen
  • 0Likes
Be rt wrote:

Kun je een foto hier plaatsen van de eerste plaats waar Ziggo je huis binnenkomt met eventuele splitters en versterkers op de foto?

Gaat mij vandaag niet meer lukken, en morgen komt er een monteur van Ziggo om de boel eens te bekijken… benieuwd wat daar uit komt.

hanh

Oud Community-lid
  • 17054Posts
  • 661Oplossingen
  • 3463Likes

Niet alleen het langste maar ook zeer relevant.
Als er problemen met de verbinding zijn, dan moet je goede info krijgen van het Modem. Een gemiddelde klant  hoeft hier geen chocola van te maken maar een bescheiden of grotere kenner wel. En daarin zit duidelijk een probleem.
Het maakt troubleshooting lastig zo niet onmogelijk.
Ik vraag me trouwens ook af of de gemiddelde monteur voldoende bagage heeft om goed om te kunnen gaan met de info. Dat is geen schande. Het kan bij een hardnekkig probleem noodzakelijk worden. Ihb als er bv al een derde monteur naar de klant wordt gestuurd.

In wat mindere mate is het idem bij een DOCSIS 3.0 Connectbox.
Ik snap ook niet waarom hier zo slordig en ondeskundig mee wordt omgesprongen. Dat scriptkiddies dit maken, mag voor mijn part wel, maar is er geen senior beschikbaar met goede expertise bij het ontwikkelen van de Firmware? Voor de kwaliteitscontrole. Zou er wel technisch getest zijn in een DOCSIS 3.1 omgeving? Zou idioot zijn als dat niet zo was. Toch vraag je je dit zo onderhand af.

Nu zijn er heel duidelijke problemen, zoals uitval van de verbinding of een instabiele of veel te lage Internetsnelheid. Dan zul je dit wel kunnen zien in de overzichten. Ontbrekende kanalen, uit de hand gelopen dBmV. Van die dingen.
Bij wat vagere problemen kan dieper inzoomen nodig zijn, omdat alles er zo ongeveer wel ok uitziet Dat moet dan wel goed kunnen als je er verstand van hebt.

Jouw probleem is vager, want alles werkt ogenschijnlijk verder goed bij je, behalve VOIP en de opmerkelijke Packet Loss bij google.com in de Pingplotter plot.
Dat zou aan de verbinding kunnen liggen. Maar aan wat?
Voor VOIP kan het nog iets anders zijn.
Wat er verder nog bekeken kan worden bij een VOIP probleem weet ik niet.@DennyW  heb jij nog iets voor dit Topic?

Het antwoord van Archie is niet het ‘Beste’ als het gaat om een directe oplossing van je problemen. Maar wel zeer waardevol. Voor mij althans.
Die DOCSIS 3.1 Modems zijn er nog maar pas, en wat meer techische kennis hierover is noodzakelijk, als je iemand uit de brand wilt proberen te helpen.

 

PeterM030
Topicstarter
Level 1
  • 15Posts
  • 1Oplossingen
  • 0Likes

Ik heb de pings op meerdere apparaten laten lopen, zowel bedraad als via wifi. En ze geven allemaal telkens op hetzelfde moment een request timeout aan.

Begrijp ik goed dat als ik mijn connectbox (192.168.178.1) ping, en overal prima resultaten krijg (wellicht iets langere ping tijden via WiFi dan via ethernet, maar geen packet loss), dat het dan aan mijn netwerkkant in principe goed is, en dat het aan de andere kant van het modem moet liggen?

Dus: bedrading van modem naar contactpunt, of van contactpunt naar centrale, of verder dan dat?

Met mijn beperkte kennis van die resultaten uit de screenshots lijkt mijn signaalsterkte ook wel ok, toch? *zucht* vervelend om gedwongen in al die technische termen te moeten duiken 🙂

Oh, en het probleem is dus niet alleen bij VOIP, maar daarbij wordt het simpelweg ineens erg duidelijk, omdat er zinnen wegvallen… Bij gewoon internetten of Netflix wordt dat via buffers natuurlijk opgelost en merk je er niet zo veel van..

PeterM030
Topicstarter
Level 1
  • 15Posts
  • 1Oplossingen
  • 0Likes

Ah, en een topic gevonden dat erg lijkt op mijn probleem. Die pingplot lijkt ook wel heel erg (bijna 1-op-1) op die van mij: https://community.ziggo.nl/internetverbinding-102/hoge-packet-loss-signaalsterkte-is-in-orde-32454/i...

 

Dat geeft hoop, ik ben dus niet alleen!! 🙂

ArChie.DVB

Level 1
  • 1306Posts
  • 19Oplossingen
  • 552Likes
PeterM030 wrote:

Met mijn beperkte kennis van die resultaten uit de screenshots lijkt mijn signaalsterkte ook wel ok, toch? *zucht* vervelend om gedwongen in al die technische termen te moeten duiken 🙂

Signaalsterkte (door Ziggo/LGI vermogen genoemd) zegt wat over het analoge deel van de data transmissie. Voor DOCSIS modems moet de signaalsterkte tussen bepaalde grenswaarden liggen om te zorgen voor een storingsvrije overdracht van data. De signaalsterkte is niet bepalend voor de snelheid van data verkeer, maar een te zwak of een te sterk signaal kan wel zorgen voor een dusdanig verstoord signaal zodat de data die via het signaal verstuurd wordt door de error correctie algoritmes van het DOCSIS modem niet meer te herstellen is. Veel belangrijker is zijn daarom de Fouten voor en na RS bij EuroDOCSIS 3.0 streams en Uncorrecteds en Uncorrectables bij DOCSIS 3.1 streams. Als die nagenoeg 0 zijn en blijven kan je concluderen dat de signaaloverdracht tussen modem en CMTS niet de oorzaak is voor de problemen (voor zover we tenminste op de informatie kunnen vertrouwen die Ziggo/LGI daarover op de status pagina’s toont en dat is nu net een veelvuldig terugkerend probleem bij alle door de Ziggo/LGI in elkaar geprutste firmwares voor alle modems).

 

PeterM030 wrote:

Oh, en het probleem is dus niet alleen bij VOIP, maar daarbij wordt het simpelweg ineens erg duidelijk, omdat er zinnen wegvallen… Bij gewoon internetten of Netflix wordt dat via buffers natuurlijk opgelost en merk je er niet zo veel van..

Bij VOIP is Quality of Service (QoS) zeer belangrijk om het voice data verkeer een hogere prioriteit te geven. Bij telefonie via een DOCSIS modem wordt PacketCable toegepast en dat verkeer krijgt automatisch tijdelijk een hogere prioriteit dan al het andere verkeer in het coaxsegment zodra de gebruiker de telefoon oppakt om te gaan bellen. Vergeet niet dat de capaciteit in het coaxsegment een gedeeld wordt met alle andere aangeslotenen waardoor andere actieve kabelinternet klanten ervoor zouden kunnen zorgen dat het gesprek gaat stotteren als het voice verkeer geen hogere prioriteit zou hebben.

Dat geldt echter niet voor het VOIP verkeer dat buiten het PacketCable protocol omgaat. Dan is het maar de vraag of Ziggo de boel zodanig geconfigureerd wordt dat het alternatieve VOIP verkeer ook herkend wordt om voorrang te krijgen. Dat zou dan aan de hand van dynamic Service Flow aanpassingen zichtbaar moeten zijn, maar ik zie dat in mijn coaxsegment niet langskomen. Misschien geen VOIP gebruikers in mijn coaxsegment.

PeterM030
Topicstarter
Level 1
  • 15Posts
  • 1Oplossingen
  • 0Likes
ArChie.DVB wrote:

Bij VOIP is Quality of Service (QoS) zeer belangrijk om het voice data verkeer een hogere prioriteit te geven. […..]

Dat geldt echter niet voor het VOIP verkeer dat buiten het PacketCable protocol omgaat. Dan is het maar de vraag of Ziggo de boel zodanig geconfigureerd wordt dat het alternatieve VOIP verkeer ook herkend wordt om voorrang te krijgen. […..]


Dat is wat ik wilde bewerkstelligen met mijn nieuwe router… Als ik met DSLReports.com een meting verricht krijg ik een hoge ‘bufferbloat’ te zien. Met het nieuwe router zou ik SQM kunnen instellen, dat blijkbaar nog iets verder gaat dan QoS.

Het lijkt er alleen op dat die Bufferbloat waarde niet zo hoog is omdat de pingtijden heel hoog zijn, maar omdat er zoveel packet loss is. Als op al het verkeer zoveel packet loss is, dan heeft het natuurlijk geen enkele zin om iets van QoS of SQM in te stellen.

PeterM030
Topicstarter
Level 1
  • 15Posts
  • 1Oplossingen
  • 0Likes
PeterM030 wrote:

Ah, en een topic gevonden dat erg lijkt op mijn probleem. Die pingplot lijkt ook wel heel erg (bijna 1-op-1) op die van mij: https://community.ziggo.nl/internetverbinding-102/hoge-packet-loss-signaalsterkte-is-in-orde-32454/i...

 

Dat geeft hoop, ik ben dus niet alleen!! 🙂


Contact gehad met de persoon uit dat andere soortgelijke topic, en de pret was blijkbaar van korte duur. Het probleem léék in eerste instantie opgelost met een nieuwe connectbox, maar is toch weer terug gekomen.

Pas na het overgaan naar een zakelijk pro abonnement, met een ander modem ipv de Connectbox is het probleem verholpen.

Iemand een idee wat mijn mogelijkheden zijn wat betreft het modem? Kan ik dit bij Ziggo aankaarten en om een ander modem vragen? Kan ik een eigen modem kopen en ervoor in de plaats zetten… of ben ik bijna verplicht om een zakelijk abonnement te nemen als ik een goede verbinding wil? (eigenlijk is dat natuurlijk wel van de zotte...)

hanh

Oud Community-lid
  • 17054Posts
  • 661Oplossingen
  • 3463Likes

Dat zou dan het volgende kastje moeten worden:
https://www.ziggo.nl/klantenservice/wifi/modem/zonder-wifi/ubee-ubc1318zg/

Is ook DOCSIS 3.1.

Zag al een vervanging door een Connectbox Giga langskomen bij een zakelijke klant, omdat het niet goed werkte. Wat dit betekent voor anderen? Geen idee.

Deze Ubee is zeer incidenteel als DOCSIS 3.0 oplossing bij consument-klanten terechtgekomen.
Of je hem als consument makkelijk los zou kunnen krijgen, zal beslist niet het geval zijn.

Eigen kabelModem is uitgesloten. Wel: (jouw) Ziggo kastje in Bridge laten zetten en eigen Router erachter. Of dit je kan gaan helpen, is mogelijk.

E-mail notificaties
Aan Uit

Ontvang een update bij nieuwe reacties in dit topic.

Uitgelicht topic