Tell me more x
, there is a new speed test available. Give it a try, leave feedback!
dslreports logo
    All Forums Hot Topics Gallery


Search Topic:
share rss forum feed


Cable Modem - Policed or Shaped?

I was just curious if anyone knew what form of rate limiting TWC uses to cap cable modems. Trying to figure out if they drop or just delay excess traffic. Thanks!


- Misread the post.

reply to CuriousRR
Delay. You can watch your ping time creep up as you max your connection out. I regularly see >1 sec times but no/little loss when maxed...


That others may surf
That's Windows not the modem or CMTS causing the high latency

First off I run Linux not Windows, next how does a PC on a gigabit network go from a few ms latency to >1 sec latency when the local network link is no where near saturated?

Edit to add: the ping times to both the router and cable modem stay <1 ms while the first hop after the router jumps up.



1 edit


reply to CuriousRR
Thanks for the replies so far. I've been doing some studying on the token bucket algorithm along with QoS. I'm just curious to learn what TWC uses to keep traffic conformed at the modem. It seems no matter what's used there's a chance of dropping excess traffic.

Buffalo, NY
reply to mackey
Running linux also

piper@x1:~$ traceroute -n
traceroute to (, 30 hops max, 60 byte packets
1 0.407 ms 0.335 ms 0.301 ms
2 21.681 ms 21.980 ms 22.068 ms
3 16.799 ms 17.194 ms 17.170 ms
4 16.113 ms 16.099 ms 16.070 ms
5 35.918 ms 35.823 ms 35.828 ms
6 25.268 ms 25.543 ms 25.536 ms
7 34.130 ms 38.498 ms 39.657 ms
8 38.359 ms 38.142 ms 35.571 ms
9 44.448 ms 37.187 ms 43.728 ms
10 46.383 ms 44.193 ms 48.431 ms
11 42.325 ms 40.426 ms 38.444 ms
12 120.290 ms 119.031 ms 115.270 ms
13 41.513 ms 41.519 ms 41.722 ms
14 40.321 ms 42.793 ms 40.934 ms
15 42.771 ms 39.784 ms 39.719 ms
16 46.604 ms 41.847 ms 46.228 ms
17 38.493 ms 33.606 ms 39.068 ms

piper@x1:~$ ping -c 50
PING ( 56(84) bytes of data.
64 bytes from icmp_req=1 ttl=50 time=34.0 ms
64 bytes from icmp_req=2 ttl=50 time=34.2 ms
64 bytes from icmp_req=3 ttl=50 time=39.7 ms
64 bytes from icmp_req=4 ttl=50 time=35.0 ms
64 bytes from icmp_req=5 ttl=50 time=35.2 ms
64 bytes from icmp_req=6 ttl=50 time=36.3 ms
64 bytes from icmp_req=7 ttl=50 time=33.6 ms
64 bytes from icmp_req=8 ttl=50 time=34.1 ms
64 bytes from icmp_req=9 ttl=50 time=35.2 ms
64 bytes from icmp_req=10 ttl=50 time=34.4 ms
64 bytes from icmp_req=11 ttl=50 time=34.3 ms
64 bytes from icmp_req=12 ttl=50 time=34.3 ms
64 bytes from icmp_req=13 ttl=50 time=34.8 ms
64 bytes from icmp_req=14 ttl=50 time=34.3 ms
64 bytes from icmp_req=15 ttl=50 time=34.3 ms
64 bytes from icmp_req=16 ttl=50 time=34.7 ms
64 bytes from icmp_req=17 ttl=50 time=34.7 ms
64 bytes from icmp_req=18 ttl=50 time=38.6 ms
64 bytes from icmp_req=19 ttl=50 time=35.3 ms
64 bytes from icmp_req=20 ttl=50 time=35.2 ms
64 bytes from icmp_req=21 ttl=50 time=35.7 ms
64 bytes from icmp_req=22 ttl=50 time=35.3 ms
64 bytes from icmp_req=23 ttl=50 time=35.7 ms
64 bytes from icmp_req=24 ttl=50 time=35.5 ms
64 bytes from icmp_req=25 ttl=50 time=40.3 ms
64 bytes from icmp_req=26 ttl=50 time=35.6 ms
64 bytes from icmp_req=27 ttl=50 time=38.7 ms
64 bytes from icmp_req=28 ttl=50 time=36.1 ms
64 bytes from icmp_req=29 ttl=50 time=36.6 ms
64 bytes from icmp_req=30 ttl=50 time=36.0 ms
64 bytes from icmp_req=31 ttl=50 time=36.7 ms
64 bytes from icmp_req=32 ttl=50 time=36.8 ms
64 bytes from icmp_req=33 ttl=50 time=33.9 ms
64 bytes from icmp_req=34 ttl=50 time=35.0 ms
64 bytes from icmp_req=35 ttl=50 time=35.7 ms
64 bytes from icmp_req=36 ttl=50 time=35.8 ms
64 bytes from icmp_req=37 ttl=50 time=34.6 ms
64 bytes from icmp_req=38 ttl=50 time=34.1 ms
64 bytes from icmp_req=39 ttl=50 time=35.0 ms
64 bytes from icmp_req=40 ttl=50 time=35.4 ms
64 bytes from icmp_req=41 ttl=50 time=36.1 ms
64 bytes from icmp_req=42 ttl=50 time=39.3 ms
64 bytes from icmp_req=43 ttl=50 time=36.3 ms
64 bytes from icmp_req=44 ttl=50 time=36.3 ms
64 bytes from icmp_req=45 ttl=50 time=34.0 ms
64 bytes from icmp_req=46 ttl=50 time=42.8 ms
64 bytes from icmp_req=47 ttl=50 time=34.2 ms
64 bytes from icmp_req=48 ttl=50 time=35.1 ms
64 bytes from icmp_req=49 ttl=50 time=34.7 ms
64 bytes from icmp_req=50 ttl=50 time=34.6 ms

--- ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 49068ms
rtt min/avg/max/mdev = 33.696/35.733/42.882/1.821 ms

debian sid | apt-get into it
proudly anti-micro$oft using aptosid / siduction

North Tonawanda, NY
·Verizon Online DSL
·Frontier Communi..
reply to DrDrew
Where does the downstream latency come from when saturating the connection if it is from Windows? Only thing Windows can do is acknowledge what comes in. If it's the sender, then the delay is from the computer to the last router hosting the connection.

reply to piper
said by piper:

Running linux also

Is that with the up and/or downstream completely saturated?


reply to CuriousRR
Anyone else have any input on this? I'm still curious what parameters they use in terms of Tc, bucket size and burst size. If someone wanted to do QoS on there it would it make sense to match these on the shaper or policer no?


Crestline, CA
reply to mackey
@mackey : Is your connection maxed out? Unless you've got QoS going, packets are first come, first served out of the router to the modem and further out to the internet, which will definitely increase the latency as packets have to wait longer in the filled up queue with no settings on which packets have priority.

Um, isn't that the whole point of this thread? About what happens when your connection is maxed out? Of course the runs above were with it maxed out; what it does when not maxed is irrelevant to this discussion. Not all shapers fill a queue when no more bandwidth is available, some just drop the packets instead. The OP wanted to know which method TWC used.



Crestline, CA
My mistake, I've been up too long and forgot what the OP said when I started writing my reply.


Lincoln, NE

1 recommendation

reply to CuriousRR
Here is a rather simple overview to how it is configured:
» ··· m_config

In essence they set the maxsustainedrate in a docsis 1.1 level config section. They may or may not use bursting and bit bucket, however at its core your traffic is not so much shaped as a line rate is set.

They will tag normal traffic as 0 or 1 with specific settings for voice and other high priority items as they see fit. The cmts then handles any sort of priority issues further up the chain. They may even use dynamic flows for MTA voice traffic to place it in a seperate pipe from your normal data.

Wow that link you provided me is amazing. I don't think I would've been able to find it otherwise (not being sarcastic here). Going to read through it now as it matches what I'm looking for. So what's the difference between the bit bucket stuff and customizing the line rate via the config file?

If anyone else has any further information this that would be perfect. Anyone work for TWC out there? Thanks for the input so far everyone.


Lincoln, NE
bit bucket is something to control bursting, it is used in conjunction with your set line rate. The bit bucket is, if i remember correctly, a cmts side global setting. It essentially provides a pool of excess bandwidth for bursts above your planned rate that is shared by everyone on a given downstream interface.

I may be a bit wrong on that, been a while since i've had to tinker with it.