Packet loss and Latency during peak hours

[triggnology]

I've been seeing packet loss and latency at peak hours for some time, but specifically Escape from Tarkov and Fifa 23, to the point where they're almost unplayable after 18:00. 

I work shifts so game during the day and rarely experience much packet loss but latency is always a problem. 

I'm aware the latency and packet loss could be from beyond the VM network but wondered if there was anything that could be done? 

[triggnology]

Downstream bonded channels

Channel Frequency (Hz) Power (dBmV) SNR (dB) Modulation Channel ID

1	235000000	4	40	256 qam	13
2	139000000	3.9	40	256 qam	1
3	147000000	4	40	256 qam	2
4	155000000	4	40	256 qam	3
5	163000000	3.9	40	256 qam	4
6	171000000	3.9	40	256 qam	5
7	179000000	4	40	256 qam	6
8	187000000	4.1	40	256 qam	7
9	195000000	4	40	256 qam	8
10	203000000	4	40	256 qam	9
11	211000000	3.9	40	256 qam	10
12	219000000	4	40	256 qam	11
13	227000000	4	40	256 qam	12
14	243000000	3.7	40	256 qam	14
15	251000000	3.9	40	256 qam	15
16	259000000	4.1	40	256 qam	16
17	267000000	4.1	40	256 qam	17
18	275000000	4.3	40	256 qam	18
19	283000000	4.5	43	256 qam	19
20	291000000	4.5	40	256 qam	20
21	299000000	5	40	256 qam	21
22	307000000	5.3	43	256 qam	22
23	315000000	5	40	256 qam	23
24	323000000	5	40	256 qam	24

Downstream bonded channels

Channel Locked Status RxMER (dB) Pre RS Errors Post RS Errors

1	Locked	40.3	16	0
2	Locked	40.9	10	0
3	Locked	40.9	16	0
4	Locked	40.9	11	0
5	Locked	40.9	22	0
6	Locked	40.3	22	0
7	Locked	40.3	20	0
8	Locked	40.3	24	0
9	Locked	40.9	22	0
10	Locked	40.3	25	0
11	Locked	40.3	10	0
12	Locked	40.3	18	0
13	Locked	40.9	16	0
14	Locked	40.9	17	0
15	Locked	40.9	20	0
16	Locked	40.3	16	0
17	Locked	40.9	24	0
18	Locked	40.9	25	0
19	Locked	43.3	24	0
20	Locked	40.9	27	0
21	Locked	40.3	39	0
22	Locked	43.3	32	0
23	Locked	40.9	40	0
24	Locked	40.9	50	0

[triggnology]

Upstream bonded channels

Channel Frequency (Hz) Power (dBmV) Symbol Rate (ksps) Modulation Channel ID

1	43100026	44.5	5120	64 qam	2
2	23600039	43	5120	64 qam	5
3	30100012	43	5120	64 qam	4
4	36599981	43	5120	64 qam	3
5	49600061	44.5	5120	64 qam	1

Upstream bonded channels

Channel Channel Type T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts

1	ATDMA	0	0	1	0
2	ATDMA	0	0	0	0
3	ATDMA	0	0	0	0
4	ATDMA	0	0	0	0
5	ATDMA	0	0	0	0

[triggnology]

Also should mention i'm on a wired connection. When running samknows real speed test it looks clean.

[Andrew-G]

Post a link to a live, shared graph of your BQM, would you?  That may help with the diagnosis.  What I would like to see is a full 24 hour trace.

[triggnology]

Hi Andrew, 

Thanks for your response... 

Is this correct? 

[triggnology]

[triggnology]

[Andrew-G]

That's the thing (and the link too).

Exactly as requested, but it is bad news, I'm afraid.  Your BQM shows a typical over-utilisation pattern - you see how it's very poor during normal waking hours, and then peachy from about half past midnight to 8 am, gets quickly worse, and awful again in the evening? Shows that the network and your hub are working perfectly when there isn't too much traffic.  This is caused by congestion at the head-end of the VM network in your area, which is lack of capacity at the CMTS, resulting in data packets being queued momentarily - but easily enough to tish all over the latency of your connection.  Technically this isn't even a fault as all the equipment works exactly as designed, but the analogy is of a sink being filled faster than it is draining - the drain can work perfectly well, but if the water arrives too fast then the sink backs up and overflows.

VM use the term "over-utilisation", because in their mind, this is the fault of customers using the network too much, rather than admit they've mendaciously sold more contracts than their equipment will support, which is the reality. 

Nothing you can do to improve matters. In some areas VM undertake work to rejig the local networks to balance loads and eliminate over-utilisation.  But sometimes that's either not possible, or judged uneconomic if there's a need to spend money on more equipment.  And sadly VM won't ever admit the truth, so there might be a fault reference and a "fix date", but there's no way of knowing if that fix date is actually backed by an actual plan of action and programme of works. Most of the time it seems not, and as the fix date approaches it is simply moved a month or two ahead, sometimes for years (areas like Bromley and some parts of St Albans have been in and out of over-utilisation for many years).  If there's no fault reference, then it will never be fixed.

Your options:

1) Sit it out, and hope that VM do carry out improvement works.  If you've seen the play "Waiting for Godot" then you already know the plot.

2) Get yourself a new ISP. If you're in a fixed term contract you'll probably have to use the VM complaints process (and arbitration at CISAS if need be) to try and be released from contract without penalty.

3) There is no option 3.

[Andrew-G]

and arbitration at CISAS if need be

Whoops, a force of habit error on my part.  As of 1 Jan this year, it is Ombudsman Services you'd need to involve if you wish to leave and VM won't let you leave without early exit fees.  CISAS who previously acted as VM's complaints adjudicator had seen it all with VM over many years, so understood a lot of the regular VM problems without too much difficulty.  Ombudsman Services are new to this gig, so if going there make sure you explain the nature of the problem, the probable cause and any lack of effective action.  Any adjudicator cannot force VM to take action that the company considers uneconomic, such as capacity improvements, and this means that the one thing you might really want (VM to provide the capacity to make your connection work properly) is not possible - all they can do is force VM to pay compensation for any months of poor connection, pay compo for any poor customer service, and require VM to ler you leave without penalty.