Hi allHad my M600 upgraded to Gig1 few days ago, and got a SH5SH4 never had a attenuator fitted so was a easy swap.I set up BQM and see lots of high latency spikes (yellow), is this normal?Today: https://www.thinkbroadband.com/broadband/monitoring/quality/share/b8dc9964ab4a5eb9776f73714f12b19863de3bd5-17-12-2022Live: https://www.thinkbroadband.com/broadband/monitoring/quality/share/9a0fde01618918325440ac6fd4cb281788dc8958SH5 Stats:Downstream bonded channelsChannel Frequency (Hz) Power (dBmV) SNR (dB) Modulation Channel ID 13300000004.140QAM 2562522100000004.641QAM 2561032180000004.541QAM 2561142260000004.641QAM 2561252340000004.941QAM 256136242000000541QAM 256147250000000541QAM 2561582580000004.941QAM 2561692660000004.841QAM 25617102740000004.640QAM 25618112820000004.640QAM 25619122900000004.540QAM 25620132980000004.740QAM 25621143060000004.840QAM 25622153140000004.740QAM 25623163220000004.440QAM 25624173380000003.940QAM 2562618346000000440QAM 2562719354000000440QAM 25628203620000004.240QAM 25629213700000004.140QAM 2563022378000000440QAM 25631233860000003.539QAM 25632243940000003.139QAM 25633254020000002.639QAM 25634264100000002.639QAM 25635274180000002.739QAM 25636284260000002.939QAM 2563729434000000339QAM 25638304420000002.939QAM 25639314500000002.739QAM 25640Downstream bonded channelsChannel Locked Status RxMER (dB) Pre RS Errors Post RS Errors 1Locked40502Locked41203Locked41904Locked41705Locked41506Locked41807Locked41608Locked41309Locked415010Locked4014011Locked405012Locked408013Locked409014Locked4012015Locked406016Locked4010017Locked408018Locked403019Locked408020Locked407021Locked4010022Locked407023Locked3911024Locked398025Locked398026Locked397027Locked399028Locked3911029Locked3911030Locked3910031Locked3990 Upstream bonded channelsChannel Frequency (Hz) Power (dBmV) Symbol Rate (ksps) Modulation Channel ID 04960000045.35120QAM 64114310000045.35120QAM 64223660000044.85120QAM 64333010000044.35120QAM 64442360000043.85120QAM 645Upstream bonded channelsChannel Channel Type T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts 0ATDMA00001ATDMA00002ATDMA00003ATDMA00004ATDMA0000 Does everything look ok?Thanks

You seem awfully put out by this and seem to think you know QoS better than the people who maintain and write the DoCSIS standards which is an interesting play.'Its stuck in a buffer aright till the modem get a transmission slot how else would it get delayed ping, like request is sent modem needs a transmission slot one not available oh we just drop it then! heaven for bid.'As I said, 'beyond as necessary given the shared nature of the access network'. If a slot is not available the modem buffers the data for a period, it doesn't just drop. It has to as there's a gigabit going into it but whatever going out onto the WAN and that's actually where most of the delay is and where it should be managed: that queue. Once the modem's buffer is full then it drops on a first in, first out basis. This buffer is actually an implementation of the modem's software, not DoCSIS, so can be modified which is part of how LLD works.'The scheduler is dumb for trying to give slots that cant be cleared in time so you buffer in the modem.'The scheduler doesn't give slots that can't be cleared in time. The entire point is that the scheduler doesn't give slots or gives zero length slots which is why things have to buffer. If you start giving everything slots whether it needs it or not you are no longer a best effort service you're an unsolicited grant service. The scheduler is also not specified in the DoCSIS standards.'So in short my Idea is to not make the scheduler over do its self by adding per channel after Docsis a rate limit by ethernet equipment to 20Mb each.'You want to implement inbound shaping, which isn't ideal, by having the CMTS no longer multiplex the upstream channels but break each one out as a VLAN so that each may be shaped which can't work. The CMTS is under no obligation to balance the upstream channels evenly and most don't. They'll fill them based on a variety of factors, not least of which being the physical RF condition of the channels alongside their type, modulation and channel width. The channels themselves may vary in capacity depending on modulation order being used.Some of the kit on VM's network and others is remote PHY. The CMTS never sees the upload bursts they're handled by a cabinet which transmits each node's upstream traffic as a single multiplexed stream along a pseudowire back to the CCAP core. Are you wanting VM to redesign R-PHY so that it places every upstream channel in its own pseudowire?You're hoping that the scheduler will never be faced with more traffic than it can handle ignoring that the modems have no visibility of how much they can transmit without breaking a channel. Your idea will cause exactly what you're saying you didn't want: modems to just blast away and the CMTS to keep offering slots. It has no idea whether the limit behind it has been reached so it can't balance traffic properly. You want to trade some latency for packet loss.'If LLD is a thing why are VM not using it? or is it that in some area the Docsis is cheap without it and VM don't enable it where it can because that would be unfair to the others on cheap CMTS setups?' LLD relies on the vendors of modems and CMTS to write the software to deploy it. That is all it is, a software change. VM are testing it. It does, however, need 3.1 modems according to the specifications though perhaps 3.0 could be retrofit. See https://www.cablelabs.com/technologies/low-latency-docsisYou're offering something of a home lab solution to something that doesn't accommodate it. Shaping should always, always be done outbound whenever possible. Your idea causes packet loss unnecessarily, will break the DoCSIS side any time someone tries using something that doesn't care about packet loss like iPerf UDP, will break video streaming if it's using UDP, and will allow and, actually, invite microbursts where an upstream channel is briefly saturated before dropping packets causes higher level protocols to slow down.You're also, wrongly, attributing delay to the wrong things. Latency rises without the DoCSIS network saturating as that's the nature of TDMA alongside the need for modems to queue traffic due to the big discrepancy between their LAN and WAN. Latency used to be awful at 75% utilisation on a channel but scheduling, that thing you consider dumb, remedied this. Channels can get very close to saturation without latency increases now and with LLD ensuring that modems request slots intelligently (the modem software side) alongside CMTS being programmed to offer those slots more frequently to the latency-sensitive queue (the CMTS software side) latency-sensitive traffic can be given a great experience even on a congested network.

I'm unconvinced, Mr Pearce. There's packet loss visible across the day and through the night and for that length of time the OP would struggle to saturate the 50 Mbps upstream, plus the nasty latency profile matches exactly what you'd expect on an over-subscribed segment of VM's network. It's possible that there's two problems - one causing the packet loss, and the other being the capacity constraint that's causing the latency issues.From years of experience looking at these, I'd suspect at the level of over-subscription the BQM shows, VM will deny on their grandmother's life that there is any problem of capacity or utilisation. And if that's the case and they're not prepared to admit the BQM shows a problem, then the problem will never be fixed. If they do admit there's a problem of over-utilisation, then the years of experience tell me the promised fix date has been plucked from somebody's fundament and means nothing.As for LexLuther, I'm afraid if I'm right (and I'm not always*), then you will have to live with that sort of performance unless you (a) have a better ISP alternative, and (b) are willing to play a game of hardball with VM to be released from contract without penalty.* Just 99% of the time.

Changing the cables won't help, as there's no evidence of any noise in the hub stats, which are excellent. This is simply a lack of capacity, and the only fix for that other than changing ISP is for VM to invest serious time and skill in analysing the local network, and then re-segmenting - possibly with additional CMTS capacity. That's not something with the capability of the field technicians that visit customer properties, it requires a referral to VM's Network team, then for that team to analyse the performance. If they decide performance is acceptable (even if it's not acceptable to you) nothing will be done. If they agree there's a problem, it gets a fault reference and a review date. But that doesn't mean that actual work to both plan a solution and implement a solution will occur. Your area problem sits in a big pile of jobs, all competing for funds and skills. If the CEO's teenage son is complaining about latency, that'll go to the top of the pile, apart from that it's who shouts loudest, chances are your area will bounce around in the stack of jobs, and maybe it'll get into those planned to be done. There will be cost benefit analysis, if there's no payback then it will never get done.You'll never know what the situation is unless and until it gets fixed.

Power levels look fine.Some packet loss on the BQM, however that could be normal depending if you are saturating your download/upload.

What can I do to resolve ?There is nothing within your control that will fix an over-utilisation fault. I believe your BQM shows a typical over-utilisation pattern - on the sample you posted, you see how it's very poor during normal waking hours, worst at peak traffic hours and then peachy from about half past midnight to 9 am? Shows that the network and your hub are working perfectly when there isn't too much traffic across the VM network in your area. Nothing you can do to improve matters, as the cause is congestion at the big box called a CMTS that sits at the head end of the local network. That congestion is caused by VM selling more contracts than the network has reliable capacity for, as a result data packets get queued at the CMTS, causing latency spikes. 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. Compared to many I've seen, your BQM is the worst, and I'd expect VM to insist that the network is fine and fault free. Your options:1) Sit it out, and hope that VM do carry out improvement works.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, using as a basis the Consumer Rights Act 2015, which requires services to be delivered with reasonable skill and care. You'll have to build a case backed by multiple days of BQM plots that show that magic profile where it all works nicely in the small hours of the night, and you should expect VM to resist, and you have to involve CISAS.

LexLuther

Tuning in

3 years ago

BQM Check for Gig1 please

Hi all

Had my M600 upgraded to Gig1 few days ago, and got a SH5

SH4 never had a attenuator fitted so was a easy swap.

I set up BQM and see lots of high latency spikes (yellow), is this normal?

Today: https://www.thinkbroadband.com/broadband/monitoring/quality/share/b8dc9964ab4a5eb9776f73714f12b19863de3bd5-17-12-2022

Live: https://www.thinkbroadband.com/broadband/monitoring/quality/share/9a0fde01618918325440ac6fd4cb281788dc8958

SH5 Stats:

Downstream bonded channels

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

1	330000000	4.1	40	QAM 256	25
2	210000000	4.6	41	QAM 256	10
3	218000000	4.5	41	QAM 256	11
4	226000000	4.6	41	QAM 256	12
5	234000000	4.9	41	QAM 256	13
6	242000000	5	41	QAM 256	14
7	250000000	5	41	QAM 256	15
8	258000000	4.9	41	QAM 256	16
9	266000000	4.8	41	QAM 256	17
10	274000000	4.6	40	QAM 256	18
11	282000000	4.6	40	QAM 256	19
12	290000000	4.5	40	QAM 256	20
13	298000000	4.7	40	QAM 256	21
14	306000000	4.8	40	QAM 256	22
15	314000000	4.7	40	QAM 256	23
16	322000000	4.4	40	QAM 256	24
17	338000000	3.9	40	QAM 256	26
18	346000000	4	40	QAM 256	27
19	354000000	4	40	QAM 256	28
20	362000000	4.2	40	QAM 256	29
21	370000000	4.1	40	QAM 256	30
22	378000000	4	40	QAM 256	31
23	386000000	3.5	39	QAM 256	32
24	394000000	3.1	39	QAM 256	33
25	402000000	2.6	39	QAM 256	34
26	410000000	2.6	39	QAM 256	35
27	418000000	2.7	39	QAM 256	36
28	426000000	2.9	39	QAM 256	37
29	434000000	3	39	QAM 256	38
30	442000000	2.9	39	QAM 256	39
31	450000000	2.7	39	QAM 256	40

Downstream bonded channels

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

1	Locked	40	5
2	Locked	41	2
3	Locked	41	9
4	Locked	41	7
5	Locked	41	5
6	Locked	41	8
7	Locked	41	6
8	Locked	41	3
9	Locked	41	5
10	Locked	40	14
11	Locked	40	5
12	Locked	40	8
13	Locked	40	9
14	Locked	40	12
15	Locked	40	6
16	Locked	40	10
17	Locked	40	8
18	Locked	40	3
19	Locked	40	8
20	Locked	40	7
21	Locked	40	10
22	Locked	40	7
23	Locked	39	11
24	Locked	39	8
25	Locked	39	8
26	Locked	39	7
27	Locked	39	9
28	Locked	39	11
29	Locked	39	11
30	Locked	39	10
31	Locked	39	9

Upstream bonded channels

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

0	49600000	45.3	5120	QAM 64	1
1	43100000	45.3	5120	QAM 64	2
2	36600000	44.8	5120	QAM 64	3
3	30100000	44.3	5120	QAM 64	4
4	23600000	43.8	5120	QAM 64	5

Upstream bonded channels

Channel Channel Type T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts

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

Does everything look ok?

Thanks

bqm

75 Replies

carl_pearce
Superstar
3 years ago
Power levels look fine.
Some packet loss on the BQM, however that could be normal depending if you are saturating your download/upload.
- Andrew-G
  Alessandro Volta
  3 years ago
  I'm unconvinced, Mr Pearce. There's packet loss visible across the day and through the night and for that length of time the OP would struggle to saturate the 50 Mbps upstream, plus the nasty latency profile matches exactly what you'd expect on an over-subscribed segment of VM's network. It's possible that there's two problems - one causing the packet loss, and the other being the capacity constraint that's causing the latency issues.
  From years of experience looking at these, I'd suspect at the level of over-subscription the BQM shows, VM will deny on their grandmother's life that there is any problem of capacity or utilisation. And if that's the case and they're not prepared to admit the BQM shows a problem, then the problem will never be fixed. If they do admit there's a problem of over-utilisation, then the years of experience tell me the promised fix date has been plucked from somebody's fundament and means nothing.
  As for LexLuther, I'm afraid if I'm right (and I'm not always*), then you will have to live with that sort of performance unless you (a) have a better ISP alternative, and (b) are willing to play a game of hardball with VM to be released from contract without penalty.
  * Just 99% of the time.
  - legacy1
    Alessandro Volta
    3 years ago
    I'm sure when BQM first showed packet loss and latency VM blamed it on are routers so they made the hubs and it was no better.
    
    At 10pm – 11pm its utilisation or you doing a download or upload VM I'm sure VM could do a temp fix with Ethernet after docsis or they just have to put in more capacity.
    
    As for packet loss thats likely a sign that your connection has noise.
Kain_W
Forum Team (Retired)
3 years ago
Hi LexLuther,

Thanks for your post and welcome back to the community.

Apologies for the issues you are experiencing, may I ask regarding the latency has this been an issue in the past too?

Let us know,
- LexLuther
  Tuning in
  3 years ago
  Hi. Yes it’s always been like this. I thought moving to Gig1 and SH5 would fix it.
  I had a sh4 before on m600 broadband.
  
  What can I do to resolve ?
  - Andrew-G
    Alessandro Volta
    3 years ago
    What can I do to resolve ?
    There is nothing within your control that will fix an over-utilisation fault. I believe your BQM shows a typical over-utilisation pattern - on the sample you posted, you see how it's very poor during normal waking hours, worst at peak traffic hours and then peachy from about half past midnight to 9 am? Shows that the network and your hub are working perfectly when there isn't too much traffic across the VM network in your area. Nothing you can do to improve matters, as the cause is congestion at the big box called a CMTS that sits at the head end of the local network. That congestion is caused by VM selling more contracts than the network has reliable capacity for, as a result data packets get queued at the CMTS, causing latency spikes. 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.
    Compared to many I've seen, your BQM is the worst, and I'd expect VM to insist that the network is fine and fault free. Your options:
    
    1) Sit it out, and hope that VM do carry out improvement works.
    
    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, using as a basis the Consumer Rights Act 2015, which requires services to be delivered with reasonable skill and care. You'll have to build a case backed by multiple days of BQM plots that show that magic profile where it all works nicely in the small hours of the night, and you should expect VM to resist, and you have to involve CISAS.
Sauce245
On our wavelength
12 months ago
Stumbled across this thread just now, crazy to see your live graph is still absolutely all over the place during peak times 2 years later. I have just moved in to a new flat where VM is the only viable option and was worried about my BQM but after having a look around the forums I don't think I can complain too much 😂 This is before I install my BE98 and put the Hub 5 where it belongs, in modem mode too. (ignore the packet loss it was a restart):
Still hurts coming from a full FTTP connection though:
- Matthew_ML
  Forum Team
  12 months ago
  Hey Sauce245, thank you for reaching out and I am sorry to hear this.
  
  I can see you have spoken to the team since this post, did they manage to help at all?
  - Sauce245
    On our wavelength
    12 months ago
    Hey Matt,
    I spoke to the team regarding something else, it was to do with the activation date being wrong, that has been fixed thanks.
    I have another sort of issue though if you wouldn't mind having a look please? Basically, I moved to a new flat with Gig1 and the flat has VM ports in 3 rooms. Looks like the other ports are fed by coax from the master port, I guess they were used for VM TV by the previous tenant. I have plugged in the cable feeding the bedroom port from the master port, and plugged the router in to the port in the bedroom, it works in terms of speed (the upload seems to struggle to get above 85Mb though), but I keep seeing random packet loss and noise on the BQM, especially when running speed tests.
    Would you mind taking a look at my config to see if using this secondary port in the bedroom is OK? I haven't actually moved in fully to the flat yet so haven't been able to properly test it with online games or anything like that.
    If not is it possible to get the master port moved? I really need the wired connection.
    Thanks in advance. My Broadband Ping
    P.S hopefully I didn't include any sensitive info in the screenshots.