Micheal64
join:2002-03-05
Oklahoma City, OK
| Latency in Oklahoma City
I'm curious to know just how many other metro users are getting sporadic high latency at their gateway routers.
[text was edited by author 2002-03-11 16:44:53] |
|
cwren
join:2001-01-03
Oklahoma City, OK
| Yep. Usually starts on my second hop. It's always a 68.xxx.xxx.xxx address. Goes downhill from there. I sure wish we could get some answers from Cox. I tried calling tech support, but evidently they had a bunch of new hires with very little training. I ended up having to explain what I meant when I told her one of their routers was dropping packets. |
|
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!! |
|
2kmaro
Think
Premium,ExMod 1 BC
join:2000-07-11
ColossalCave
clubs:  
| 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
| 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:
| 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. |
|
Micheal64
join:2002-03-05
Oklahoma City, OK
|  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. |
|
meester
Premium
join:2000-06-03
Oklahoma City, OK
clubs:
| reply to Micheal64
a couple of TraceRT I just ran. 20 pings per hop....
I May be one of the few but I have the best connection I have had in 2 yr.Just hope it last.....
Your download speed : 2636737 bps, or 2636 kbps.
Browsers would show : about a 321.8 KB/sec transfer rate.
Your upload speed : 268456 bps, or 268 kbps.
Your connection rocks .. above the 1mbit barrier!
»/quality/nil/697122
--
Operates With Pride
[text was edited by author 2002-03-11 20:01:07] |
|
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
| 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 | My report from off net.
»/quality/nil/697135 |
|
catseyenu
Ack Pfft
Premium
join:2001-11-17
Fix East
| reply to Micheal64
And this is on a good day. That gateway has seemed to stay at a minimum of 10%.
I've been hanging tough and supporting Cox. God knows they have a tough row to hoe.
I am beginning to get a little nervous with their support lately. I've had them stand me up twice on house calls, not even a call to say they weren't going to be there. Wasted a whole day waiting for them last time. Finally used online support to report the OKC office. Sheesh, c'mon guys I understand things happen and schedules get off but is a courtesy call to let me know you're not going to make it to much to ask?
[text was edited by author 2002-03-12 03:39:53]
[text was edited by moderator] |
|
Zar
Premium
join:2001-08-04
Platte City, MO
| reply to Micheal64
Every time I go thru 68.12.8.53 I get packet loss all the time. When I go thru 68.12.8.61 everything looks fine..
After this text message I will post jpegs of PingPlotter and Visual Route
All done at around 4am March 12 2002
>ping -n 100 -l 128 68.
Pinging 68.12.8.53 with 128 bytes of data:
Reply from 68.12.8.53: bytes=128 time=44ms TTL=253
Reply from 68.12.8.53: bytes=128 time=17ms TTL=253
Reply from 68.12.8.53: bytes=128 time=79ms TTL=253
Reply from 68.12.8.53: bytes=128 time=46ms TTL=253
Reply from 68.12.8.53: bytes=128 time=14ms TTL=253
Reply from 68.12.8.53: bytes=128 time=15ms TTL=253
Reply from 68.12.8.53: bytes=128 time=19ms TTL=253
Reply from 68.12.8.53: bytes=128 time=17ms TTL=253
Reply from 68.12.8.53: bytes=128 time=13ms TTL=253
Reply from 68.12.8.53: bytes=128 time=15ms TTL=253
Reply from 68.12.8.53: bytes=128 time=17ms TTL=253
Reply from 68.12.8.53: bytes=128 time=17ms TTL=253
Request timed out.
Reply from 68.12.8.53: bytes=128 time=12ms TTL=253
Reply from 68.12.8.53: bytes=128 time=13ms TTL=253
Reply from 68.12.8.53: bytes=128 time=20ms TTL=253
Reply from 68.12.8.53: bytes=128 time=16ms TTL=253
Reply from 68.12.8.53: bytes=128 time=15ms TTL=253
Reply from 68.12.8.53: bytes=128 time=13ms TTL=253
Reply from 68.12.8.53: bytes=128 time=20ms TTL=253
Reply from 68.12.8.53: bytes=128 time=14ms TTL=253
Reply from 68.12.8.53: bytes=128 time=20ms TTL=253
Reply from 68.12.8.53: bytes=128 time=17ms TTL=253
Reply from 68.12.8.53: bytes=128 time=19ms TTL=253
Reply from 68.12.8.53: bytes=128 time=17ms TTL=253
Reply from 68.12.8.53: bytes=128 time=15ms TTL=253
Request timed out.
Reply from 68.12.8.53: bytes=128 time=14ms TTL=253
Reply from 68.12.8.53: bytes=128 time=64ms TTL=253
Reply from 68.12.8.53: bytes=128 time=14ms TTL=253
Reply from 68.12.8.53: bytes=128 time=20ms TTL=253
Reply from 68.12.8.53: bytes=128 time=18ms TTL=253
Reply from 68.12.8.53: bytes=128 time=32ms TTL=253
Reply from 68.12.8.53: bytes=128 time=18ms TTL=253
Reply from 68.12.8.53: bytes=128 time=26ms TTL=253
Reply from 68.12.8.53: bytes=128 time=52ms TTL=253
Reply from 68.12.8.53: bytes=128 time=31ms TTL=253
Reply from 68.12.8.53: bytes=128 time=19ms TTL=253
Reply from 68.12.8.53: bytes=128 time=41ms TTL=253
Reply from 68.12.8.53: bytes=128 time=14ms TTL=253
Reply from 68.12.8.53: bytes=128 time=12ms TTL=253
Reply from 68.12.8.53: bytes=128 time=25ms TTL=253
Reply from 68.12.8.53: bytes=128 time=14ms TTL=253
Reply from 68.12.8.53: bytes=128 time=13ms TTL=253
Reply from 68.12.8.53: bytes=128 time=14ms TTL=253
Reply from 68.12.8.53: bytes=128 time=14ms TTL=253
Reply from 68.12.8.53: bytes=128 time=13ms TTL=253
Reply from 68.12.8.53: bytes=128 time=60ms TTL=253
Reply from 68.12.8.53: bytes=128 time=13ms TTL=253
Reply from 68.12.8.53: bytes=128 time=18ms TTL=253
Reply from 68.12.8.53: bytes=128 time=54ms TTL=253
Reply from 68.12.8.53: bytes=128 time=13ms TTL=253
Reply from 68.12.8.53: bytes=128 time=46ms TTL=253
Reply from 68.12.8.53: bytes=128 time=12ms TTL=253
Reply from 68.12.8.53: bytes=128 time=15ms TTL=253
Reply from 68.12.8.53: bytes=128 time=13ms TTL=253
Reply from 68.12.8.53: bytes=128 time=78ms TTL=253
Reply from 68.12.8.53: bytes=128 time=53ms TTL=253
Reply from 68.12.8.53: bytes=128 time=13ms TTL=253
Request timed out.
Reply from 68.12.8.53: bytes=128 time=30ms TTL=253
Reply from 68.12.8.53: bytes=128 time=19ms TTL=253
Reply from 68.12.8.53: bytes=128 time=15ms TTL=253
Reply from 68.12.8.53: bytes=128 time=58ms TTL=253
Reply from 68.12.8.53: bytes=128 time=14ms TTL=253
Reply from 68.12.8.53: bytes=128 time=15ms TTL=253
Reply from 68.12.8.53: bytes=128 time=14ms TTL=253
Reply from 68.12.8.53: bytes=128 time=16ms TTL=253
Reply from 68.12.8.53: bytes=128 time=25ms TTL=253
Reply from 68.12.8.53: bytes=128 time=14ms TTL=253
Reply from 68.12.8.53: bytes=128 time=36ms TTL=253
Reply from 68.12.8.53: bytes=128 time=13ms TTL=253
Request timed out.
Reply from 68.12.8.53: bytes=128 time=13ms TTL=253
Reply from 68.12.8.53: bytes=128 time=13ms TTL=253
Reply from 68.12.8.53: bytes=128 time=14ms TTL=253
Reply from 68.12.8.53: bytes=128 time=15ms TTL=253
Reply from 68.12.8.53: bytes=128 time=15ms TTL=253
Reply from 68.12.8.53: bytes=128 time=20ms TTL=253
Reply from 68.12.8.53: bytes=128 time=15ms TTL=253
Reply from 68.12.8.53: bytes=128 time=13ms TTL=253
Reply from 68.12.8.53: bytes=128 time=23ms TTL=253
Reply from 68.12.8.53: bytes=128 time=17ms TTL=253
Reply from 68.12.8.53: bytes=128 time=50ms TTL=253
Reply from 68.12.8.53: bytes=128 time=18ms TTL=253
Reply from 68.12.8.53: bytes=128 time=60ms TTL=253
Reply from 68.12.8.53: bytes=128 time=12ms TTL=253
Request timed out.
Reply from 68.12.8.53: bytes=128 time=17ms TTL=253
Reply from 68.12.8.53: bytes=128 time=17ms TTL=253
Reply from 68.12.8.53: bytes=128 time=14ms TTL=253
Reply from 68.12.8.53: bytes=128 time=16ms TTL=253
Reply from 68.12.8.53: bytes=128 time=16ms TTL=253
Reply from 68.12.8.53: bytes=128 time=39ms TTL=253
Reply from 68.12.8.53: bytes=128 time=14ms TTL=253
Request timed out.
Reply from 68.12.8.53: bytes=128 time=43ms TTL=253
Reply from 68.12.8.53: bytes=128 time=17ms TTL=253
Reply from 68.12.8.53: bytes=128 time=13ms TTL=253
Reply from 68.12.8.53: bytes=128 time=42ms TTL=253
Ping statistics for 68.12.8.53:
Packets: Sent = 100, Received = 94, Lost = 6 (6% loss),
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 79ms, Average = 23ms
now to 68.12.8.61
Pinging 68.12.8.61 with 128 bytes of data:
Reply from 68.12.8.61: bytes=128 time=14ms TTL=253
Reply from 68.12.8.61: bytes=128 time=17ms TTL=253
Reply from 68.12.8.61: bytes=128 time=17ms TTL=253
Reply from 68.12.8.61: bytes=128 time=17ms TTL=253
Reply from 68.12.8.61: bytes=128 time=16ms TTL=253
Reply from 68.12.8.61: bytes=128 time=16ms TTL=253
Reply from 68.12.8.61: bytes=128 time=20ms TTL=253
Reply from 68.12.8.61: bytes=128 time=70ms TTL=253
Reply from 68.12.8.61: bytes=128 time=18ms TTL=253
Reply from 68.12.8.61: bytes=128 time=17ms TTL=253
Reply from 68.12.8.61: bytes=128 time=17ms TTL=253
Reply from 68.12.8.61: bytes=128 time=34ms TTL=253
Reply from 68.12.8.61: bytes=128 time=18ms TTL=253
Reply from 68.12.8.61: bytes=128 time=19ms TTL=253
Reply from 68.12.8.61: bytes=128 time=36ms TTL=253
Reply from 68.12.8.61: bytes=128 time=16ms TTL=253
Reply from 68.12.8.61: bytes=128 time=28ms TTL=253
Reply from 68.12.8.61: bytes=128 time=21ms TTL=253
Reply from 68.12.8.61: bytes=128 time=17ms TTL=253
Reply from 68.12.8.61: bytes=128 time=18ms TTL=253
Reply from 68.12.8.61: bytes=128 time=22ms TTL=253
Reply from 68.12.8.61: bytes=128 time=19ms TTL=253
Reply from 68.12.8.61: bytes=128 time=18ms TTL=253
Reply from 68.12.8.61: bytes=128 time=17ms TTL=253
Reply from 68.12.8.61: bytes=128 time=56ms TTL=253
Reply from 68.12.8.61: bytes=128 time=19ms TTL=253
Request timed out.
Reply from 68.12.8.61: bytes=128 time=13ms TTL=253
Reply from 68.12.8.61: bytes=128 time=14ms TTL=253
Reply from 68.12.8.61: bytes=128 time=22ms TTL=253
Reply from 68.12.8.61: bytes=128 time=25ms TTL=253
Reply from 68.12.8.61: bytes=128 time=15ms TTL=253
Reply from 68.12.8.61: bytes=128 time=13ms TTL=253
Reply from 68.12.8.61: bytes=128 time=51ms TTL=253
Reply from 68.12.8.61: bytes=128 time=13ms TTL=253
Reply from 68.12.8.61: bytes=128 time=16ms TTL=253
Reply from 68.12.8.61: bytes=128 time=15ms TTL=253
Reply from 68.12.8.61: bytes=128 time=12ms TTL=253
Reply from 68.12.8.61: bytes=128 time=49ms TTL=253
Reply from 68.12.8.61: bytes=128 time=15ms TTL=253
Reply from 68.12.8.61: bytes=128 time=16ms TTL=253
Reply from 68.12.8.61: bytes=128 time=27ms TTL=253
Reply from 68.12.8.61: bytes=128 time=12ms TTL=253
Reply from 68.12.8.61: bytes=128 time=15ms TTL=253
Reply from 68.12.8.61: bytes=128 time=13ms TTL=253
Reply from 68.12.8.61: bytes=128 time=15ms TTL=253
Reply from 68.12.8.61: bytes=128 time=14ms TTL=253
Reply from 68.12.8.61: bytes=128 time=29ms TTL=253
Reply from 68.12.8.61: bytes=128 time=17ms TTL=253
Reply from 68.12.8.61: bytes=128 time=21ms TTL=253
Reply from 68.12.8.61: bytes=128 time=15ms TTL=253
Reply from 68.12.8.61: bytes=128 time=55ms TTL=253
Reply from 68.12.8.61: bytes=128 time=13ms TTL=253
Reply from 68.12.8.61: bytes=128 time=13ms TTL=253
Reply from 68.12.8.61: bytes=128 time=73ms TTL=253
Reply from 68.12.8.61: bytes=128 time=16ms TTL=253
Reply from 68.12.8.61: bytes=128 time=22ms TTL=253
Reply from 68.12.8.61: bytes=128 time=14ms TTL=253
Reply from 68.12.8.61: bytes=128 time=14ms TTL=253
Reply from 68.12.8.61: bytes=128 time=17ms TTL=253
Reply from 68.12.8.61: bytes=128 time=18ms TTL=253
Reply from 68.12.8.61: bytes=128 time=17ms TTL=253
Reply from 68.12.8.61: bytes=128 time=17ms TTL=253
Reply from 68.12.8.61: bytes=128 time=21ms TTL=253
Reply from 68.12.8.61: bytes=128 time=15ms TTL=253
Reply from 68.12.8.61: bytes=128 time=36ms TTL=253
Reply from 68.12.8.61: bytes=128 time=17ms TTL=253
Reply from 68.12.8.61: bytes=128 time=15ms TTL=253
Reply from 68.12.8.61: bytes=128 time=39ms TTL=253
Reply from 68.12.8.61: bytes=128 time=14ms TTL=253
Reply from 68.12.8.61: bytes=128 time=14ms TTL=253
Reply from 68.12.8.61: bytes=128 time=12ms TTL=253
Reply from 68.12.8.61: bytes=128 time=73ms TTL=253
Reply from 68.12.8.61: bytes=128 time=26ms TTL=253
Reply from 68.12.8.61: bytes=128 time=24ms TTL=253
Reply from 68.12.8.61: bytes=128 time=16ms TTL=253
Reply from 68.12.8.61: bytes=128 time=20ms TTL=253
Reply from 68.12.8.61: bytes=128 time=19ms TTL=253
Reply from 68.12.8.61: bytes=128 time=25ms TTL=253
Reply from 68.12.8.61: bytes=128 time=14ms TTL=253
Reply from 68.12.8.61: bytes=128 time=21ms TTL=253
Reply from 68.12.8.61: bytes=128 time=23ms TTL=253
Reply from 68.12.8.61: bytes=128 time=12ms TTL=253
Reply from 68.12.8.61: bytes=128 time=13ms TTL=253
Reply from 68.12.8.61: bytes=128 time=22ms TTL=253
Reply from 68.12.8.61: bytes=128 time=27ms TTL=253
Reply from 68.12.8.61: bytes=128 time=14ms TTL=253
Reply from 68.12.8.61: bytes=128 time=14ms TTL=253
Reply from 68.12.8.61: bytes=128 time=14ms TTL=253
Reply from 68.12.8.61: bytes=128 time=15ms TTL=253
Reply from 68.12.8.61: bytes=128 time=18ms TTL=253
Reply from 68.12.8.61: bytes=128 time=17ms TTL=253
Reply from 68.12.8.61: bytes=128 time=22ms TTL=253
Reply from 68.12.8.61: bytes=128 time=37ms TTL=253
Reply from 68.12.8.61: bytes=128 time=17ms TTL=253
Reply from 68.12.8.61: bytes=128 time=62ms TTL=253
Reply from 68.12.8.61: bytes=128 time=14ms TTL=253
Reply from 68.12.8.61: bytes=128 time=18ms TTL=253
Reply from 68.12.8.61: bytes=128 time=53ms TTL=253
Reply from 68.12.8.61: bytes=128 time=30ms TTL=253
Ping statistics for 68.12.8.61:
Packets: Sent = 100, Received = 99, Lost = 1 (1% loss),
Approximate round trip times in milli-seconds:
Minimum = 12ms, Maximum = 73ms, Average = 22ms
--
Don't knock on deaths door, ring the bell and run, he hates that. |
|
Zar
Premium
join:2001-08-04
Platte City, MO
| reply to Micheal64
jpegs of pingplotter and vroute |
|
Zar
Premium
join:2001-08-04
Platte City, MO
| reply to Micheal64
more jpegs of said programs |
|
Zar
Premium
join:2001-08-04
Platte City, MO
| reply to Micheal64
Here is a bad PingPlotter from the other day that you might have already seen..
»Anyone know why cox has this crazy routing?
--
Don't knock on deaths door, ring the bell and run, he hates that. |
|
Micheal64
join:2002-03-05
Oklahoma City, OK
| Papa Smurf, I'm not sure if you're familiar with Netperf (Unix utility) or not, but I'm seeing errors when I'm testing UDP streaming to a system at work.
traceroute to 208.6.XXX.55 (208.6.XXX.55), 64 hops max, 40 byte packets
1 10.0.0.1 (10.0.0.1) 48.357 ms 21.744 ms 78.675 ms
2 68.12.8.13 (68.12.8.13) 46.423 ms 15.709 ms 37.095 ms
3 68.12.14.9 (68.12.14.9) 29.329 ms 19.544 ms 26.423 ms
4 68.1.0.104 (68.1.0.104) 31.713 ms 24.100 ms 23.577 ms
5 68.1.0.107 (68.1.0.107) 31.981 ms 28.934 ms 30.998 ms
6 gigabitethernet2-1.ipcolo1.Dallas1.Level3.net (209.246.136.33) 64.110 ms 24.312 ms 26.897 ms
7 gigabitethernet10-1.core1.Dallas1.Level3.net (209.244.15.69) 40.843 ms 28.985 ms 42.208 ms
8 sprint-level3-oc12.Dallas1.Level3.net (209.245.240.166) 58.035 ms 48.262 ms 25.459 ms
9 sl-gw30-fw-0-0.sprintlink.net (144.232.12.167) 39.473 ms 47.218 ms 34.931 ms
10 sl-ccnetw-5-0.sprintlink.net (160.81.99.110) 50.314 ms 41.612 ms 49.600 ms
11 208.6.XXX.55 (208.6.XXX.55) 75.172 ms 46.119 ms 124.185 ms
--- 208.6.XXX.55 ping statistics ---
11 packets transmitted, 11 packets received, 0% packet loss
round-trip min/avg/max/stddev = 28.568/55.472/140.052/31.682 ms
These tests are being sent from my home system to a receiver on my work server:
netperf -H 208.6.XXX.55 -t UDP_STREAM
UDP UNIDIRECTIONAL SEND TEST to 208.6.XXX.55 : histogram
Socket Message Elapsed Messages
Size Size Time Okay Errors Throughput
bytes bytes secs # # 10^6bits/sec
9216 9216 10.01 945 102913 6.96
42080 10.01 33 0.24
netperf -H 208.6.XXX.55 -t TCP_STREAM
TCP STREAM TEST to 208.6.XXX.55 : histogram
Recv Send Send
Socket Socket Message Elapsed
Size Size Size Time Throughput
bytes bytes bytes secs. 10^6bits/sec
16384 32768 32768 10.92 0.24
Are there any known issues with routing of UDP traffic? I'm concerned with the error rate that my system is seeing on this one. It could tie in with your Gaming thread. What's the possibility that there is a problem with routing UDP traffic and with the amount of gamers sending out UDP, that the routers are having problems passing it and getting overloaded at times? |
|
PapaSmurf
A Smurfy Salute
VIP
join:2001-08-05
smurfville
| reply to Micheal64
Hey dredster,
I'm working with some TOC resources on this thread. They are new at this forum, but I'll be working with them to keep updates going here. First order of business is to sort through this thread and determine how many issues there are, where they are, what has been done to date (open tickets, trucks rolls, etc.) and what needs to be done next. Still working that. Until we get there, I don't want to speculate on where or what a problem might be. I'm not real certain we can generalize that way. Hope that doesn't come across sounding like the "party line" response. I just want to give these guys a chance to assess what we have and then dig in. Fair? |
|
Micheal64
join:2002-03-05
Oklahoma City, OK
| Papa Smurf, as long as someone can say "Yes, I can see a problem here" and sincerely mean it when they say they're looking into it, I'm good. It's when I'm told that and the tickets are ignored that I have a problem.  |
|
Micheal64
join:2002-03-05
Oklahoma City, OK
| One thing that may not be readily noticed is that there appears to be a problematic router within the Okc pipe that is consitantly showing latency in a lot of the tests into the metro area.
Take a look at »/badrouters/68.12.14.14
and you should see loss on a consistant basis there. |
|
