Met de functie voor automatische suggesties kun je je zoekresultaten snel verfijnen doordat mogelijke overeenkomsten wordt voorgesteld terwijl je typt.
De monteur heeft eindjes geoxideerde groene kabel aan weerszijden vervangen en het AOP fatsoenlijk gemonteerd. Ik heb de afgelopen dagen de packet loss bijgehouden en stel vast dat het niet beter is geworden:
Jij bent de IT-hulplijn in je straat, de verlichting werkt thuis op commando en je groet de pakketbezorger met de slimme deurbel. Herkenbaar? Dan zijn de Community events echt iets voor jou! Doe mee en sluit je aan.
Zelf heb ik inderdaad een ander topic geopend, echter heeft Vincent nog niet gereageerd. Hij is de topic starter en ervaart momenteel net zoals ik eerst packet loss.
Ik denk dat @GeneralX het waardeert als dit topic nog geopend blijft zolang hij de packet loss probeert weer te geven. Wellicht dat het in zijn situatie ook nog een idee is om voor de zekerheid het coax signaal door te meten + een Ubee UBC1318ZG te plaatsen?
In ieder geval lijkt het initiele probleem, los van dit ene vage moment waar de verbinding even wegviel, in zijn geheel bij mij opgelost te zijn waar ik erg tevreden mee ben! Bij Vincent (GeneralX) heeft hij, voor zo ver ik begrepen heb, nog steeds hier af- en toe problemen mee.
Het is al even geleden sinds ik hier gereageerd heb omdat er bij mij niets veranderd is sinds de monteur langs is geweest. Packet loss komt nog steeds voor. Vorige week heb ik hier gevraagd of het de bedoeling was dat ik actief contact zou gaan zoeken wanneer er packet loss optreedt zodat jullie wellicht een meting kunnen starten, maar daar heb ik tot op heden geen reactie op gehad vanuit jullie kant.
Ik heb eigenlijk geen tijd om elke 5 minuten even te kijken of er misschien packet loss optreedt en ik heb nog geen tijd gemaakt om push-notificaties in te stellen. Ik heb ook geen idee of dat laatste technisch goed te doen is, of dat ik dan een dag aan het programmeren ben.
Bovendien kwam @felix_ langs in dit topic, met de melding dat hij een Ubee UBC1318ZG zou krijgen en inmiddels heeft gekregen. Voor hem zijn daarmee de problemen opgelost, maar ik zie niet zo goed waarom dit reden is om mijn topic te sluiten. Ik ga ervanuit dat u dat niet zo bedoelde. Felix’s oplossing klinkt heel makkelijk, dus die wil ik best proberen. Het lijkt erop dat ik binnenkort weer meer thuis zal werken, dus als dat Ubee modem de problemen verhelpt dan is dat wel heel waardevol.
Graag hoor ik van u wat nu precies de bedoeling is? Moet ik aan de telefoon gaan hangen bij packet loss, starten jullie zelf een meting, of gaan jullie een ander modem opsturen?
Wat mij in ieder geval duidelijk is geworden dat Ziggo geen packet loss kan meten, tenminste dit is mij meerdere malen via de klantenservice duidelijk gemaakt. Dit heb ik dus zelf moeten doen, maar ik heb dan ook meerdere virtuele machines die 24/7 draaien waar ik mooi gebruik van kan maken.
Ik heb ook in een datacenter van Microsoft Azure een Linux server draaien met Smokeping, als je wilt zet ik jouw IP-adres thuis van je modem in mijn monitoring actief. De Azure datacenters hebben uiteraard een 100% stabiele internet verbinding, dus als er packet loss te zien is weet je zeker dat dit aan jouw verbinding thuis ligt. Je kan dan zelf de packet loss en dergelijk in de gaten houden met de website: http://felix-smokeping.westeurope.cloudapp.azure.com/smokeping/smokeping.cgi
Momenteel kan je deze niet bezoeken, aangezien ik jouw IP-adres hiervoor moet whitelisten in de firewall op port 80. Ik monitor hier ook andere Ziggo verbindingen overigens, dus die van jou kan daar best tussen! Scheelt in ieder geval het moeten draaien van hardware 24/7, de installatie van operating system en software en je krijgt acurate cijfers terug, omdat de pings vanuit een datacenter van buitenaf jouw netwerk komen, in plaats van binnenuit naar buiten. Hiermee toon je direct aan dat het echt aan de verbinding ligt en niet jouw interne netwerk.
Wel moet jouw firewall ICMP (ping) pakketjes accepteren op de WAN interface, de meeste routers en firewalls hebben dit standaard al aan staan. Het ziggo modem ook, heb jij deze nog steeds in bridge staan met een Mikrotik router hierachter?
Laat maar weten of je er gebruik van wilt maken, voor mij amper moeite om even in een config file jouw IP-adres toe te voegen!
PS: Stuur even je IP-adres via een PM door, zodat dit niet openbaar op dit forum staat.
Groet,
Felix
Web interface ziet er zo uit, ik monitor hier ook momenteel een Ziggo verbinding van mijn neef die in een studentenhuis woont. Mogelijk dat ik hier binnenkort de WiFi ga verbeteren, echter moet ik eerst weten of de Ziggo lijn stabiel is of dat ook hier problemen zitten. Ongeveer 8 studenten worden met enig regelmaat uit hun online video sessies van school gegooid etc. Wel een 300/40 verbinding daar, maar apparatuur is meuk.Dit is Pingplotter bij mij thuis die op Linux binnen een virtuele machine draait. Dit zijn dus de grafiekjes die je kan verwachten, ping times en packet loss zijn eenvoudig uit te lezen. Bovenstaande afbeelding is pingplotter in een Microsoft Azure Datacenter West-Europa.
De eerste keer dat er hier een monteur langskwam, heb ik met veel aandacht gekeken naar zijn verrichtingen. Elektrotechniek is nou eenmaal mijn vakgebied, ook al focus ik normaal niet zo op datacommunicatie. Ik begrijp daaruit dat het mogelijk is om de signaalwaarden van (delen van) een wijk in de gaten te houden en dat er op die manier ingezoomed kan worden op eventuele stoorzenders.
Daarmee identificeer je natuurlijk nooit problemen in een modem, maar die conclusie kun je trekken op het moment dat er op het LAN geen packet loss is en de wijk ook in orde is. Of wanneer je het modem vervangt en de problemen verdwijnen. Packet loss tussen twee IPs is natuurlijk niet goed te meten door Ziggo, tenzij ze zelf één van de IPs zijn. Dus in die zin zijn we inderdaad aangewezen op onze eigen logging, totdat ze bij Ziggo zelf gaan pingen naar onze modems.
In het verleden heb ik wel discussie gehad met monteurs of packet loss niet lag aan de bestemmingen die ik ping, maar Azure downtime is dusdanig zeldzaam dat ik aanneem dat daar niet moeilijk over zal worden gedaan. Ik waardeer je aanbod in ieder geval bijzonder, ik heb je een DM gestuurd. Mijn hardware blijft verder toch wel draaien (in verband met synchronisatie van ontwerpen/tekeningen en engineers die rare werktijden hebben nu ze thuis werken), maar we kunnen daarmee in ieder geval mijn hardware en software uitsluiten en wellicht correlatie vinden tussen packet loss op uitgaand en binnenkomend verkeer.
Ik heb het modem niet meer in bridge mode staan sinds mijn eerste topic op het forum (gesloten wegens 7 dagen niet gepost te hebben, vandaar #2 in de topic titel) en dat is inmiddels al maanden geleden. De configuratie is nu praktisch standaard, met uitzondering van een statisch IP en een UPnP forwarding regel. ICMP heb ik niet aangezeten en ik kom ook geen specifieke instelling tegen om het aan te passen.
Wat we niet uitsluiten kunnen, is dat de hardware of firmware voor de uitgaande verbinding afwijkt van die voor de inkomende verbinding en dat packet loss maar in één richting optreedt. Maar dat is ook belangrijke informatie.
Nogmaals, bedankt voor het vriendelijke aanbod 🙂
Groet,
Vincent
Packet loss is realDe hele dag was blijkbaar matig. Ik was niet thuis op de momenten dat er packet loss was, dus veel verkeer kan er niet zijn geweest.
Hi Vincent (en Felix), Lycke was even in de war denk ik, dit topic gaat om jouw probleem en niet die van Felix. Ook al is de oplossing misschien gelijk, dat zullen we zien.
Ik heb wat meer mogelijkheden dan de Klantenservice om verbindingen te monitoren waaronder Smokeping, dus ik heb bij dezen een meting gestart op jouw modem (en op een ander modem in jouw omgeving ter vergelijking). Zo komen we er snel achter hoe vaak de packetloss optreedt en of dat alleen bij jou speelt of ook bij de andere Ziggo klanten in jouw omgeving.
Daarnaast start ik ook een gedetailleerde meting op het docsis signaal tussen ons en jouw modem, als ik daarin korte dipjes of spikes zie elke keer dat jij packetloss ervaart dan zit daar de oorzaak. In dat geval denk ik niet dat een nieuw modem de oplossing zal zijn, maar zullen we nogmaals een monteur langs moeten sturen om het signaal te onderzoeken.
Donderdag ben ik er weer, dan zal ik gaan kijken naar de verzamelde data.
Als ik de resultaten bekijk is er niet vaak sprake van packetloss. De momenten dat er wel packetloss optreedt komt dat schijnbaar door hoge belasting van het modem (veel down- & uploadverkeer tegelijk) waarbij ICMP simpelweg gedropt wordt omdat het modem het normale dataverkeer voorrang geeft. Over het algemeen is je ping heel erg instabiel, maar dat komt door het constante uploadverkeer. Ook dat krijgt voorrang t.ov. ICMP verkeer.
Onderstaand een periode waarin verschillende beelden te zien zijn.
Eerst stabiel en laag in rust
Dan instabiel en verhoogd bij een constante upload (~7Mbps)
Gevolgd door uitschieters en (ICMP) packetloss op momenten dat zowel up- als download redelijk belast wordt
Als ik naar het modem van een van je buren kijk in dezelfde periode zie ik geen enkel probleem. Dit modem maakt verbinding met dezelfde centrale (CMTS) op dezelfde up- en downstream frequenties, vanaf de eindversterker (kastje in de straat) ook via dezelfde coaxkabels. Dat zit allemaal wel goed dus.
De packetloss die jij ervaart kan ik niet verklaren uit het signaal op jouw individuele aansluiting, noch uit het wijksignaal en de CMTS. De (ICMP) packetloss die ik tot nu toe gemeten heb kan ik alleen maar linken aan de belasting van je modem, waardoor ICMP verkeer in de verdrukking komt. Het normale dataverkeer (je download, stream, video-call, game) heeft daar veel minder last van, maar is een aanname. Dat kun je niet in kaart brengen aan de hand van ICMP verkeer.
De meting loopt nog tot 10-11 14:43 zoals je ziet, als je zelf een periode van packetloss ziet/ervaart (binnen de sessie van 3-11 t/m 10-11) die je graag verder onderzocht wilt hebben, laat het me weten!
Bedankt voor de inzichtelijke informatie! Incidenteel was de packet loss altijd al, dus dat het zich niet vaak voordoet dat heb ik in het eerste topic zelfs in de titel gezet. Zodra ik weer thuis ben, zal ik de achtergrondprocessen uitzetten zodat we de ‘ruis’ kunnen beperken. Als ik thuis met werk bezig ben, valt er sowieso al een hoop verkeer weg. Ik zal daarom kijken of ik tot het aflopen van de sessie wat meer thuis kan werken.
De reden dat ik dit topic heb geopend, is dat ik ook packet loss ervaarde tijdens momenten dat er niks draaide en het dus niet direct aan belasting kon koppelen. Sowieso moet ik eens kijken waarom er zoveel data wordt verstookt, want dat hoort eigenlijk niet zo lang door te lopen.
Van de andere kant bekeken, is het niet vreemd dat een redelijke belasting leidt tot het droppen van ICMP pakketjes? Deze modems worden immers ook geleverd aan klanten met 500/40 Mbit/s abbonementen? Daar leidt 7 Mbit/s niet tot instabiliteit, hoop ik. Mag ik afleiden uit uw bericht dat Ziggo vindt dat 7 Mbit/s eigenlijk te veel is? Kunt u misschien ook aangeven bij welke belasting het modem nog wel normaal ICMP verkeer af kan handelen?
Het droppen van ICMP pakketjes door het modem is geen instabiliteit. Er gaat niets stuk als je ICMP pakketjes dropt, behalve de ICMP test. Pas als ook andere pakketjes gedropt worden wordt de verbinding instabiel. Dat kun je strikt gezien niet meten met een ICMP test (tenzij je TCP pakketjes gebruikt), maar uit een combinatie van de ICMP resultaten naast alle andere metingen kun je afleiden of het slechts een gedropt ICMP pakketje betreft of werkelijke packetloss waar je last van hebt in het dagelijks gebruik.
Ik zie zondag tussen ~14:10 en ~15:15 wat hogere ping + een klein beetje packetloss terwijl er weinig dataverkeer op je modem is (dit zie ik ook op het andere modem uit jouw omgeving). Hier was sprake van een piek in het uploadverkeer op hele de centrale en daar heeft al het dataverkeer last van (niet alleen ICMP). Ben benieuwd of dit inderdaad de structurele oorzaak is, we houden het nog even in de gaten.
Wat mij in ieder geval duidelijk is geworden dat Ziggo geen packet loss kan meten, tenminste dit is mij meerdere malen via de klantenservice duidelijk gemaakt. Dit heb ik dus zelf moeten doen, maar ik heb dan ook meerdere virtuele machines die 24/7 draaien waar ik mooi gebruik van kan maken.
Ik heb ook in een datacenter van Microsoft Azure een Linux server draaien met Smokeping, als je wilt zet ik jouw IP-adres thuis van je modem in mijn monitoring actief. De Azure datacenters hebben uiteraard een 100% stabiele internet verbinding, dus als er packet loss te zien is weet je zeker dat dit aan jouw verbinding thuis ligt. Je kan dan zelf de packet loss en dergelijk in de gaten houden met de website: http://felix-smokeping.westeurope.cloudapp.azure.com/smokeping/smokeping.cgi
Momenteel kan je deze niet bezoeken, aangezien ik jouw IP-adres hiervoor moet whitelisten in de firewall op port 80. Ik monitor hier ook andere Ziggo verbindingen overigens, dus die van jou kan daar best tussen! Scheelt in ieder geval het moeten draaien van hardware 24/7, de installatie van operating system en software en je krijgt acurate cijfers terug, omdat de pings vanuit een datacenter van buitenaf jouw netwerk komen, in plaats van binnenuit naar buiten. Hiermee toon je direct aan dat het echt aan de verbinding ligt en niet jouw interne netwerk.
Wel moet jouw firewall ICMP (ping) pakketjes accepteren op de WAN interface, de meeste routers en firewalls hebben dit standaard al aan staan. Het ziggo modem ook, heb jij deze nog steeds in bridge staan met een Mikrotik router hierachter?
Laat maar weten of je er gebruik van wilt maken, voor mij amper moeite om even in een config file jouw IP-adres toe te voegen!
PS: Stuur even je IP-adres via een PM door, zodat dit niet openbaar op dit forum staat.
Groet,
Felix
Web interface ziet er zo uit, ik monitor hier ook momenteel een Ziggo verbinding van mijn neef die in een studentenhuis woont. Mogelijk dat ik hier binnenkort de WiFi ga verbeteren, echter moet ik eerst weten of de Ziggo lijn stabiel is of dat ook hier problemen zitten. Ongeveer 8 studenten worden met enig regelmaat uit hun online video sessies van school gegooid etc. Wel een 300/40 verbinding daar, maar apparatuur is meuk.Dit is Pingplotter bij mij thuis die op Linux binnen een virtuele machine draait. Dit zijn dus de grafiekjes die je kan verwachten, ping times en packet loss zijn eenvoudig uit te lezen. Bovenstaande afbeelding is pingplotter in een Microsoft Azure Datacenter West-Europa.
Hey Felix,
Zou je mij kunnen helpen door mijn ip te plaatsen op dat smoke ding waar je kan monitoren?
Het droppen van ICMP pakketjes door het modem is geen instabiliteit. Er gaat niets stuk als je ICMP pakketjes dropt, behalve de ICMP test. Pas als ook andere pakketjes gedropt worden wordt de verbinding instabiel. Dat kun je strikt gezien niet meten met een ICMP test (tenzij je TCP pakketjes gebruikt), maar uit een combinatie van de ICMP resultaten naast alle andere metingen kun je afleiden of het slechts een gedropt ICMP pakketje betreft of werkelijke packetloss waar je last van hebt in het dagelijks gebruik.
Ik zie zondag tussen ~14:10 en ~15:15 wat hogere ping + een klein beetje packetloss terwijl er weinig dataverkeer op je modem is (dit zie ik ook op het andere modem uit jouw omgeving). Hier was sprake van een piek in het uploadverkeer op hele de centrale en daar heeft al het dataverkeer last van (niet alleen ICMP). Ben benieuwd of dit inderdaad de structurele oorzaak is, we houden het nog even in de gaten.
Hi Mark en Vincent,
Woensdag 11-11 zag ik ook wat packet loss bij Vincent terugkomen, interessant probleem. Zou de wijkkast dan in sommige situaties gewoonweg te weinig capaciteit beschikbaar hebben? Zoals Vincent het eerder omschreef merkt hij het ook tijdens gamen, ICMP wordt inderdaad niet geprioriteerd, maar als TCP & UDP pakketjes ook verloren gaan duidt dit op een ander probleem dan dat ICMP even niet meer doorkomt wegens capaciteitsproblemen op de aansluiting.
7 Mbit/s lijkt mij ook niet echt waanzinnig veel, wel als constante upload 24/7 natuurlijk, maar lijkt mij dat dit toch wel moet kunnen.
De Azure VM had te weinig geheugen beschikbaar, deze heb ik nu verdubbeld. Vandaar dat er af- en toe geen data beschikbaar is voor wat uurtjes. Tenminste, dit is mijn vermoeden. Begreep dat Mark ook jouw verbinding in Smokeping heeft staan, @Mark Ziggo heb jij nog iets kunnen zien op de COAX verbinding afgelopen woensdag?
Ben benieuwd of het hier om hetzelfde probleem als bij mij ging, sinds ik de Ubee heb geen packet loss meer. Maar voor zo ver bij mij bekend is hebben mijn Ziggo buren geen problemen, terwijl ik deze wel frequent had. Leek bij mij dus niet aan de CMTS te liggen, wat bevestigd is door een nu wel stabiele verbinding met de UBC1318ZG.
Kreeg dit net @felix_ toen ik aan het gamen was. Via pingplotter de test gedaan. Ik krijg constant lag. En als ik doorga zie opeens de gamertag van de tegenstander boven mijn spelers in fifa
@Flitspuit - Kun je een eigen topic starten om jouw probleem verder te onderzoeken? Anders lopen er hier meerdere troubleshoots door elkaar en raken we het overzicht kwijt. In de pingtest screenshots die je deelt zie ik overigens geen problemen.
Terug naar jouw verbinding Vincent @GeneralX, net als Felix zie ik bij jou op 12-nov dezelfde periode van packetloss en verhoogde ping, maar dat is te verklaren door hoog down- en uploadverkeer vanaf jouw aansluiting in die periode.
De capaciteit in de wijk kan dat prima aan, op het andere modem was er geen vuiltje aan de lucht:
Zelfde verhaal op 13/14-nov:
Wederom geen indicatie dat de capaciteit in de wijk niet toereikend zou zijn.
Voorlopig zie ik dus alleen de effecten van het down- en uploadverkeer op ICMP verkeer, maar ik heb geen reden om aan te nemen dat dat ook invloed heeft op het normale dataverkeer.
