Downstream Speed issues after 16QAM Implementation |

You are here

Downstream Speed issues after 16QAM Implementation

11 posts / 0 new
Last post
Anonymous (not verified)
Downstream Speed issues after 16QAM Implementation

We have had a few customers report Downstream speed issues after switching from QPSK to 16QAM on our upstreams. These modems, however, hit their Upstream Speed caps every time. When QPSK is set back to that upstream, the downstream speeds return.

Example - 5Mb/512kbps Config File
QPSK - 4.8Mb/500kbps speed test
16QAM - 600kbps/500kbps speet test

(These are speed tests that are run inside our network)

Basic Info:
The modem used is a Motorola SB 5101, the CMTS is a Motorola BSR-1000

One of the customers is 3 amps deep in the cascade, the other is 2 deep. They are also close to the amplifiers.

In one Node, the customer has the following readings at the modem:
Channel 116 +1.7db
Channel 76 +2.2db
Channel 35 +2.8db
Channel 2 +8.1db

Inserting a step attenuator in line with the modem caused the modem to transmit harder, and once the modem got to 55 db, the speeds increased. The modem had problems dropping offline, but the speeds were much better, returning the upstream to QPSK restored the downstream speed.

We have the Sunrise AT2500HMQ with CM1000 w/USG. We have been proofing our plant for 16QAM signals using the Sunrise Upstream Characterization Equipment. We are seeing Group Delay in the neighborhood of 160ns at a couple of these troublesome areas, while the rest of our plant performs at less than 60ns. We are not seeing any other impairments using the analyzer.

Looking for some feedback on to what we possibly could be missing on the Plant side or any ideas on what to look for to fix these issues.


Downstream Speed issues after 16QAM Implementation

Sounds like poor upstream performance for some reason. Missed TCP acks cause retransmits and poor TCP windowing/speeds.

You didn't show the native modem xmit levels, but I'm guessing they're low. If they're not, there may be some other return sweep/padding issues that need to be addressed that are causing low return SNR/MER.

What are the return target levels at the CMTS? What's the SNR of the specific modems having issues?

For example:
#sho cable modem 0009.0e41.b49c phy

MAC Address Interface USPwr USSNR Timing Mod
(tenthdBmV) (tenthdB) Offset Type
0008.0e41.b49c C0/0/U3 11 271 1006 TDMA

This modem is hitting the cmts at 1.1db (actual target 1.0) and has an upstream reported SNR of 27.1. In the field, its xmit level is +45. Everyone is happy. :)

Generally, you want 25db or better MER at the CMTS to run 16QAM. Clean plant should be able to give you 30db without any problem.

#sho controller cable 0/0 upstream 3

Cable 0/0/U3
is up
Frequency 17.200000 MHz, Channel Width 3.200000 MHz, 16-QAM, Symbol Rate 2.560000 Msps
SNR 29.8 dB
Nominal Input Power Level 1 dBmV

Did you double the return bandwidth when switching from QPSK to 16QAM -- ie, 1.6mhz wide to 3.2mhz? If so, did you increase the return target by 3db to compensate?

These commands are from a BSR64k but there should be similar commands on the 1000.

docsisdude (not verified)
a few things

Try using a frequency further away from the rolloff of the return amp diplex filters, that should resolve the group delay issues.

Also you might want to investigate turning on "pre-equalization" which is very helpful to modems as it allows them to take advantage of their ability to overcome distortions in the return plant.

davidslopez (not verified)
I have the following values for QPSK, symbol rate 1,280 msps

First Case
USPWR=50.05 dBm
USSNR=25,85 dB
DSPWR=-3,08 dBm
DSSNR=30,07 dB

Second Case
USPWR=49.05 dBm
USSNR=24,92 dB
DSPWR=-4,06 dBm
DSSNR= 27,08dB

I´ll need some tresholds for certify my cable docsis network


apx (not verified)
Downstream Speed Issues

I too am seeing similar results as posted above. Because of what has been stated, I will check for this tomorrow, and see if the areas that I'm seeing effected are QAM16. QAM16 and QPSK are both implemented in the upstreams for the network that I support, so I am trying to find a common denominator in this. Thank you for the information posted here thus far.

Anonymous (not verified)
Downstream Speed issues after 16QAM Implementation

Thanks for the reply YoYo,

We were already running 3.2 channel width with QPSK.
Here are the Stats for one modem that was having this issue.
Levels were taken at time Modem was using 16QAM.

Upstream Power Level: 48.8 dBmV
Downstream Power Level: -0.6 dBmV
Upstream SNR: 27.2 db
Downstream SNR: 37.1 db

#sh cable modem 0018.C0BC.D504 phy
MAC Address USPwr USSNR Timing
(dBmV) (tenthdB) Offset
0018.c0bc.d504 -6 276 2841

#sh cont cable 0/0 upstream 1

Cable 0/0 Upstream 1 is up
Frequency 32.000000 MHz, Channel Width 3.200000 MHz, 16QAM, Symbol Rate 2.560000 Msps
Spectrum Group:
SNR 277 dBmv
Nominal Input Power Level 0 dBmV

The plant (from what we can see) is in really good shape. I did find some pretty dominant Micro-reflections being generating from 'Self' Terminating 2.4 taps. I was seeing borderline Pre-FEC Errors at that time and since then they have Disappeared once terminated. Downstream and Upstream MER are both above 35dB.

Here are some screen shots using the Sunrise Upstream Characterization Tool. This is our AT2500HMQ analyzing the 16QAM carrier that we were generating from the location of the Modem having the issue.

Seems a big offset like it

Seems a big offset like it was after 10-th amp or so, why is that?

Downstream Speed issues after 16QAM Implementation

It looks like you've got everything well under control in the RF domain. I had assumed low return SNR from the modem itself, but 27.6 is fine. The reason that came to mind is because you mentioned the speed went up with the modem xmit level. That seemed really suspicious... I can't think of any reason why a modem with a downstream/upstream SNR of 37/27 at 256/16QAM and normal levels would have any issues.

I believe the SB5101s on my plant are running I'm not aware of any specific problems with them.

Are the affected modems incrementing T3s? If you put a 5120 in place of the 5101 does the same issue exist? If the speed issue is due to packet loss in either direction, your tech should see be able to do a network capture at the customer premise with Wireshark (Ethereal) and see TCP retransmit messages during local downloads.

Alternatively, if you have access to a linux box you could also try (as root) flooding the management address of the modem with pings like such:

# ping -f
PING ( 56(84) bytes of data.

Let it run for a minute or so. Lost packets will show up as dots. Hit control-C to quit and check the results. My results after 35 seconds show 3100 packets sent and received to a modem with no significant loss.

--- ping statistics ---
3102 packets transmitted, 3101 received, 0% packet loss, time 36381ms
rtt min/avg/max/mdev = 8.967/14.678/51.734/4.384 ms, pipe 5, ipg/ewma 11.732/15.651 ms

Hopefully the issue is specific to certain hardware/firmware on the CPE side and can be easily addressed with updates.

Anonymous (not verified)
Downstream Speed issues after 16QAM Implementation

The modem was running SB5101- I upgraded to SB5101-

The modem was not showing any unusual events in the logs. No T3 timeouts. We swapped out the modem for an older 5100 and it experienced that same problem with fluxuating Download speeds. Speeds were better through the Sunrise CM1000 meter with its modem module. 95% of our modems in the field are Moto SB5100 and SB5101. This issue is not widespread and so far only have found 3 modems with similiar issues. I have some Arris modems with SIP MTAs built in coming soon. If they dont experience the issue, then we know to throw it at Motorola.

At the modem with issues, no packet loss was seen and no latency. Pings were done from the CMTS to the Modem and Modem to the web. The issue has us baffled.

Anonymous (not verified)
Downstream Speed issues after 16QAM Implementation

This might possibly be a combo of things. The firmware and plant conditions. I had a customer reporting almost the exact same issue with slow download speeds off an upstream running 16QAM this morning.

Firmware might of fixed the issue. I have 3 other customers that I know of with the issue at 16QAM. This customer has our 3.0MB/384kbps package. Here are some tests with firmware that I ran this morning. This issue seemed to be resolved with SB5101- firmware. Unable to replicate issue in our Lab which is the frustrating part.

SB5101- (1.2-1.5MB download speed)
SB5101- (725kbps - 1.9MB download speed)
SB5101- (3.0MB Consistantly)
SB5101- (1.2-1.6MB download speed)

Millatron (not verified)
Hey all, I joined here

Hey all, I joined here mainly because I am seeing similar challenges. I'm a TSR2 for an ISP in Canada and we have recently switched to 16qam from qpsk for all of our upstream channels. Now I am seeing a number of reports of slow downstream. The downstream channel utilization is only at 16mbps on the card but we are seeing speed test results of only 2mbit or lower (modems are provisioned for 10mbps with a speedboost utility that allows modems to "uncap" for the first 10 to 20 seconds of a download) with this setup we usually see 10-14 mbit results due to the boost at the start. To give an example of a card with these challenges:

Description: Cable Downstream 1/0
Max Speed: 42884296 b/s

Values at last update:
Average bits out (for the day):
Cur: 16.89 Mbits/sec
Avg: 14.67 Mbits/sec
Max: 28.45 Mbits/sec

Operating Freq. 117mhz
Width 6.0

Cable Upstream Logical Channel - 1/1/0

Max Speed: 10240000 b/s

Values at last update:
Average bits in (for the day):
Cur: 955.73 kbits/sec
Avg: 1.51 Mbits/sec
Max: 3.03 Mbits/sec

Operating Freq. 28.1
width 3.2
USnR 28.0db

Here is the modem in question on the card above, speed test shows 2mbit down and 964kbit up

Software Image Filename SB5102N-
Software Version SB5102N-
Modem Firmware DOCSIS 2.0 Capable

Downstream Channel Cable Downstream 1/0
Upstream Channel Cable Upstream Logical Channel - 1/1/0

RF Levels
Receive Level (dB) 2.5
Transmit Level (dB) 40.5
Downstream Signal/Noise Ratio (dB) 36.5
Upstream Signal/Noise Ratio (dB) 29.5

Codewords Sent by Modem (counters are all independent of each other)
Without Error 1447935
With Correctable Errors 199
With Uncorrectable Errors 7

From these numbers, anyone see a challenge here that would cause these slow speeds?

Log in or register to post comments