Micheal64
join:2002-03-05
Oklahoma City, OK | reply to Micheal64
Re: Latency in Oklahoma City
My report from off net.
»/quality/nil/697135 |
|
Micheal64
join:2002-03-05
Oklahoma City, OK
| reply to Micheal64
As I write this, I'm seeing 165ms - 250ms to the gateway (68.12.64.1) and my sons Diablo just dropped him. I checked the signal info in the modem and this is it:
Configuration
Manager
This page provides information about the current
upstream and downstream signal status of your Cable Modem.
Downstream
Value
Frequency
579000000 Hz Locked
Signal to Noise Ratio
36 dB
QAM
64
Network Access Control Object
ON
Power Level
7 dBmV
The Downstream Power Level reading is a
snapshot taken at the time this page was requested. Please
Reload/Refresh this Page for a new reading
Upstream
Value
Channel ID
1
Frequency
25008000 Hz Ranged
Ranging Service ID
873
Symbol Rate
1.280 Msym/s
Power Level
50 dBmV IMG
--
Rich Cook: Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning. |
|
Micheal64
join:2002-03-05
Oklahoma City, OK
| reply to Micheal64
Papa Smurf, I don't know if you work for Cox or not, but on the off chance that you do, allow me to provide you with a bit more information.
I first reported this problem in November 2001. It wasn't nearly as often as it is now.
There have been 4 truck rolls to my residence to check line signal and such. All techs on site coordinated with the SOC here in Okc and determined that the line signal was clean and within tolerance for a HSD connection.
I live in a multi-dwelling unit with a 26 value tap. I have one internal splitter. All connections and cable have been checked and rechecked by each tech that has been on site.
The modem has been replaced once already. The account has been reprovisioned numerous times. I called again to day and the techs were seeing 25% loss when they tried to ping the ip of my gateway (68.12.64.1). The issue was supposedly handed off to Jacob (Supervisor here in Okc that I used to work for when I worked there). I don't know what else to do short of walking to the 10th street location and personally request to speak to the HSD rep at the SOC to have them actually telnet into the router and pull stats from the interface itself. I can't do much of anything else from here except grip and complain and honestly, I don't like having to do that since I know what the other end is like.
There are currently 3 Remedy tickets for this issue. The third opened yesterday. |
|
Micheal64
join:2002-03-05
Oklahoma City, OK
|  reply to 2kmaro
No problem Red.
As for my individual problem, I'm getting latency to the gateway itself. I've got a gateway IP of 68.12.64.1 and I believe that it's the same system as 10.0.0.1 as well as the last hop next to my end on this report.
»/quality/nil/696989
This particular report doesn't show it's all that bad. Of course, it was actually running fairly smooth at the time of this report but that's how it goes. I'm routinely seeing 200ms - 3000ms at times when trying to do anything that even remotely uses my upstream. I admit, I'm an online gamer and I have a 100mb lan. I've been told by some techs at Cox that the problem is that the latency is due to traffic. Yea, that would definitely cause the problem all right. With the exception that when I'm getting this latency, I shut down the 2 windows boxes and leave only the freebsd router online. The latency lasts for about 30 - 45 seconds and subsides. It's making any type of gaming pretty much useless. Can't access usenet either. With the current prediciment that the nntp servers are in and in combination with what I'm getting, I can pretty much only check email and some light surfing when it's happening.
Another thing that I've noticed is an awful log of DHCP broadcast traffic from 10.0.0.1 to 255.255.255.255:68. I'm used to seeing dhcp traffic, but I didn't think it was permitted to pass beyond the 10.x.x.x network into the public IP space of the remote system. That may be something else entirely or it may be part of the problem. When these broadcasts occur, I'm showing anywhere from 20 packets to 200 packets hitting my router at one time. Since they're UDP, the remote doesn't care if it gets a response or not so I'm wondering if there may be some sort of udp storm on the network. I can't tell from here.
At any rate, I've enabled traffic shaping and effectively locked my outside interface to the modem down to 56k just to see if I may be overloading the upstream. No luck. I still get upwards of 3000ms on icmp traffic to the router when the latency is spiking.
I'm at a loss and I'm really having problems getting it resolved. I've had 3 open Remedy (ARS) tickets opened since November 2001. The third one was opened yesterday. The previous 2 were closed out automatically due to time out with no comments and apparently no assignment of the ticket. Even after it was requested that the issue be escalated. I'm starting to get really tired of this. I used to work for Cox and I can sympathize with what their going through, but damn, someone has to fess up and fix the issues that we have or the customers are going to go with someone else. DSL is available in much of the Okc metro area anymore and it's starting to look a lot more pleasing as time goes on.
Here's a snippet of what I'm getting. Report from Dec 2001 just for histories sake. I have times all the way back to December 2001 and they run 10 packets every 5 minutes and are logged:
Wed Dec 12 00:20:00 CST 2001
PING 10.68.64.1 (10.68.64.1): 56 data bytes
64 bytes from 10.68.64.1: icmp_seq=0 ttl=255 time=87.274 ms
64 bytes from 10.68.64.1: icmp_seq=1 ttl=255 time=18.828 ms
64 bytes from 10.68.64.1: icmp_seq=2 ttl=255 time=195.193 ms
64 bytes from 10.68.64.1: icmp_seq=3 ttl=255 time=129.099 ms
64 bytes from 10.68.64.1: icmp_seq=4 ttl=255 time=128.811 ms
64 bytes from 10.68.64.1: icmp_seq=5 ttl=255 time=122.908 ms
64 bytes from 10.68.64.1: icmp_seq=6 ttl=255 time=118.781 ms
64 bytes from 10.68.64.1: icmp_seq=7 ttl=255 time=12.639 ms
64 bytes from 10.68.64.1: icmp_seq=8 ttl=255 time=239.577 ms
64 bytes from 10.68.64.1: icmp_seq=9 ttl=255 time=166.865 ms
--- 10.68.64.1 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 12.639/121.998/239.577/67.166 ms
Wed Dec 12 13:50:00 CST 2001
PING 10.68.64.1 (10.68.64.1): 56 data bytes
64 bytes from 10.68.64.1: icmp_seq=0 ttl=255 time=306.519 ms
64 bytes from 10.68.64.1: icmp_seq=1 ttl=255 time=280.821 ms
64 bytes from 10.68.64.1: icmp_seq=2 ttl=255 time=258.857 ms
64 bytes from 10.68.64.1: icmp_seq=3 ttl=255 time=129.234 ms
64 bytes from 10.68.64.1: icmp_seq=4 ttl=255 time=281.859 ms
64 bytes from 10.68.64.1: icmp_seq=5 ttl=255 time=248.998 ms
64 bytes from 10.68.64.1: icmp_seq=6 ttl=255 time=161.447 ms
64 bytes from 10.68.64.1: icmp_seq=7 ttl=255 time=16.557 ms
64 bytes from 10.68.64.1: icmp_seq=8 ttl=255 time=269.254 ms
64 bytes from 10.68.64.1: icmp_seq=9 ttl=255 time=213.454 ms
--- 10.68.64.1 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 16.557/216.700/306.519/85.310 ms
-------------------------
Now for today. These packets are using 1492 to even out to 1500 (my MTU on the FreBSD outside interface). I should have no major latency with this packet size if I'm getting 256kbps upstream. Unless my math is sourly incorrect.
--------------
Mon Mar 11 11:50:00 CST 2002
PING 68.12.64.1 (68.12.64.1): 1500 data bytes
1508 bytes from 68.12.64.1: icmp_seq=0 ttl=255 time=82.947 ms
1508 bytes from 68.12.64.1: icmp_seq=1 ttl=255 time=74.736 ms
1508 bytes from 68.12.64.1: icmp_seq=2 ttl=255 time=52.617 ms
1508 bytes from 68.12.64.1: icmp_seq=3 ttl=255 time=135.840 ms
1508 bytes from 68.12.64.1: icmp_seq=4 ttl=255 time=53.162 ms
1508 bytes from 68.12.64.1: icmp_seq=5 ttl=255 time=27.844 ms
1508 bytes from 68.12.64.1: icmp_seq=6 ttl=255 time=26.373 ms
1508 bytes from 68.12.64.1: icmp_seq=7 ttl=255 time=78.630 ms
1508 bytes from 68.12.64.1: icmp_seq=8 ttl=255 time=82.772 ms
1508 bytes from 68.12.64.1: icmp_seq=9 ttl=255 time=163.991 ms
--- 68.12.64.1 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 26.373/77.891/163.991/41.521 ms
Mon Mar 11 11:55:00 CST 2002
PING 68.12.64.1 (68.12.64.1): 1500 data bytes
1508 bytes from 68.12.64.1: icmp_seq=0 ttl=255 time=281.187 ms
1508 bytes from 68.12.64.1: icmp_seq=1 ttl=255 time=106.741 ms
1508 bytes from 68.12.64.1: icmp_seq=2 ttl=255 time=153.134 ms
1508 bytes from 68.12.64.1: icmp_seq=3 ttl=255 time=178.217 ms
1508 bytes from 68.12.64.1: icmp_seq=4 ttl=255 time=101.450 ms
1508 bytes from 68.12.64.1: icmp_seq=5 ttl=255 time=79.863 ms
1508 bytes from 68.12.64.1: icmp_seq=6 ttl=255 time=49.058 ms
1508 bytes from 68.12.64.1: icmp_seq=7 ttl=255 time=303.891 ms
1508 bytes from 68.12.64.1: icmp_seq=8 ttl=255 time=384.743 ms
1508 bytes from 68.12.64.1: icmp_seq=9 ttl=255 time=150.960 ms
Mon Mar 11 12:00:00 CST 2002
PING 68.12.64.1 (68.12.64.1): 1500 data bytes
1508 bytes from 68.12.64.1: icmp_seq=0 ttl=255 time=38.357 ms
1508 bytes from 68.12.64.1: icmp_seq=1 ttl=255 time=100.426 ms
1508 bytes from 68.12.64.1: icmp_seq=2 ttl=255 time=89.179 ms
1508 bytes from 68.12.64.1: icmp_seq=3 ttl=255 time=151.775 ms
1508 bytes from 68.12.64.1: icmp_seq=4 ttl=255 time=38.036 ms
1508 bytes from 68.12.64.1: icmp_seq=5 ttl=255 time=126.372 ms
1508 bytes from 68.12.64.1: icmp_seq=6 ttl=255 time=65.474 ms
1508 bytes from 68.12.64.1: icmp_seq=7 ttl=255 time=95.435 ms
1508 bytes from 68.12.64.1: icmp_seq=8 ttl=255 time=96.246 ms
1508 bytes from 68.12.64.1: icmp_seq=9 ttl=255 time=43.910 ms
--- 68.12.64.1 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 38.036/84.521/151.775/36.208 ms
Mon Mar 11 12:05:01 CST 2002
PING 68.12.64.1 (68.12.64.1): 1500 data bytes
1508 bytes from 68.12.64.1: icmp_seq=0 ttl=255 time=632.239 ms
1508 bytes from 68.12.64.1: icmp_seq=1 ttl=255 time=510.352 ms
1508 bytes from 68.12.64.1: icmp_seq=2 ttl=255 time=424.583 ms
1508 bytes from 68.12.64.1: icmp_seq=3 ttl=255 time=572.465 ms
1508 bytes from 68.12.64.1: icmp_seq=4 ttl=255 time=187.285 ms
1508 bytes from 68.12.64.1: icmp_seq=5 ttl=255 time=113.856 ms
1508 bytes from 68.12.64.1: icmp_seq=6 ttl=255 time=167.287 ms
1508 bytes from 68.12.64.1: icmp_seq=7 ttl=255 time=424.446 ms
1508 bytes from 68.12.64.1: icmp_seq=8 ttl=255 time=106.631 ms
1508 bytes from 68.12.64.1: icmp_seq=9 ttl=255 time=72.402 ms
--- 68.12.64.1 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 72.402/321.155/632.239/202.376 ms
Mon Mar 11 12:10:00 CST 2002
PING 68.12.64.1 (68.12.64.1): 1500 data bytes
1508 bytes from 68.12.64.1: icmp_seq=0 ttl=255 time=25.391 ms
1508 bytes from 68.12.64.1: icmp_seq=1 ttl=255 time=73.067 ms
1508 bytes from 68.12.64.1: icmp_seq=2 ttl=255 time=104.173 ms
1508 bytes from 68.12.64.1: icmp_seq=3 ttl=255 time=192.162 ms
1508 bytes from 68.12.64.1: icmp_seq=4 ttl=255 time=185.025 ms
1508 bytes from 68.12.64.1: icmp_seq=5 ttl=255 time=190.536 ms
1508 bytes from 68.12.64.1: icmp_seq=6 ttl=255 time=145.384 ms
1508 bytes from 68.12.64.1: icmp_seq=7 ttl=255 time=132.440 ms
1508 bytes from 68.12.64.1: icmp_seq=8 ttl=255 time=49.121 ms
1508 bytes from 68.12.64.1: icmp_seq=9 ttl=255 time=83.721 ms
--- 68.12.64.1 ping statistics ---
10 packets transmitted, 10 packets received, 0% packet loss
round-trip min/avg/max/stddev = 25.391/118.102/192.162/57.374 ms
Granted, ICMP isn't the most efficient way to diagnose latency since it's a lower priority protocol, but it does coincide with my in game latency. I also believe that it's on my way TO the router that the latency is occuring. Someone please correct me if I'm wrong, but as I recall, the HL engine (as do most of the other first person shooters out there) use UDP traffic for their preffered protocol. I'm unable to send update packets to the remote server although I AM able to receive inbound data from the remote server with little to no indication of loss. I stop moving, others move around me, I see the shots fired at me, I get the indication of getting hit. 30 seconds later, I'm dead. That's one of the reason's that I wanted cable or DSL to begin with. I like to play games as do my children. At the present, we're pretty muc stuck on web suring (when it's not also effected) and email. I just want the problem fixed. I don't really care if they ackowledge the problem or not and I'm starting to get real weary of this fight. |
|
2kmaro
Think
Premium,ExMod 1 BC
join:2000-07-11
ColossalCave
clubs:  
| reply to PapaSmurf
OK - these are from Saturday the 8th - cut them from that other thread. That was a particularly nasty day. Situation went on for quite some time, then suddenly went away (like everyone went out to supper or something  ) --
To www.dslreports.com (www.broadbandreports.com)
1 1 ms 1 ms 1 ms 192.168.0.1
2 10 ms 9 ms 11 ms 10.1.16.1
3 * 163 ms * 68.12.8.129
4 * * * Request timed out.
5 140 ms 11 ms 10 ms 68.1.0.108
6 116 ms 69 ms 11 ms 68.1.0.102
7 * * 134 ms 68.1.0.107
8 * * * Request timed out.
9 * * * Request timed out.
10 * * * Request timed out.
11 * * * Request timed out.
12 * * * Request timed out.
13 * * * Request timed out.
14 * * * Request timed out.
15 * * * Request timed out.
16 * * * Request timed out.
17 * * * Request timed out.
18 * * * Request timed out.
19 * * * Request timed out.
20 * * * Request timed out.
21 * * * Request timed out.
22 230 ms 59 ms 61 ms broadbandreports.com [209.123.109.175]
Trace complete.
to Yahoo!
1 2 ms 1 ms 1 ms 192.168.0.1
2 21 ms 12 ms 79 ms 10.1.16.1
3 * 27 ms 63 ms 68.12.8.141
4 * 19 ms 15 ms 68.12.14.9
5 22 ms 13 ms 10 ms 68.1.0.104
6 * 17 ms 17 ms 68.1.0.107
7 19 ms 18 ms 35 ms gigabitethernet1-1.ipcolo1.Dallas1.Level3.net [2 09.246.152.233]
8 26 ms 28 ms 30 ms gigabitethernet10-1.core1.Dallas1.Level3.net [209.244.15.69]
9 18 ms 20 ms 21 ms so-4-0-0.mp2.Dallas1.Level3.net [209.247.10.105]
10 57 ms 59 ms 56 ms so-2-0-0.mp1.SanJose1.Level3.net [209.247.9.114]
11 60 ms 57 ms 62 ms gige9-2.ipcolo4.SanJose1.Level3.net [64.159.2.13 8]
12 65 ms 59 ms 101 ms cust-int.level3.net [64.152.69.18]
13 78 ms 75 ms 74 ms ge-1-2-0.msr2.pao.yahoo.com [216.115.100.154]
14 60 ms 62 ms 61 ms vlan28.bas1-m.snv.yahoo.com [216.115.100.122]
15 83 ms 59 ms 74 ms www.yahoo.akadns.net [216.115.102.78]
Trace complete.
--
I am not now, nor have I ever been, a member of the Comcast Party. |
|
PapaSmurf
A Smurfy Salute
VIP
join:2001-08-05
smurfville
| reply to 2kmaro
OKC only for this one. It helps simplify working the problem to have a separate thread I can reference to TOC and engineers. Additionally, since there's always work of sorts going on within the network, it helps to have current plots to work from. Thanks for the redirect, though, I'll add that to the issue log. |
|
2kmaro
Think
Premium,ExMod 1 BC
join:2000-07-11
ColossalCave
clubs:
| reply to PapaSmurf
There's a lot of that in this thread:
»What is Cox doing?
Or do you just want OKC only reports?
and I still want to know what was so boring about this thread?!
[text was edited by author 2002-03-11 18:25:57] |
|
PapaSmurf
A Smurfy Salute
VIP
join:2001-08-05
smurfville | reply to Micheal64
Dredster,
Thanks for starting this up. If you folks could post your ping plots, line qual tests or whatever here that would be a big help as well. Also gives us the specifics we'll need to reference. Thanks!! |
|
