Our D3.0 wideband modems exhibit what I think is odd behavior. As the connection's provisioned upload QOS starts to exceed around 60-70% the download speed begins to suffer heavily. DS bandwidth deteriorates increasingly to the point when the the upload bandwidth is near or at max QOS. At max upload QOS the connection is pratically unuseable, not just slow. Our D2.0 modems, e.g. SB510X's don't exhibit this behavior. I've successfully maxed a D2.0 modem's US and DS qos for a sustained period of time without diminished bandwidth in either direction.
We are configured for four contigous downstream frequencies and two upstream freqs. Our CMTS is a UBR-10k
Is this typical behavior of a D3.0 connection?
Any insight or config suggestions? I can provide scrubbed .cm and cmts config information if necessary.
No, that is not typical.
I think the best bet will be to post some cmts config, eg "show run int cable 5/0/0", plus your 5/0/0 integrated-cable/modular-cable and wideband-cable config
Also might be useful to show your cm config plus advise the brand/model/firmware of the D3 cm.
Are you doing 2 x channel upstream bonding, or just 1 channel ?
Have you done any graphing of the CMTS US and DS utilisation ?
What speeds are you selling DS and US ?
We are running 4x2 bonding for the majority of the system, with 2 nodes sharing a MAC domain with the associated transmit post. The CMTS is running 12.2 SCC5 IOS on PRE2, using MC20x20V line cards.
Typical DOCSIS 3.0 modem is the Arris CM820 with 7.3.139 firmware
Select pieces of the "show run" for the system, detailing the local node we use for testing:
cable upstream rate-adapt local
controller Integrated-Cable 6/0/4
rf-channel 0 cable downstream channel-id 65
rf-channel 0 frequency 597000000 annex B modulation 256qam interleave 32
rf-channel 0 rf-power 45.0
no rf-channel 0 rf-shutdown
rf-channel 1 cable downstream channel-id 66
rf-channel 1 frequency 603000000 annex B modulation 256qam interleave 32
rf-channel 1 rf-power 45.0
no rf-channel 1 rf-shutdown
rf-channel 2 cable downstream channel-id 67
rf-channel 2 frequency 609000000 annex B modulation 256qam interleave 32
rf-channel 2 rf-power 45.0
no rf-channel 2 rf-shutdown
rf-channel 3 cable downstream channel-id 68
rf-channel 3 frequency 615000000 annex B modulation 256qam interleave 32
rf-channel 3 rf-power 45.0
no rf-channel 3 rf-shutdown
interface Cable6/0/4
downstream Integrated-Cable 6/0/4 rf-channel 0-3
cable mtc-mode
cable enable-trap cmonoff-notification
cable enable-trap cmonoff-interval 60
no cable packet-cache
cable default-phy-burst 0
cable map-advance dynamic 300 1000
cable bundle 1
cable upstream max-ports 4
cable upstream bonding-group 604
upstream 0
upstream 1
attributes A0000000
cable upstream bonding-group 624
upstream 2
upstream 3
attributes A0000000
cable upstream 0 connector 16 shared
cable upstream 0 frequency 22000000
cable upstream 0 channel-width 6400000 6400000
cable upstream 0 power-level 3
cable upstream 0 load-balance group 78
cable upstream 0 docsis-mode atdma
cable upstream 0 minislot-size 2
cable upstream 0 range-backoff 3 6
cable upstream 0 modulation-profile 221
no cable upstream 0 rate-limit
cable upstream 0 rate-adapt
cable upstream 0 attribute-mask 20000000
no cable upstream 0 shutdown
cable upstream 1 connector 16 shared
cable upstream 1 frequency 30000000
cable upstream 1 channel-width 6400000 6400000
cable upstream 1 power-level 3
cable upstream 1 load-balance group 78
cable upstream 1 docsis-mode atdma
cable upstream 1 minislot-size 2
cable upstream 1 range-backoff 3 6
cable upstream 1 modulation-profile 221
no cable upstream 1 rate-limit
cable upstream 1 rate-adapt
cable upstream 1 attribute-mask 20000000
no cable upstream 1 shutdown
interface Wideband-Cable6/0/4:0
load-interval 30
cable bundle 1
cable bonding-group-id 705
cable dynamic-bw-sharing
cable rf-channel 0 bandwidth-percent 71
cable rf-channel 1 bandwidth-percent 71
cable rf-channel 2 bandwidth-percent 71
cable rf-channel 3 bandwidth-percent 71
!
interface Integrated-Cable6/0/4:0
cable bundle 1
cable dynamic-bw-sharing
cable rf-bandwidth-percent 25
!
interface Integrated-Cable6/0/4:1
cable bundle 1
cable dynamic-bw-sharing
cable rf-bandwidth-percent 25
!
interface Integrated-Cable6/0/4:2
cable bundle 1
cable dynamic-bw-sharing
cable rf-bandwidth-percent 25
!
interface Integrated-Cable6/0/4:3
cable bundle 1
cable dynamic-bw-sharing
cable rf-bandwidth-percent 25
cable fiber-node 100
description Zero Node
downstream Integrated-Cable 6/0/4 rf-channel 0-3
upstream Cable 6/0 connector 16
===========
The "dotCM" file items, sold as 20/3 speed (snmp security items stripped)
03 (Net Access Control) = Yes
05 (Modem Capability)
S01 (Concatenation Support) = 1
S03 (Fragmentation Support) = 1
S04 (Payload Header Suppression Support) = 1
S06 (Privacy Support) = 1
18 (Maximum Number of CPE) = 1
24 (Upstream Service Flow Block)
S01 (Flow Reference) = 1
S06 (QoS Parameter Set Type) = 7
S07 (Traffic Priority) = 0
S08 (Max Substained Traffic Rate) = 3100000
S09 (Max Traffic Burst) = 50000
S13 (Timeout for Admitted QoS Parameters) = 0
S14 (Max Concatenated Burst) = 8192
S15 (Service Flow Scheduling Type) = 2
25 (Downstream Service Flow Block)
S01 (Flow Reference) = 2
S06 (QoS Parameter Set Type) = 7
S08 (Max Substained Traffic Rate) = 20300000
S09 (Max Traffic Burst) = 75000
S13 (Timeout for Admitted QoS Parameters) = 0
OK, well I have a very similar system, except I am running PRE4 rather than PRE2. I have some of those CM820 on my network as well. I dont have any problems with upload or download speed, selling variations up to 100/8 with 4 and 8 DS bonding groups, some nodes have 1 and some have 2 US bonding.
When I compare my configs to yours I see a small number of differences. Heres is what you would change to bring it in line with mine :
In your cm config file, alter these settings :
change upstream Max Traffic Burst from 50000 to 10000
change upstream Max Concatenated Burst from 8192 to 10000
Also these (although I dont think they will the source of your problems) :
change downstream Max Traffic Burst from 75000 to something larger (I use 4096000)
add downstream Peak Rate as 0
And here are the differences for the CMTS :
int cable 6/0/4
cable upstream 0 ingress-noise-cancellation 10
default cable upstream 0 rate-limit
no cable upstream 0 rate-adapt
cable upstream 0 equalization-coefficient
cable upstream 1 ingress-noise-cancellation 10
default cable upstream 1 rate-limit
no cable upstream 1 rate-adapt
cable upstream 1 equalization-coefficient
In particular I would not recommend using the rate-adapt stuff.
Oh and also you might want to try upgrading your IOS, SCC5 is pretty old. We've worked our way through SCC SCD SCE and now onto SCF as we get Cisco to fix bug after bug. I would think SCF4 or SCE6 would be a better choice than very old SCC5.
Hope that helps!
We made the changes recommended by mbowe and they seem to have solved the wideband bandwidth performace. In particular the following changes to the CMTS appear to have been the key (presently still on SCC5):
qoute: mbowe
And here are the differences for the CMTS :
int cable 6/0/4
cable upstream 0 ingress-noise-cancellation 10
default cable upstream 0 rate-limit
no cable upstream 0 rate-adapt
cable upstream 0 equalization-coefficient
cable upstream 1 ingress-noise-cancellation 10
default cable upstream 1 rate-limit
no cable upstream 1 rate-adapt
cable upstream 1 equalization-coefficient
:end quote
Though we haven't yet done a line-by-line config change to see which change, if one, was the silver bullet.
I would like to thank you very much for your quick, helpful response regarding our issue. This forum is a wonderful resource.
Excellent news!
Yeah the performance related ones are the rate-adapt and the rate-limit ones. So it's likely one of those caused your problems.
The other 2 are more to help with handling noise. I would recommend using these, they make a big difference. The only gotcha being we saw some problems with equalization-coefficient and some really old Motorola modem firmware. But soon as we updated those firmwares to anything semi recent the problems went away.
I'd seen speed increases and stability with those enabled on the 7246VXR this beast replaced, so I carried them over on the initial stand up for the 10K. I never suspected the dual-direction impairment until it was brought to my attention.
As far as Motorola firmware is concerned, every modem on here is either on their end-of-life final release (like the SB5100s on 2.3.9.0), or one step behind the current release in the case of the 5101s. The DOCSIS 3.0 modems go with current KOMODO (now 1.0.6.8), but only after a few test subjects burn on it for a month.
Thanks for the assist!
Holy crap, update your modem firmware! The latest for the arris820 is 7.5.63 and there are an enormous amounts of fixes inbetween.
(and for 822/804/860/862's as well) Keep that modem firmware up to date!
I'd like to thank my coworker for posting those configs and the forum member's responses in this thread. I hope to have some test results early this week.
Yeah, my slip-up, I was in a hurry and grabbed the wrong "latest" from the TFTP server.
Have to get in a different mindset for the Arris eMTAs and their firmware, since our VoIP provider was acquired by a larger company. Before acquisition, we were told not to use anything but their "approved" version, which put us miles off the upgrade train. Now, it's "Eh, throw what you want at them".