cancel
Showing results for 
Search instead for 
Did you mean: 

BQM Check for Gig1 please

LexLuther
Tuning in

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/b8dc9964ab4a5eb9776f73714f12b19863...

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

SH5 Stats:

Downstream bonded channels

Channel Frequency (Hz) Power (dBmV) SNR (dB) Modulation Channel ID
13300000004.140QAM 25625
22100000004.641QAM 25610
32180000004.541QAM 25611
42260000004.641QAM 25612
52340000004.941QAM 25613
6242000000541QAM 25614
7250000000541QAM 25615
82580000004.941QAM 25616
92660000004.841QAM 25617
102740000004.640QAM 25618
112820000004.640QAM 25619
122900000004.540QAM 25620
132980000004.740QAM 25621
143060000004.840QAM 25622
153140000004.740QAM 25623
163220000004.440QAM 25624
173380000003.940QAM 25626
18346000000440QAM 25627
19354000000440QAM 25628
203620000004.240QAM 25629
213700000004.140QAM 25630
22378000000440QAM 25631
233860000003.539QAM 25632
243940000003.139QAM 25633
254020000002.639QAM 25634
264100000002.639QAM 25635
274180000002.739QAM 25636
284260000002.939QAM 25637
29434000000339QAM 25638
304420000002.939QAM 25639
314500000002.739QAM 25640

Downstream bonded channels

Channel Locked Status RxMER (dB) Pre RS Errors Post RS Errors
1Locked4050
2Locked4120
3Locked4190
4Locked4170
5Locked4150
6Locked4180
7Locked4160
8Locked4130
9Locked4150
10Locked40140
11Locked4050
12Locked4080
13Locked4090
14Locked40120
15Locked4060
16Locked40100
17Locked4080
18Locked4030
19Locked4080
20Locked4070
21Locked40100
22Locked4070
23Locked39110
24Locked3980
25Locked3980
26Locked3970
27Locked3990
28Locked39110
29Locked39110
30Locked39100
31Locked3990

 

Upstream bonded channels

Channel Frequency (Hz) Power (dBmV) Symbol Rate (ksps) Modulation Channel ID
04960000045.35120QAM 641
14310000045.35120QAM 642
23660000044.85120QAM 643
33010000044.35120QAM 644
42360000043.85120QAM 645

Upstream bonded channels

Channel Channel Type T1 Timeouts T2 Timeouts T3 Timeouts T4 Timeouts
0ATDMA0000
1ATDMA0000
2ATDMA0000
3ATDMA0000
4ATDMA0000

 

Does everything look ok?

Thanks

59 REPLIES 59

You were talking about doing your own AQM in the downstream, so I figured you were talking about a local issue - when you are trying to send more data than the modem is allowed to transmit, which results in bufferbloat.

Congestion is more tricky. LLD can also help in this scenario. The CMTS can see, if the modem is requesting bandwidth for a low latency packet, and can then schedule it to be transmitted in the very near future, instead of later.


@legacy1 wrote:

@gitty wrote:
The CMTS doesn't deal with bufferbloat in the upstream. That must be handled by the modem.

The modem cant do nothing when the area is under load the CMTS just says "yup keep it coming!" but if you can limit the channels one by one then their is way for Docsis to not over do its self preventing buffering in modems. As it is you can be idle and the ping is stuck in the buffer and so your ping is delayed.    


The CMTS doesn't say that at all, quite the opposite. 

The CMTS allocates capacity to the modems based on a scheduler. Modems request transmission slots and, if they can't get them, that's where the latency comes in. The CMTS will either give them a negative grant or a zero length grant until it can service them. 

The ping isn't stuck in any buffer while idle beyond as necessary given the shared nature of the access network. The modem will request the minislots for it when it next receives an upstream contention slot, these are every couple of milliseconds, then transmit at the allocated time.

This all aside you would never shape behind the CMTS, you'd shape in it using the scheduler, and manipulating how modems handle their requests. Inbound shaping trades latency for loss. LLD manages bufferbloat superbly and is all about the modems. Have a read of it. It is outbound and has to be. 

The major cause why BQM might look grim while speeds are normal is because modems with data constantly in their buffer can encapsulate their next transmit request in with the current batch of data, while a BQM ping may rely on the contended slots within the upstream MAP.

You can actually tell when a customer has had a little use on their BQM: when the minimum is lower that normal it means either the request for that ping responses's data or the response itself was attached to an existing transmission so no REQ-MAP-send, either MAP-send or straight to send if it were concatenated in with an earlier request. 

legacy1
Alessandro Volta

@IPFreely wrote:

The ping isn't stuck in any buffer while idle beyond as necessary given the shared nature of the access network.

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.  

The scheduler is dumb for trying to give slots that cant be cleared in time so you buffer in the modem.   

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. 

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?    

---------------------------------------------------------------

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-docsis

You'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.

DOCSIS scheduling has always been about highest possible throughput. LLD changes that. It will take latency into higher consideration, which can lead to less efficient throughput (total). PGS is an optional feature of LLD which takes this idea to another level. It will preallocate bandwidth for you.

🙂

Andrew-G
Alessandro Volta

I am enjoying following this (now wildly off-topic) discussion, and the wisdom of some contributors, but I have to observe that LLD and other DOCSIS enhancements would be an investment that comes with technical risk, significant testing and implementation costs, yet offer few prospects of recovering their costs since VM have committed to XGS-PON to be rolled out by 2028. 

For other LG group companies that are adopting D4.0 the situation is different, but VM have said they're doing XGS instead of D4.0, and it therefore makes no sense to keep playing with future DOCSIS upgrades that will be obsolete long before the deliver any commercial value.  I know you'll immediately be countering with "ah, but 2028 is not a cut off date for DOCSIS, years of life left in it!" but if you believe that, then how will VM get a return on their significant XGS-PON investments?  Project Mustang (the XGS-PON roll out) is forecast at around £5-6bn with interest payments of around £275m a year assuming interest rates stay where they are now, and depreciation costs of at least the same if not double that.  As a cable business, VM is already a debt-junkie with around £14bn of debt attributable to VM, and has made no net return to shareholders for a decade or more.  The number of customers who VM lose (or can't sign up) because of the latency performance of D3.1 will be in the low single digit percentage range, possibly even below 1%, no matter how cheap LLD might be it will still have no return, and VM will still need to start making returns on the Mustang investments.  If VM do want to invest for commercial reasons then there's far more obvious opportunities amongst the broken processes, poor systems, chaotic under-performing outsource contracts, and low quality business model of the customer services and support areas.

LLD is a matter of support in firmware and then the configuration of it, so it shouldn't be that expensive to roll out. There is the risk of some operators making it a paid service. The low latency traffic runs in its own separate service flow between the modem and CMTS. This service flow may be enabled for all by default, or only for paying customers.

The testing part... A lot of interoperability events have been held by CableLabs, to find all the bugs and make it work flawless between vendors. With a little luck, the technical risk of rolling it out should be minimal.

Andrew-G
Alessandro Volta

Testing by Cablelabs is an essential development path but means little in the field - look at how long VM have been trialling 2.5 Gbps?  D3.1 was ratified back when, in 2013, secret trials would have started a year or so later I'd guess, but the UK publicly announced field trials for 2.5 Gbps only started in 2020 and are still rumbling on in multiple locations, still with no product that customers can buy.  There's also a faint sniff of higher upload speeds on the way, although nothing official.  VM's network bods are rightly cautious before letting some fancy new technology loose in the field across millions of connections, but that means change is slow and therefore expensive, even if executing the change is seen as "only" changing modem firmware.  But regardless, that still doesn't answer the question of why do it at all when for the UK market DOCSIS is in it's sunset years?    

Let's imagine that VM did implement LLD, and were able to get latency down to the standards of a good Openreach FTTP connection (12ms on my BQM), and that they roll out 2.5 Gbps, maybe even with faster upload, all for two and sixpence.  We can call this DOCSIS three-point-half.  It's still going to be eighteen months before LLD would see the light of day, and where would that leave the business case to get customers to pay for PON-based services and recoup Mustang's £5+bn ?  In the world of this hypothesised upgrade to D three-point-half, I'd imagine at best 1% of the customer base would then be willing to pay more to upgrade to PON, because the only customer offer that would beat this mythically upgraded DOCIS would be for a 5-10 Gbps fully symmetrical package.  For a tiny, tiny minority of punters there's a use case for those speeds, for a tiny, tiny minority there's saddo bragging rights by having the fastest connection on offer. 

For the minority of people who understand what we're talking about and care about low latency, they'll mostly already be with an Openreach connection, so customer attrition from VM due to DOCSIS latency will be negligible.  Even if LLD implementation were cost-free, what competent network operator would take the operational risks of an LLD roll out when that gives them no commercial benefit, and puts in the field a more complex technology that will inevitably result in more support calls and disputes by bonehead customers who think that their Gamer LLD package means they'll be able to have a killer ping when connecting via wifi across three floors and through supporting walls, using a cheapskate VM hub?  

If I were an investor in LG, I'd be utterly horrified if I learned that VM were investing resources to test and potentially implement improvements to DOCSIS technology when (as an investor) I'd recently agreed with management's choice to invest billions to go with PON instead of D 4.0.

Sure you haven't combined the costs of Mustang and Lightning? 

Mustang is supposed to come in sub-£100 per premises passed and less than £1.5 billion total.

Believe VM aren't doing any more plant upgrade in terms of RF bandwidth but still have some plans for the HFC. 


@IPFreely wrote:

Sure you haven't combined the costs of Mustang and Lightning? 

Mustang is supposed to come in sub-£100 per premises passed and less than £1.5 billion total.

Believe VM aren't doing any more plant upgrade in terms of RF bandwidth but still have some plans for the HFC. 


You're right, my maths is shonky, although if they can stick to a £1.5bn budget in these times I'll be amazed.  Even so, it still doesn't take away from my argument - why invest in improving the old technology when you're telling the world you are building it's replacement?  There appears to be some muddled thinking at VM Towers, that they'll put in the basics of XGS-PON for some billions, with nothing budgeted for drop links and CPE.  If VM are indeed investing in HFC and doing something akin to my D three-point-half (esp symmetric speeds), they surely they may as well have gone the whole hog of D4.0, and not bothered with the PON plans at all.  Worst case, VM keep twiddling the knobs on DOCSIS but that won't get symmetric speeds, and by the time any VM XGS-PON product is available, Openreach and altnets will have cornered such commercial market as exists for symmetrical or fast uploads.  Best case VM upgrade DOCSIS, it delivers LLD and symmetric, is available commercially to counter (eg) Vodafone recent 2 Gbps symmetric announcement, but then there's no returns on the PON investment because nobody will want anything better than 2-10 gig symmetric.  It's not good either way, is it?

Last time I saw planning that bad was when working in the former Soviet Union shortly after the fall of Communism.  The city of Leningrad needed two new super sewers, each leading to a massive new sewage treatment plant to serve respectively the south and north of the city.  As they didn't have the money to do all of it, they built one super sewer and one treatment plant.  Unfortunately, due to VM-style planning, they built the northern sewer to a treatment plant that didn't exist, and built the southern treatment plant but without any sewer to bring in the raw foulage, with the result that the entirety of the city's sewage from 5.5m people and a heavy industrial base was thrown into the Gulf of Finland without any treatment at all.