Met de functie voor automatische suggesties kun je je zoekresultaten snel verfijnen doordat mogelijke overeenkomsten wordt voorgesteld terwijl je typt.
Afgelopen vrijdag heb ik m'n nieuwe Sagemcom F3896LG-ZG modem aangesloten, omdat de tweede adapter al van de Technicolor 7210 niet meer werkte.
M'n Technicolor stond in bridge modus, dus moest ik eerst even bellen met de helpdesk om de Sagemcom uit bridge te halen (vanwege het "geen IP adres uitgifte probleem"), om hem vervolgens weer in bridge modus te zetten.
Hierna had ik weer internet via de bridge modus (groen lampje op de Sagemcom modem).
Wat me, nadat alles weer operationeel was, opviel was dat de latency op de verbindingen naar/via het modem toegenomen waren.
1. Met de TC7210 had ik een ping vanaf de pc naar het modem van 1.1ms gemiddeld. Met de Sagemcom is dat nu 3.07ms gemiddeld.
2. Met de TC7210 had ik een ping vanaf de server naar Ziggo DNS: 9.6ms gemiddeld. Met de Sagemcom is dat nu 13.23ms gemiddeld.
3. Met de TC7210 had ik een ping vanaf de server naar Cloudflare DNS 9.92ms. Met de Sagemcom is dat nu 13.49ms gemiddeld.
Dit zijn toch significante verschillen. Een gemiddelde gebruiker zou wellicht zeggen waar heb je het over.
Maar bij het spelen van FPS (first person shooters) telt iedere milliseconde natuurlijk. Zeker als je speelt tegen mensen die op glas zitten en een nóg lagere ping hebben naar de servers.
Ik heb al gewisseld van de 2,5Gbps poort 4 naar de 1Gbps poort 1. Dat maakte geen verschil.
Het enige wat dan anders is, is het modem zelf en de gebruikte technologie DOCSIS 3.1 i.p.v. 3.0.
Wat ik mij nu afvroeg:
- wat is jullie PING naar het Sagemcom modem, in een vergelijkbare netwerk topologie?
- is jullie een afwijking in latency opgevallen naar servers op het internet na het plaatsen van een Sagemcom modem?
(- klopt het verder dat bij modem_status "Internet (Router status)" is, i.p.v. "Internet (Bridge status)" ? )
Wat me verder opviel is dat als je een foutief wachtwoord opvoert, je de pagina moet vernieuwen om opnieuw een wachtwoord te kunnen invoeren (interface foutje?).
Deze extra latency wordt vermoedelijk veroorzaakt door het OFDMA-kanaal, niet door de F3896. Het kanaal moet nog steeds worden verplaatst naar hogere frequenties (FM-omroepband) zodat de eerder uitgeschakelde IUC's (Interval Usage Codes) 10 en 11 opnieuw ingeschakeld kunnen worden c.q. hogere modulaties kunnen worden gebruikt. Daarnaast is de ruisvloer hoger op de huidige lage frequenties.
De coaxinstallatie ziet er prima uit. Is de TV-kabel direct op een TV/decoder aangesloten, al of niet via een contactdoos, of heb je ook een versterker of tweede splitter in gebruik?
De downstream- (dank, @KBX458) en upstream-waarden zijn goed, op enkele SC-QAM-kanalen zijn echter uncorrectable errors voorgekomen.
Kun je ook de gegevens van het tabblad Netwerk historie plaatsen?
Ik gebruik zelf een UBC1318ZG in bridge mode en zie ook een latency van 2~3 ms naar het modem. Mijn latency naar het CMTS is echter 7~9 ms, 8~10 ms naar een Microsoft-server (www.msftncsi.com) in Amsterdam. Dit is gemeten door Nagios Core op een Raspberry Pi. De Raspberry Pi is via Cat 6a S/FTP verbonden met een switch (ES-8-150W), welke op diens beurt via OM4 fiber is verbonden met de router (ER-4).
'Router status' is een visuele bug, dit betekent bridge mode.
Bij overstap naar een ander modem (in router mode) ontvang je inderdaad een ander IPv4-adres en andere IPv6-prefix. De routing zou echter gelijk moeten blijven, het modem verbindt met hetzelfde CMTS. Buiten het corenetwerk van VodafoneZiggo kan eventueel wel een andere route gekozen worden.
Ik maak nog geen gebruik van IPv6 dus kan hiermee geen vergelijking geven.
CM-STATUS message sent. Event Type Code: 2; Chan ID: 32; DSID: N/A; MAC Addr: N/A; OFDM/OFDMA Profile ID: N/A.;CM-MAC=d0:6d:c9:51:84:2b;CMTS-MAC=00:01:5c:c0:30:0c;CM-QOS=1.1;CM-VER=3.1;
10-02-2023 15:45:50
notice
REGISTRATION COMPLETE - Waiting for Operational status
10-02-2023 15:45:45
warning
RNG-RSP CCAP Commanded Power in Excess of 6 dB Below the Value Corresponding to the Top of the DRW;CM-MAC=d0:6d:c9:51:84:2b;CMTS-MAC=00:01:5c:c0:30:0c;CM-QOS=1.1;CM-VER=3.1;
DHCP WARNING - Non-critical field invalid in response ;CM-MAC=d0:6d:c9:51:84:2b;CMTS-MAC=00:01:5c:c0:30:0c;CM-QOS=1.1;CM-VER=3.1;
10-02-2023 15:45:29
notice
Honoring MDD; IP provisioning mode = IPv4
10-02-2023 15:45:27
critical
Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=d0:6d:c9:51:84:2b;CMTS-MAC=00:01:5c:c0:30:0c;CM-QOS=1.1;CM-VER=3.1;
10-02-2023 15:44:52
critical
No Ranging Response received - T3 time-out;CM-MAC=d0:6d:c9:51:84:2b;CMTS-MAC=00:01:5c:c0:30:0c;CM-QOS=1.1;CM-VER=3.1;
10-02-2023 15:44:48
critical
SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=d0:6d:c9:51:84:2b;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.1;CM-VER=3.1;
10-02-2023 15:44:30
critical
Cable Modem reboot from UI
10-02-2023 15:01:16
critical
Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=d0:6d:c9:51:84:2b;CMTS-MAC=00:01:5c:c0:30:0c;CM-QOS=1.1;CM-VER=3.1;
10-02-2023 15:00:42
critical
No Ranging Response received - T3 time-out;CM-MAC=d0:6d:c9:51:84:2b;CMTS-MAC=00:01:5c:c0:30:0c;CM-QOS=1.1;CM-VER=3.1;
10-02-2023 15:00:38
critical
SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=d0:6d:c9:51:84:2b;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.1;CM-VER=3.1;
10-02-2023 14:58:45
critical
Cable Modem Reboot from SNMP
10-02-2023 14:52:23
critical
Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=d0:6d:c9:51:84:2b;CMTS-MAC=00:01:5c:c0:30:0c;CM-QOS=1.1;CM-VER=3.1;
10-02-2023 14:51:49
critical
No Ranging Response received - T3 time-out;CM-MAC=d0:6d:c9:51:84:2b;CMTS-MAC=00:01:5c:c0:30:0c;CM-QOS=1.1;CM-VER=3.1;
10-02-2023 14:51:44
critical
SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=d0:6d:c9:51:84:2b;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.1;CM-VER=3.1;
10-02-2023 14:49:45
critical
Cable Modem Reboot from SNMP
10-02-2023 14:44:09
critical
Received Response to Broadcast Maintenance Request, But no Unicast Maintenance opportunities received - T4 time out;CM-MAC=d0:6d:c9:51:84:2b;CMTS-MAC=00:01:5c:c0:30:0c;CM-QOS=1.1;CM-VER=3.1;
10-02-2023 14:43:35
critical
No Ranging Response received - T3 time-out;CM-MAC=d0:6d:c9:51:84:2b;CMTS-MAC=00:01:5c:c0:30:0c;CM-QOS=1.1;CM-VER=3.1;
10-02-2023 14:43:30
critical
SYNC Timing Synchronization failure - Failed to acquire QAM/QPSK symbol timing;;CM-MAC=d0:6d:c9:51:84:2b;CMTS-MAC=00:00:00:00:00:00;CM-QOS=1.1;CM-VER=3.1;
Ping statistics for 23.202.229.40: Packets: Sent = 21, Received = 21, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 6ms, Maximum = 18ms, Average = 13ms
Tracing route to a1961.g2.akamai.net [23.202.229.35] over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms USG [192.168.1.1] 2 * * * Request timed out. 3 10 ms 12 ms 14 ms mnd-rc0001-cr101-et90-201.core.as33915.net [213.51.197.233] 4 13 ms 10 ms 17 ms asd-rc0001-cr101-be155-10.core.as9143.net [213.51.158.108] 5 13 ms 9 ms 20 ms nl-ams09c-ri1-ae50-0.core.as9143.net [213.51.64.62] 6 12 ms 17 ms 14 ms 213.46.182.254 7 18 ms 16 ms 12 ms ae-0.akamai.amstnl07.nl.bb.gin.ntt.net [81.20.64.106] 8 12 ms 14 ms 15 ms a23-202-229-35.deploy.static.akamaitechnologies.com [23.202.229.35]
V.w.b. "router" status, dat zag ik bij de eerdere connectbox ook voor komen. De groene kleur LED voorop is leidend.
De latency lokaal naar het modem maakt me vrij weinig uit, hoewel het wel typisch is, maar naar het internet is belangrijker voor mij natuurlijk 🙂
Omdat het modem in bridge stond en staat en het MAC adres van m'n router ongewijzigd is gebleven, is ook het WAN IP adres ongewijzigd gebleven (ik weet wat het adres was voor de wijziging en na de wijziging uiteraard).
De event log toont uitval (MDD timeouts) van meerdere SC-QAM-kanalen. Dit kan veroorzaakt worden door instraling op de einddozen, welke verouderd zijn. Je kunt de versterker tijdelijk ontkoppelen van de versterker om na te gaan of dit een positief effect heeft op het oplopen van de uncorrectable errors, de events in de log en/of de WAN latency/jitter. Uncorrectable errors mogen alleen oplopen tijdens werkzaamheden of bekende storingen.
Tracing route to a1961.g2.akamai.net [23.202.229.40] over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms RT-AX86U-3438.lan [192.168.0.1] 2 17 ms 11 ms 11 ms 77.250.136.1 3 17 ms 13 ms 13 ms 212.142.54.49 4 13 ms 13 ms 15 ms asd-rc0001-cr101-be114-2.core.as33915.net [213.51.7.98] 5 15 ms 13 ms 14 ms nl-ams09c-ri1-ae50-0.core.as9143.net [213.51.64.62] 6 13 ms 14 ms 13 ms 213.46.182.254 7 135 ms 220 ms 306 ms ae-0.akamai.amstnl07.nl.bb.gin.ntt.net [81.20.64.106] 8 14 ms 10 ms 14 ms a23-202-229-40.deploy.static.akamaitechnologies.com [23.202.229.40]
Trace complete.
C:\Users\robinjoo1>ping 23.202.229.40
Pinging 23.202.229.40 with 32 bytes of data: Reply from 23.202.229.40: bytes=32 time=13ms TTL=56 Reply from 23.202.229.40: bytes=32 time=15ms TTL=56 Reply from 23.202.229.40: bytes=32 time=15ms TTL=56 Reply from 23.202.229.40: bytes=32 time=14ms TTL=56
Ping statistics for 23.202.229.40: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 13ms, Maximum = 15ms, Average = 14ms
De TRISZ-DG300 is prima. I.v.m. de versterker kan de POA-01-B het beste worden vervangen door een POA-254 met F/F-kabel voor het modem, of er kan een HPFX258-IECFM tussen splitter en versterker worden geplaatst.
De EDC 1000 wordt inderdaad nog steeds nieuw aangeboden, maar is >10 jaar oud. Afsluitweerstanden (TIM 75) plaatsen op de radio-uitgangen is inderdaad een optie.
De uncorrectable errors mogen alleen voorkomen c.q. oplopen bij werkzaamheden of bekende storingen. De hoeveelheden correctable errors zijn acceptabel.
Deze extra latency wordt vermoedelijk veroorzaakt door het OFDMA-kanaal, niet door de F3896. Het kanaal moet nog steeds worden verplaatst naar hogere frequenties (FM-omroepband) zodat de eerder uitgeschakelde IUC's (Interval Usage Codes) 10 en 11 opnieuw ingeschakeld kunnen worden c.q. hogere modulaties kunnen worden gebruikt. Daarnaast is de ruisvloer hoger op de huidige lage frequenties.
Via Marktplaats en andere tweedehands platformen worden de zeshoekige
SmartWifi pods van Ziggo regelmatig aangeboden. Wat op het eerste
gezicht een mooie deal lijkt, blijkt het toch vaak een spreekwoo...