dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
1242
share rss forum feed


CuriousRR

@rr.com

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!


Fleeced

join:2012-10-06
kudos:2

- Misread the post.



mackey
Premium
join:2007-08-20
kudos:12
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...

/M



DrDrew
That others may surf
Premium
join:2009-01-28
SoCal
kudos:15

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



mackey
Premium
join:2007-08-20
kudos:12

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.

/M



mackey
Premium
join:2007-08-20
kudos:12

1 edit

traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  192.168.10.254  0.210 ms  0.194 ms  0.211 ms
 2  76.171.148.1  2530.273 ms  2531.183 ms  2531.279 ms
 3  76.166.17.137  1302.816 ms  1303.765 ms  1303.945 ms
 4  72.129.13.16  1311.977 ms  1311.981 ms  1311.951 ms
...
 

ping -c 50 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_req=1 ttl=44 time=745 ms
64 bytes from 8.8.8.8: icmp_req=2 ttl=44 time=906 ms
64 bytes from 8.8.8.8: icmp_req=3 ttl=44 time=971 ms
64 bytes from 8.8.8.8: icmp_req=4 ttl=44 time=1246 ms
64 bytes from 8.8.8.8: icmp_req=5 ttl=44 time=1239 ms
64 bytes from 8.8.8.8: icmp_req=6 ttl=44 time=1433 ms
64 bytes from 8.8.8.8: icmp_req=7 ttl=44 time=1528 ms
64 bytes from 8.8.8.8: icmp_req=8 ttl=44 time=1752 ms
64 bytes from 8.8.8.8: icmp_req=9 ttl=44 time=1877 ms
64 bytes from 8.8.8.8: icmp_req=10 ttl=44 time=1999 ms
...
64 bytes from 8.8.8.8: icmp_req=49 ttl=44 time=1805 ms
64 bytes from 8.8.8.8: icmp_req=50 ttl=44 time=1838 ms
 
--- 8.8.8.8 ping statistics ---
50 packets transmitted, 47 received, 6% packet loss, time 49023ms
rtt min/avg/max/mdev = 745.325/1692.587/2041.660/287.046 ms, pipe 3
 

/M


CuriousRR

@rr.com
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.



piper
Premium
join:2001-04-19
Buffalo, NY
reply to mackey

Running linux also


piper@x1:~$ traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
1 192.168.11.1 0.407 ms 0.335 ms 0.301 ms
2 69.207.26.1 21.681 ms 21.980 ms 22.068 ms
3 98.0.0.193 16.799 ms 17.194 ms 17.170 ms
4 98.0.3.10 16.113 ms 16.099 ms 16.070 ms
5 98.0.3.3 35.918 ms 35.823 ms 35.828 ms
6 24.24.21.213 25.268 ms 25.543 ms 25.536 ms
7 24.24.21.215 34.130 ms 24.24.21.208 38.498 ms 39.657 ms
8 66.109.6.74 38.359 ms 38.142 ms 35.571 ms
9 107.14.17.172 44.448 ms 66.109.6.26 37.187 ms 107.14.17.172 43.728 ms
10 66.109.6.28 46.383 ms 66.109.9.30 44.193 ms 66.109.6.28 48.431 ms
11 66.109.6.165 42.325 ms 40.426 ms 107.14.19.135 38.444 ms
12 66.109.9.66 120.290 ms 74.125.49.181 119.031 ms 115.270 ms
13 209.85.252.80 41.513 ms 41.519 ms 209.85.252.46 41.722 ms
14 72.14.236.146 40.321 ms 72.14.236.148 42.793 ms 72.14.236.146 40.934 ms
15 72.14.238.70 42.771 ms 72.14.238.18 39.784 ms 72.14.238.16 39.719 ms
16 72.14.232.21 46.604 ms 216.239.49.149 41.847 ms 216.239.49.145 46.228 ms
17 8.8.8.8 38.493 ms 33.606 ms 39.068 ms


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

--- 8.8.8.8 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



Smith6612
Premium,MVM
join:2008-02-01
North Tonawanda, NY
kudos:24
Reviews:
·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.



mackey
Premium
join:2007-08-20
kudos:12
reply to piper

said by piper:

Running linux also

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

/M


CuriousRR

@rr.com
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?


Razoul

join:2012-10-09
Crestline, CA
Reviews:
·Charter
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.



mackey
Premium
join:2007-08-20
kudos:12

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.

/M


Razoul

join:2012-10-09
Crestline, CA

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


Bigman397

join:2012-11-25
Lincoln, NE

1 recommendation

reply to CuriousRR

Here is a rather simple overview to how it is configured:
»www.cmtsinfo.net/index.php?howto=cm_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.



RRCurious

@rr.com

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.


Bigman397

join:2012-11-25
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.