Why do my DOCSIS subscribers and their Cable Modems get lower speeds than what my DOCSIS config file says they should get?

This is a common question that I am asked and it has more than one answer.  All too often the RF plant is the first to blame for low DOCSIS cable modem speeds, but in many cases the root cause of the problem can be traced back to the cable modem configuration file and/or the lack of appropriate speed test applications in the headend.  Also, some subscriber education is often needed.  Let’s take a look at each one of these.

First the RF plant

Let us assume that you have configured everything else properly, but your subscriber is having slow upstream data rates.  Before you call in the IT or DOCSIS folks, its a good idea to look at the return spectrum using a spectrum analyzer or return path monitoring system.  Even better if you have test equipment that can look at a specific cable modem’s MAC address and see its MER (Modulation Error Ratio) and other impairments such as group delay and micre-reflections, which will not show up on a spectrum analyzer.  Do you have RF problems?  If so, they are the number one cause of throughput issues.  But wait – they are not the only cause of throughput issues.  The investigation must continue if the RF plant is clean.

Capacity Management on the CMTS

Next you will want to look at the CMTS or your equivalent reporting engine to see if you have too many cable modems on the upstream (or downstream if that is the reported bottleneck).  While you are there, look for low SNR values, high levels of codeword errors, high level of T3 or T4 timeouts, and the possibility that the cable modem your subscriber(s) are having issues with are on the flaplist.  Any of these issues will be an indication that you either have an over loaded port on the CMTS or RF impairments.  This means the following recommendations are unlikely to help your immediate problem and you must go back to troubleshooting 101.

DOCSIS Config File, CMTS & Cable Modem

Now that we have ruled out the basics, you need to verify that your cable modem configuration file, downloaded during cable modem registration via TFTP, has been properly sized for bandwidth.  What do I mean by this?  When I started creating DOCSIS config files if I wanted a 5 Mbps upstream so I set the DOCSIS Upstream Maximum Sustained Traffic Rate to 5 Mbps.  This makes complete sense, right?  Well, not always.

You see by setting the maximum traffic rate of 5 Mbps is just part of the equation.  The CMTS operating system, commonly referred to as IOS, and the cable modem firmware & hardware play a role.  In addition there are other parameters in the cable modem config file that can be optimized.

Some older DOCSIS 2.0 cable modems just don’t have the internal capabilities to support high downstream or upstream data rates.  Also, older CMTS IOS versions lack the necessary functions to get the full data rates out DOCSIS 2.0, let alone DOCSIS 3.0.  It is therefore a good idea to make sure that you are always updating your cable modem inventory and staying up to date with your CMTS IOS firmware.

Assuming you are on current firmware and modems, there are two key parameters to set; one in the DOCSIS config file and one in the CMTS.  On the cable modem config file, for the downstream and the upstream optimization of the Maximum Traffic Burst is essential to obtaining fast downstream and upstream data rates.  Testing of TCP traffic suggests that the chosen normal and extended burst values should be on the order of several seconds worth of traffic at the configured average rate. That is, if the average rate is 10 Mbps, then a normal burst size of 10 to 20 Mb.

Cisco recommends the following values for the Maximum Traffic Burst parameters:¹

normal burst = configured rate * (1 byte)/(8 bits) * 1.5 seconds

This can be applied for both the upstream and downstream Maximum Traffic Burst parameters.  Next, on the CMTS it is recommended to enable some form of token bucket shaping.  This helps police CMs that won’t police themselves according to their config file settings.  On a Cisco CMTS the command for enabling this is as follows:

cable up x rate-limit token bucket shaping

Where x is the respective upstream port (i.e. 1).

Local Speedtest Sever

Perhaps one of the biggest problems you will experience are subscribers using sites like www.speedtest.net or www.ookla.com/speedtest. When a subscriber tests the the speed of their DOCSIS service to one of these servers they are testing your DOCSIS network, your IP network and the entire IP network between your headend and wherever the speedtest server is located that they choose.  It is likely that you have no control over the last section of the network.  Any number of impairments such as congestion, routing delays, number of hops, etc. can and do impact the subscriber’s displayed throughput.  So what do you do?

Many cable operators have already deployed local speedtest servers in their headends.  This means that subscribers can run throughput tests on the network entirely controlled by the cable operator (example: speedtest.comcast.net).  Ookla.com is one such company that sells commercial speedtest servers which can easily be deployed in a headend.  The next step is making your speedtest server public and educating your subscribers about your server, the network you control and the network you don’t control.

More…

I have only scratched the surface on DOCSIS throughput optimization.  John Downey of Cisco Systems has produced a very good article on this topic that I highly recommend for further reading. It’s called Understanding DOCSIS Data Throughput and How to Increase it.  Make sure you check it out.

1. http://www.cisco.com/en/US/docs/ios-xml/ios/qos_plcshp/configuration/15-2mt/qos-plcshp-oview.html