unacceptable rtt (ping) between CM CMTS | docsis.org

You are here

unacceptable rtt (ping) between CM <->CMTS

4 posts / 0 new
Last post
unacceptable rtt (ping) between CM <->CMTS

Hi all,
We have 2x arris 1500 running on 3,2MHz QPSK upstreams. Theoretically there is 5Mbps of bandwidth available per upstream. But when US utilization is at 50% rtt is about 20 ms. When it reaches 70% it is almost unusable - 50-60ms. On average there is 70-80 modems connected per US.

Is there any way of using 70-80 % of US bandwidth and not making delays so big?

We tried setting min reserved rate, but arris CMTS stops registering modems after (number of logged in modems) *(min reserved rate) >= Us bandwidth. DOCSIS standard says it MAY do it(= this function is not required for device to be DOCSIS 1.1 compatible).

US utilisation [%] RTT[ms]
0-30 10
50 20
70 60

Our CM config:
NetworkAccess 1;
GlobalPrivacyEnable 0;
DownstreamFrequency 410000000;
UpstreamChannelId 4;

UsServiceFlowRef 1;
QosParamSetType 7;
TrafficPriority 3;
MaxRateSustained 300000;
SchedulingType 2;
DsServiceFlowRef 2;
QosParamSetType 7;
TrafficPriority 3;
MaxRateSustained 1024000;

MaxCPE 1;

Any ideas anyone?


A few ideas on what is going

A few ideas on what is going on, and how to possibly remedy it. My guess is your utilization is high and your bandwidth usage is relatively low.

First off Upstream utilization is not a measurement of bandwidth being consumed, but rather a measure of time slots being used.

For upstream communication a cable modem requests a time slot from the cmts during which time it can transmit data on the return path. Then during its appointed time the cable modem transmits data and the cmts processes and likely forwards it to the internet. What is likely happening in your situation is there a few customers with a virus, or really aggressive P2P software that are requesting and using most of your available timeslots. The reason your ping times are going up is when it is trying to respond to the ping packet it has to wait for an available time slot thus extending the response time. You also need to look at available minislots (aka timeslots) on the cmts on the upstream affected. Chances are it is quite low <15% and this is causing your problem. Some cmtses have a customizable timeslot size, though it is usually tied to channel width.

When a customer has a virus, generally that computer wil try and infect as many hosts as possible, it will keep trying to contact other vulnerable hosts and spreading. Generally viruses first try and infect the subnet they are on and will attack closer computers, This generates a lot of requests which turn into a lot of minislot requests and high upstream utilization.

If this is indeed your problem then the only way to fix it is to identify the culprit with a cisco cmts we use "show ip cache flow", generally it is readily apparent who the culprit is his ip address is showing up on nearly every page usually multiple times a page. If we identify someone we think may be having the problem we use the command "show ip cache flow | include x.x.x.x" to look at just their traffic. Infected customers generally have one of two signatures 1) there are a lot of connections to ips on the same or similar subnet quite possibly sequential usually viruses, and 2) A lot of connections to a lot of dissimilar ips on the same or similar port, usually this is indicitive of P2P.

Depending on the type of problem you are experiencing the remedy will be different. If it is a virus customer, simply disabling the customer and contacting them to resolve the problem will fix the problem, for troublesome ports such as 135-139 or 445 you may want to block access to these ports in an access list. For P2P customers it is a little tricky, generally most P2P progs will have less aggressive settings i.e. only allow it to connect to set # of hosts or only use so much bandwidth. And usually a little customer education goes a long way.

Thanks for fast and accurate
Thanks for fast and accurate answer. You are right with upstream utilization and upstream bandwidth. I calculated usage with MRTG and included only bandwidth usage. Virus ports(139, 445 etc) are all blocked on CM. only p2p and zombie computers might be the problem. I have doubled minimum-map-size and maximum-map-size on the CMTS. Current US config: [code] Parameter Value --------- ----- admin-status up frequency 36000000 hertz width 3200000 hertz power 10 tenths-of-dBmV input-power-window 60 tenths-of-dB modulation-profile 1 (number) slot-size 4 (6.25 uSec ticks) start-ranging-backoff 2 (2 to this power, 16=>special) end-ranging-backoff 5 (2 to this power, 16=>special) start-tx-backoff 3 (2 to this power, 16=>special) end-tx-backoff 10 (2 to this power, 16=>special) minimum-map-size 64 slots maximum-map-size 4096 slots contention-per-map 32 mini-slots request-data-allowed disallowed max-data-in-contention 80 mini-slots initial-ranging-interval 2000 microseconds high-priority-threshold 75 (number) guaranteed-threshold 100 percent link-trap enabled alias "" max-cbr-flows -1 flows (-1 = no limit) [/code] Any ideas for further adjustments? John
PSE Strata System Engineer at

PSE Strata System Engineer at Palo Alto Networks provides actual exam questions and an online practice test engine for Palo Alto Networks System Engineer - Strata. For a limited time, you can try free Palo Alto Pse Strata Professional - Strata test questions. Palo Alto Networks System Engineer - Strata test PDF can also be downloaded for free. If you appreciate our product, you can request complete access to all Palo Al updates.

Log in or register to post comments