Met de functie voor automatische suggesties kun je je zoekresultaten snel verfijnen doordat mogelijke overeenkomsten wordt voorgesteld terwijl je typt.
Connect Box - Upstreamkanalen vallen willekeurig terug naar 16-QAM
Het viel mij eergisteren voor het eerst op dat bepaalde (willekeurige) upstreamkanalen op willekeurige momenten terugvallen van 64- naar 16-QAM op mijn Compal Connect Box. Meestal is het kanaal 2 op 44.5 MHz. Is dit normaal? Ik ben overigens van plan om het modem vandaag sowieso een power cycle te geven.
Welke compal versie heb je nu. Er wordt een nieuwere versie uitgerold en met deze versie is het niet mogelijk om zonder pasword gegevens via curl te krijgen als je dit gebruikt. Ik kan morgen wel een script in mekaar rijgen om de modulatie te monitoren met 5 minuten interval
Oei, dan moet ik de authenticatiefunctie van mijn script opnieuw schrijven. Mijn Connect Box heeft nu software CH7465LG-NCIP-6.12.18.25-2p5-NOSH en ik gebruik inderdaad cURL in mijn script. Elke keer dat ik het script draai vraag ik nu een nieuwe token op dus wenselijk is dat niet. Het beste zou zijn om een cookie jar te gebruiken.
Toen ik eenmaal doorhad dat een van de upstream channels op 16-QAM stond, heb ik meteen mijn script zó aangepast dat deze een afsluit met een warning als een of meerdere van de downstream en upstream channels niet respectievelijk 256-QAM en 64-QAM zijn.
Waarschijnlijke oorzaak is een slechte SNR bij de CMTS.
De CMTS beheerd het modem CM en verstuurd opdrachten naar het modem, bv het verhogen/verlagen van het vermogen dat het modem mag zenden. Dit wordt ook niet gelogd.
In jouw geval wordt de modulatie gewijzigd wat ik vreemd vindt dit zou m.i. ook kunnen met het verhogen van het zendvermogen om een betere snr te krijgen, er is ruimtegenoeg. Kan je ook controleren of de symbolrate ook aangepast wordt.
In fUPC wanneer er wordt gebruikt gemaakt van 6 US kanalen, de 2 kanalen met de laagste frequentie, gebruiken dan een lagere symbolrate i.v.m. ruis.
Dit is mijn activiteit met zendvermogen over de laatste 72 uur
Ik zat inderdaad ook te denken aan een tijdelijk verhoogde hoeveelheid ruis op het betreffende kanaal. Helaas kunnen wij als eindgebruikers niet zien wat de SNR bij de CMTS is en of een verlaagde SNR een bepaalde aansluiting of een geheel coax-segment betrof.
Zelf vind ik het ook vreemd dat het modem terugvalt naar een lagere modulatie terwijl de signaalniveaus in orde zijn en constant blijven. Ik heb gisteren om 19:30 de laatste alert gehad, opnieuw over 44.5 MHz en opnieuw 16-QAM voor ~20 minuten, dit zal ik in de gaten blijven houden. Verder moet ik het modem nog een reboot geven, mogelijk komt dit de stabiliteit ten goede.
De symbol rate is interessant en zal ik vandaag toevoegen aan mijn script. Een maand geleden was deze 5120 ksym/s op alle US-kanalen, nu nog steeds.
Ik heb er ook last van vanaf 19:30 -19:50 en 21:50 22:10. en ook op hetzelfde kanaal
Voor de aardigheid het mac-adres van de CMTS-MAC=00:01:5c:b1:76:46;CM-QOS=1.1;CM-VER=3.0; Het is nu weer normaal Voor zover ik weet is het een Arris/Cadant modem.
Interessant, ik heb op dit moment (sinds 22:11) ook weer een alert. Ook weer 44.5 MHz. Inderdaad geen verandering in signaalniveau, T3 en symbol rate. Jij en ik zitten niet toevallig in dezelfde regio (Noord-Holland Noord)? We zitten niet achter dezelfde CMTS zo te zien, al zit ik ook achter een Arris/Cadent CMTS.
Upstream kanalen worden gebruikt om DOCSIS data packets van de modems naar de CMTS te verzenden. Modulatie van die upstream kanalen vindt plaats aan de modem kant van de HFC infrastructuur. Er zijn daarom meerdere zenders en de CMTS is de enige ontvanger. Omdat het niet erg zinvol is om alle modems tegelijk te laten zenden via de beperkte set upstream kanalen heeft een groot deel van de DOCSIS specificatie betrekking op de benodigde mechanismes om modems om de beurt te laten zenden waarbij de CMTS bepaalt wie er mag zenden en voor welk doel er gezonden mag worden. Op hoofdlijnen vallen die doelen uiteen in DOCSIS management verkeer en data verkeer van de kabel internet gebruiker.
Dit maakt het bepalen van de capaciteit van een upstream en daarmee de totale upstream capaciteit van een coaxsegment nogal lastig. Ook werken de diverse modulatie technieken en verschillende bandbreedtes niet mee. Een upstream kanaal met de maximale bandbreedte van 6.4 MHz en 64-QAM modulatie heeft in theorie een capaciteit van maximaal 28 Mbps, maar is dus niet continu in gebruik met deze instellingen. Wanneer hetzelfde upstream kanaal tijdelijk met QPSK modulatie gebruikt wordt voor DOCSIS management verkeer dan valt de capaciteit terug naar maximaal 9 Mbps. Kanalen met 3.2 MHz bandbreedte hebben de helft van de capaciteit van een kanaal met 6.4 MHz bandbreedte met dezelfde modulatie instellingen. De bandbreedte van een upstream kanaal kan via de modem upstream status pagina afgeleid worden aan de hand van de symboolsnelheid. Een symboolsnelheid van 5210 ksps komt overeen met een bandbreedte van 6.4 MHz en een symboolsnelheid van 2560 ksps met 3.2 MHz.
Mischien is bovenstaande de oorzaak QPSK of QAM16 ???
Zojuist het modem een reboot gegeven, eerder vandaag op bepaalde momenten willekeurige US-kanalen tegelijk op 16-QAM. Kijken of het nu beter gaat.
De software is van CH7465LG-NCIP-6.12.18.25-2p5-NOSH naar CH7465LG-NCIP-6.12.18.26-3p6-GA-NOSH gegaan en mijn script lijkt niet meer te werken, dus ga daar nu weer mee aan de slag.
Deze commands werken dus niet meer, althans: het modem geeft geen data meer terug voor fun 10 en de eerder verkregen token:
:~/git/ch7465lg-nagios $ curl -I -s http://192.168.100.1/common_page/login.html HTTP/1.1 200 Ok Server: NET-DK/1.0 Date: Wed, 13 May 2020 13:04:37 GMT Last-Modified: Fri, 31 Jan 2020 05:09:57 GMT Cache-Control: no-cache Pragma: no-cache Expires: -1 Content-Type: text/html Content-Length: 40656 Connection: close Set-Cookie: sessionToken=4082746112; path=/;
Helaas ben ik hier nog niet veel verder mee gekomen. Om het script weer te laten werken moet ik nieuwe cURL commands samenstellen omdat de oorspronkelijke twee niet meer werken, zoals jarielcapitain aangaf in zijn eerste bericht in dit topic vereist het modem nu authenticatie met het wachtwoord, alleen de token opgeven voldoet niet meer.
Ik heb geprobeerd om te volgen welke data het modem teruggeeft in de headers wanneer ik op de normale manier, via de browser, inlog en de DS/US-data bekijk. Via de developer tools in de browser kan ik zien dat het modem steeds een nieuwe token geeft die mijn browser in het volgende request gebruikt. Dit was ook het geval met mijn script. Echter, ik zie naast de token ook een SID (sessie-ID) gebruikt worden die steeds hetzelfde is en ik kan er niet achter komen hoe ik deze verkrijg van het modem. Mijn browser gebruikt deze nadat ik inlog met mijn wachtwoord. Samengevat, het is nog niet gelukt om het script aan te passen zodat het werkt voor de nieuwe modemsoftware.
Omdat ik het script nu niet gebruik, kan ik ook niet zien of het terugvallen van US-kanalen naar 16-QAM nog is voorgekomen de afgelopen twee dagen.
Update: 18 april 16:30 uur ZiggoIn de eerste plaats willen we iedereen
ontzettend bedanken voor alle feedback van de test, dit is voor ons erg
waardevol geweest. En zoals opgemerkt is vandaag de hoger...