Re-occurring packet loss mainly on upload

[markk01]

Hi guys,

Over the last few weeks been having several occurrences where am getting packet loss on my connection. This shows up on my BQM monitor and also when am trying to stream on twitch, resulting in around 5% dropped frames (normally its 0%). This generally resolves after a day or 2, which am guessing is when someone in VM notices a problem on their network and bounces the faulty device.

The issue is currently ongoing right now as shown on my BQM live graph and snapshot:

https://www.thinkbroadband.com/broadband/monitoring/quality/share/155856a3e5762e152d2e6c84bb07befd 

https://www.thinkbroadband.com/broadband/monitoring/quality/share/52f4fff49a69c42cd1419f99d29707099e... 

This also happened on 19th-20th Dec :https://www.thinkbroadband.com/broadband/monitoring/quality/share/6607feca4add74929e4d32defe1bef4fd0... 

https://www.thinkbroadband.com/broadband/monitoring/quality/share/e25e9fd7ea8cf1931c7bd9a9aca78e8db7... 

Router has been restarted and factory reset, coax cable is secured tightly but issue still comes back after a few days to a week ish of being resolved.

Router logs:

3.0 Upstream channels
Channel Frequency (Hz) Power (dBmV) Symbol Rate (ksps) Modulation Channel ID
1 25800000 39 5120 KSym/sec 32QAM 4
2 32600000 39.8 5120 KSym/sec 64QAM 3
3 39400000 40.3 5120 KSym/sec 64QAM 2
4 46200000 40.8 5120 KSym/sec 64QAM 1

Fri 17/12/2021 17:18:13 5 MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
Fri 17/12/2021 17:18:19 3 No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
Fri 17/12/2021 17:18:35 6 CM-STATUS message sent. Event Type Code: 3; Chan ID: N/A; DSID: 525674; MAC Addr: N/A; OFDM/OFDMA Profile ID: N/A.;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
Fri 17/12/2021 17:31:03 3 No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
Sun 19/12/2021 07:59:52 5 MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
Mon 20/12/2021 08:16:36 3 No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
Mon 20/12/2021 08:37:30 3 Unicast Ranging Received Abort Response - initializing MAC;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
Mon 20/12/2021 08:37:31 3 No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
Thu 23/12/2021 19:23:05 4 DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
Thu 23/12/2021 19:23:06 6 DHCP Renew - lease parameters tftp file-cmreg-vmdg640-bbt076-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
Fri 24/12/2021 08:44:39 3 No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
Fri 24/12/2021 15:57:58 5 MIMO Event MIMO: Stored MIMO=-1 post cfg file MIMO=-1;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
Fri 24/12/2021 15:58:07 3 No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
Mon 27/12/2021 17:40:25 4 DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
Mon 27/12/2021 17:40:26 6 DHCP Renew - lease parameters tftp file-cmreg-vmdg640-bbt076-b.cm modified;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;
Tue 28/12/2021 00:46:45 3 No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.1;

3.0 Upstream channels
Channel Channel Type T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts
1 US_TYPE_STDMA 0 0 2 0
2 US_TYPE_STDMA 0 0 1 0
3 US_TYPE_STDMA 0 0 0 0
4 US_TYPE_STDMA 0 0 0 0

Any help in getting this resolved once and for all would be appreciated.

[Adduxi]

All your US channels should be 64QAM. Also you need to post the Downstream stats as well .

[Anonymous]

In some areas the 25.8 channel is set to 16QAM due to noise floor. Shouldn't ever be 32 though.

I'm sure VM are looking forward to Christmas lights going off. 

[markk01]

Here are the downstream stats:

3.0 Downstream channels
Channel Frequency (Hz) Power (dBmV) SNR (dB) Modulation Channel ID
25 331000000 6.800003 40.366287 QAM256 25
1 139000000 8.300003 40.366287 QAM256 1
2 147000000 8.500000 40.366287 QAM256 2
3 155000000 8.500000 40.366287 QAM256 3
4 163000000 7.800003 38.983261 QAM256 4
5 171000000 7.199997 38.983261 QAM256 5
6 179000000 6.800003 40.366287 QAM256 6
7 187000000 7.000000 40.366287 QAM256 7
8 195000000 7.000000 40.366287 QAM256 8
9 203000000 6.800003 40.366287 QAM256 9
10 211000000 6.599998 40.366287 QAM256 10
11 219000000 6.599998 40.366287 QAM256 11
12 227000000 6.400002 40.366287 QAM256 12
13 235000000 6.300003 38.983261 QAM256 13
14 243000000 6.099998 40.366287 QAM256 14
15 251000000 6.000000 38.983261 QAM256 15
16 259000000 6.300003 38.983261 QAM256 16
17 267000000 6.800003 40.366287 QAM256 17
18 275000000 7.099998 40.366287 QAM256 18
19 283000000 6.800003 40.366287 QAM256 19
20 291000000 6.400002 40.366287 QAM256 20
21 299000000 6.300003 38.605377 QAM256 21
22 307000000 6.800003 38.983261 QAM256 22
23 315000000 7.099998 40.366287 QAM256 23
24 323000000 7.000000 40.366287 QAM256 24
26 339000000 6.500000 40.946209 QAM256 26
27 347000000 6.699997 40.946209 QAM256 27
28 355000000 6.800003 40.366287 QAM256 28
29 363000000 6.500000 40.366287 QAM256 29
30 371000000 6.099998 40.366287 QAM256 30
31 379000000 6.099998 40.366287 QAM256 31

3.0 Downstream channels
Channel Lock Status RxMER (dB) Pre RS Errors Post RS Errors
25 Locked 40.366287 0 0
1 Locked 40.366287 0 0
2 Locked 40.366287 0 0
3 Locked 40.366287 0 0
4 Locked 38.983261 0 0
5 Locked 38.983261 0 0
6 Locked 40.366287 0 0
7 Locked 40.366287 0 0
8 Locked 40.366287 0 0
9 Locked 40.366287 0 0
10 Locked 40.366287 0 0
11 Locked 40.366287 0 0
12 Locked 40.366287 0 0
13 Locked 38.983261 0 0
14 Locked 40.366287 0 0
15 Locked 38.983261 0 0
16 Locked 38.983261 0 0
17 Locked 40.366287 0 0
18 Locked 40.366287 0 0
19 Locked 40.366287 0 0
20 Locked 40.366287 0 0
21 Locked 38.605377 0 0
22 Locked 38.983261 0 0
23 Locked 40.366287 0 0
24 Locked 40.366287 0 0
26 Locked 40.946209 0 0
27 Locked 40.946209 0 0
28 Locked 40.366287 0 0
29 Locked 40.366287 0 0
30 Locked 40.366287 0 0
31 Locked 40.366287 0 0

3.1 Downstream channels
Channel Channel Width (MHz) FFT Type Number of Active Subcarriers Modulation (Active Profile) First Active Subcarrier (Hz)
159 96 4K 1880 QAM4096 392

3.1 Downstream channels
Channel ID Lock Status RxMER Data (dB) PLC Power (dBmV) Correcteds (Active Profile) Uncorrectables (Active Profile)
159 Locked 43 6.6 427958963 0

[markk01]

Morning ... so this morning the link entirely went down and no surprise as per previous occassions when the link came back up the packet loss has now dissapated.

If this goes by the normal pattern it'll prob last a few days or a week before happening again. Have also noted that all the upload channels are now back at 64 QAM.

Channel Frequency (Hz) Power (dBmV) Symbol Rate (ksps) Modulation Channel ID
1 25800000 39.020599 5120 KSym/sec 64QAM 4
2 32600000 39.770599 5120 KSym/sec 64QAM 3
3 39400000 40.270599 5120 KSym/sec 64QAM 2
4 46200000 40.770599 5120 KSym/sec 64QAM 1

Could really do with someone in VM taking a look at the underlying cause of this.

[John_GS]

Hi markk01

Thanks for posting. Okay so I have run checks and no issues showing, all levels are fine etc. There is a provisioning issue on the base of your account however, which could be causing it. It's a known issue we're aware of. I will come back to you when have an update.

Best

[jem101]

I believe that the 25.8 MHz channel is particularly prone to interference and I’m also sure that I read recently that VM are planning/working on phasing out use of this channel where possible.? Hopefully someone more knowledgable about VM’s plans will be able to confirm or deny - although probably anyone who actually knows what VM’s plans are, is not at liberty to say!

Now having said that, yes ideally all four channels are supposed to be running at 64 QAM but  DOCSIS is designed to ‘sort of’ self adjust itself to compensate for local conditions. So if a particular channel can’t get a reliable connection at a modulation of 64 QAM it will drop to 32, and if that works OK it’ll stay there and ramp back up if and when the conditions improve.

Without doing into all the maths and details of QAM, the difference between 64 and 32 isn’t actually that much, each ‘symbol’, which you can think of as a packet of data transmitted all at once, (OK it’s not really a data packet but work with me on this one), is composed of 6 bits for 64 QAM rather than 5 bits for 32 QAM. Incidentally why 6 bits or 5 bits?; 2^6 is 64, 2^5 is 32 etc.

Take a look at the upstream stats from the Hub, what you see for each channel is something like 5120 ksym/sec at 32 QAM (or ideally 64QAM), so, somewhat crudely, each channel has a capacity of 5120 x 1000 (it’s kilosymbols per second) x 5 (QAM32 is 5 bits per symbol) or 25,600,000 bits per second (or 25 Megabits per second). Compare this with QAM 64 which is (I’ll leave it to you to do the maths) is only a 17% (roughly) reduction in capacity. And that’s only on one of the four bonded channels.

So, if a single channel drops to 32 QAM, then yes, that is an indication of noise ingress on the connection, but it really isn’t the end of the world