Cable Modem - Policed or Shaped? - Time Warner Internet Services

Author	All Replies
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!
	to forum · permalink · 2012-11-17 12:44:07 ·
Fleeced join:2012-10-06 kudos:2	- Misread the post.
	to forum · permalink · 2012-11-17 14:10:13 ·
mackey join:2007-08-20 kudos:3	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
	to forum · permalink · 2012-11-17 22:26:30 ·
DrDrew So that others may surf. join:2009-01-28 SoCal kudos:8	That's Windows not the modem or CMTS causing the high latency
	to forum · permalink · 2012-11-17 23:34:39 ·
mackey join:2007-08-20 kudos:3	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
	to forum · permalink · 2012-11-17 23:36:47 ·
mackey join:2007-08-20 kudos:3 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
	to forum · permalink · 2012-11-17 23:45:59 ·
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.
	to forum · permalink · 2012-11-18 00:18:05 ·
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
	to forum · permalink · 2012-11-19 12:17:36 ·

Smith6612 Premium,MVM join:2008-02-01 North Tonawanda, NY kudos:22 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.
	to forum · permalink · 2012-11-19 13:46:17 ·
mackey join:2007-08-20 kudos:3	reply to piper said by piper: Running linux also Is that with the up and/or downstream completely saturated? /M
	to forum · permalink · 2012-11-19 14:52:56 ·
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?
	to forum · permalink · 2012-11-25 12:43:22 ·
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.
	to forum · permalink · 2012-11-26 01:00:03 ·
mackey join:2007-08-20 kudos:3	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
	to forum · permalink · 2012-11-26 01:26:44 ·
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.
	to forum · permalink · 2012-11-26 02:22:37 ·
Bigman397 join:2012-11-25 Lincoln, NE	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.
	to forum · permalink · 2012-11-26 07:13:19 ·
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.
	to forum · permalink · 2012-11-26 19:15:56 ·
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.
	to forum · permalink · 2012-11-27 19:32:28 ·

US Cable Support > Time Warner Internet Services > Cable Modem - Policed or Shaped?

Cable Modem - Policed or Shaped?