Intermittent (but serious) upstream issues

[cabbagelover]

Hi All,

Desperately struggling with intermittent upstream speed issues that make it impossible to work at home.  Service status checker first reports no issues with our connection, but when asking it to check further, it confirms there is a known issue in our area being worked on.  Have called VM customer support multiple times, but all I am given is an expected fix date which is constantly missed, and apologies that they will not do anything else (no details whatsoever about what the problem actually is, no engineer visit, and no compensation).

In terms of what happens, upstream speed drops from usual 25mbps down to prolonged period of 0.1-0.5mbps.  A speed checker app suggests no issue with download speed, which remains at 275mbps.  There are no error lights on router, and in most instances the upload speed returns around 4-6 hours later - usually just as working day ends.  Working from home, I am completely unable to have video calls, upload anything to our cloud filing, send or receive emails, and print documents wirelessly.

I have managed to get through to a floor supervisor once on phone once (on 02/01/23) - advice then was that issue has been taking place since 9th December.  At the time, the supervisor suggested they had spoken directly to an engineer who was on site replacing a cable - but problem continues despite being assured it would finally be over by 04/01/23.  

Issue has got so bad - and financially damaging for our working - that have yesterday ordered a temporary 5G router to use during moments of outage.  Any advice how to reclaim these costs from Virgin gratefully received, although ultimately just hoping this post might reach the expert moderators and provide means to escalate or at least give some assurance on what is going on and when it might be fixed!

Router logs to follow.  Have today set up a BQM which I will share tomorrow am.  Am fairly non-technical, but really incredibly grateful for any and all advice.  Thank you in advance!

[cabbagelover]

Downstream bonded channels

Channel	Frequency (Hz)	Power (dBmV)	SNR (dB)	Modulation	Channel ID
1	235000000	3.5	40	256 qam	13
2	139000000	2	38	256 qam	1
3	147000000	2.2	38	256 qam	2
4	155000000	2.4	40	256 qam	3
5	163000000	2.2	40	256 qam	4
6	171000000	2.2	40	256 qam	5
7	179000000	1.7	38	256 qam	6
8	187000000	1.7	38	256 qam	7
9	195000000	1.7	38	256 qam	8
10	203000000	1.9	38	256 qam	9
11	211000000	2.5	38	256 qam	10
12	219000000	2.9	38	256 qam	11
13	227000000	3.2	40	256 qam	12
14	243000000	3.7	40	256 qam	14
15	251000000	4	40	256 qam	15
16	259000000	4.1	40	256 qam	16
17	267000000	4.5	40	256 qam	17
18	275000000	4.4	40	256 qam	18
19	283000000	4.8	40	256 qam	19
20	291000000	4.9	40	256 qam	20
21	299000000	5.4	40	256 qam	21
22	307000000	5	40	256 qam	22
23	315000000	5.1	40	256 qam	23
24	323000000	5.3	40	256 qam	24

Downstream bonded channels

Channel	Locked Status	RxMER (dB)	Pre RS Errors	Post RS Errors
1	Locked	40.9	10	0
2	Locked	38.9	50	0
3	Locked	38.9	25	0
4	Locked	40.3	16	0
5	Locked	40.3	15	0
6	Locked	40.3	24	0
7	Locked	38.9	9	0
8	Locked	38.9	21	0
9	Locked	38.9	11	0
10	Locked	38.9	17	0
11	Locked	38.9	8	0
12	Locked	38.9	15	0
13	Locked	40.9	9	0
14	Locked	40.3	6	0
15	Locked	40.3	10	0
16	Locked	40.3	21	0
17	Locked	40.3	8	0
18	Locked	40.3	14	0
19	Locked	40.3	15	0
20	Locked	40.3	6	0
21	Locked	40.3	10	0
22	Locked	40.3	16	0
23	Locked	40.3	10	0
24	Locked	40.3	16	0

[cabbagelover]

Upstream bonded channels

Channel	Frequency (Hz)	Power (dBmV)	Symbol Rate (ksps)	Modulation	Channel ID
1	30099959	38	5120	16 qam	10
2	43099395	37.5	5120	16 qam	8
3	23600183	38	5120	16 qam	11
4	49598737	37.5	5120	16 qam	7
5	36599227	37.8	5120	16 qam	9

Upstream bonded channels

Channel	Channel Type	T1 Timeouts	T2 Timeouts	T3 Timeouts	T4 Timeouts
1	ATDMA	0	0	56	0
2	ATDMA	0	0	52	0
3	ATDMA	0	0	67	0
4	ATDMA	0	0	52	0
5	ATDMA	0	0	83	0

Network Log

Time	Priority	Description
19/01/2023 10:04:49	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
19/01/2023 10:04:49	critical	Started Unicast Maintenance Ranging - No Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
19/01/2023 10:01:33	critical	TFTP file complete - but missing mandatory TLV;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
16/01/2023 17:36:51	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
16/01/2023 09:39:3	Error	DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
13/01/2023 05:52:12	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
12/01/2023 21:39:3	Error	DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
10/01/2023 00:36:39	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
10/01/2023 00:27:52	Error	DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
10/01/2023 00:27:50	Error	DHCP RENEW sent - No response for IPv4;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
09/01/2023 10:44:3	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
09/01/2023 10:42:31	Error	DHCP RENEW sent - No response for IPv4;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
05/01/2023 20:05:23	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
05/01/2023 05:50:12	Error	DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
02/01/2023 11:16:29	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
02/01/2023 11:15:18	notice	LAN login Success;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
02/01/2023 10:57:52	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
02/01/2023 10:56:13	notice	LAN login Success;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
01/01/2023 03:05:8	critical	No Ranging Response received - T3 time-out;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;
31/12/2022 19:33:41	Error	DHCP RENEW WARNING - Field invalid in response v4 option;CM-MAC=**:**:**:**:**:**;CMTS-MAC=**:**:**:**:**:**;CM-QOS=1.1;CM-VER=3.0;

[Client62]

So the non technical explanation is the Upstream channels are impacted confirming the experience as reported.

To see the issue in the stats, look at the Upstream bonded channels

In this case there are 5 Upstream bonded channels but all have dropped down to Modulation 16 qam.

16 qam is the slowest upstream rate that maintains a connection even when there is severe noise issues on the service.

32 qam is the medium upstream rate used when there is light noise issues.

64 qam is the fast rate for normal service. ( each 64 qam channel = 27 Mb/s of upstream bandwidth )

Once the local fault (damaged cables etc) have been repaired the Upstream channels should all come back to 64 qam.

[cabbagelover]

Thank you for the reply and detail - it is appreciated.

After another very frustrating afternoon not able to work, and with continued apathy from Virgin customer service, have now arranged for disconnection. Fingers crossed a new provider will be able to give us more certainty.

[Client62]

Sadly Virgin Media's service can be like chalk and cheese.

[legacy1]

Not sure how VM are doing this but they only mostly care about download speed but heres the tricky part to download you have to upload send back small ACK packets which is way more bandwidth then 1Mb for 275Mb download. So clearly VM have done some priority QoS/BWM.

example

[gitty]

The modem uses ACK suppression, so you need to measure at the other end, if you want to know how many ACKs that get through.

[legacy1]

So this ACK suppression is done in modem mode too?

What if this ACK suppression in the Docsis modem is flawed causing an attacker to limit ones bandwidth in some way?

[gitty]

Yes, it also works in modem mode. It works by throwing away unnecessary ACKs between bursts. You should be safe from attackers. 🙂