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
| Re: Latency in Oklahoma City 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 | 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!! | |
|
 | |
| |
PapaSmurf
A Smurfy Salute
VIP
join:2001-08-05
smurfville
| Re: Latency in Oklahoma City 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. | |
|
| | | |
| | | |
Micheal64
join:2002-03-05
Oklahoma City, OK
|  Re: Latency in Oklahoma City
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. | |
|
| | | | |
Micheal64
join:2002-03-05
Oklahoma City, OK
| Re: Latency in Oklahoma City 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
| Re: Latency in Oklahoma City 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. | |
|
| | | | | | | |
meester
Premium
join:2000-06-03
Oklahoma City, OK
clubs:
| 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] | |
|
catseyenu
Ack Pfft
Premium
join:2001-11-17
Fix East
|
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] | |
|
| CoxPCTech
join:2002-02-20
Oklahoma City, OK
| Re: Latency in Oklahoma City We missed a house call? That's very dire circumstances. We don't go home til all the calls are done. Period. I've been out til 1am before running PC calls. Were you waiting for a Line Tech? Most likely you were if everyone else has looked at your problem. Line Techs do not make customer contact unltil they fix the problem. As this thread has noted, it does look like we have a troublesome router and I hope it gets fixed soon, but it's out of my hands, I'm a field tech, and my internet suffers just as much as the rest of you all. We've had a rough time of it since the @Home shutdown, I don't know if anyone saw, but we pumped 178 MILLION dollars into @Home JUST to keep them going so none of our users would go down because of their bankruptcy. I think we are biting off more than we can chew by switching over the Roadrunner areas before we have all the bugs worked out of the system, but it's also not my department.
It looks like everyone is giving it their all, and it looks like this is standard procedure in Cox systems that do the switchover. It's rough running for a few weeks, and hopefully it will all be taken care of as expediantly as possible. Bear with us and we'll have a great service up and going again. | |
|
Zar
Premium
join:2001-08-04
Platte City, MO
| 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
| jpegs of pingplotter and vroute | |
|
Zar
Premium
join:2001-08-04
Platte City, MO
| more jpegs of said programs | |
|
Zar
Premium
join:2001-08-04
Platte City, MO
| 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
| Re: Latency in Oklahoma CityPapa 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
| 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
| Re: Latency in Oklahoma City 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
| Re: Latency in Oklahoma City 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. | |
|
| |
PapaSmurf
A Smurfy Salute
VIP
join:2001-08-05
smurfville
| Agree. Hopefully, we can translate that into some meaningful site status notices as well. In any event, we'll all make sure we identify the real problem and ensure nothing's ignored.
I saw that 69.12.14.14 and a few others. That's part of the process TOC is engaged in, identifying the culprits. These composite posts here help as well. We can evidence who is being affected and how, especially if one or two points are causing all the grief. | |
|
| | |
Micheal64
join:2002-03-05
Oklahoma City, OK | Re: Latency in Oklahoma City Agreed. | |
|
imtim83
You All Deserve The Economic Meltdown
Premium
join:2001-06-03
Kenner, LA | Dredster i hate when tickets are ignored too. Then its like you are waiting for nothing.
--
Any help is very appreicated.Please Reply.Thanks | |
|
Micheal64
join:2002-03-05
Oklahoma City, OK
| Red Hat, you might find this interesting also. I'm seeing an awful lot of broadcast DHCP traffic being generated from my gateway as well. I don't know if this may have any bearing on any possible load issue or not. I've noticed this for awhile now and have mentioned it in other threads but thought that I might put some numbers here for you folks to go over.
Please note that the "message repeated" is what FreeBSD and other syslog daemons do to prevent the system from getting flooded due to the firewall entries. They all pertain to the last "log" entry above them.
For what it's worth, these are coming into my actual ip (68.12.xx.221) and I always thought that the 10.x.x.x block should stop at the cable modem and not pass to the public IP space. I could be mistaken on that.
-----------------
Mar 12 00:00:00 caverns newsyslog[21109]: logfile turned over
Mar 12 00:02:09 caverns /kernel: ipfw: 800 Deny UDP 10.0.0.1:67 255.255.255.255:68 in via ep0
Mar 12 00:02:09 caverns /kernel: ipfw: 800 Deny UDP 10.0.0.1:67 255.255.255.255:68 in via ep0
Mar 12 00:03:31 caverns /kernel: ipfw: 800 Deny UDP 10.0.0.1:67 255.255.255.255:68 in via ep0
Mar 12 00:08:31 caverns /kernel: ipfw: 800 Deny UDP 10.0.0.1:67 255.255.255.255:68 in via ep0
Mar 12 00:13:00 caverns /kernel: ipfw: 800 Deny UDP 10.0.0.1:67 255.255.255.255:68 in via ep0
Mar 12 00:18:31 caverns last message repeated 123 times
Mar 12 00:28:31 caverns last message repeated 2 times
Mar 12 00:38:31 caverns last message repeated 4 times
Mar 12 00:49:20 caverns last message repeated 16 times
Mar 12 00:58:31 caverns last message repeated 4 times
Mar 12 01:08:45 caverns last message repeated 6 times
Mar 12 01:20:07 caverns last message repeated 4 times
Mar 12 01:28:32 caverns last message repeated 4 times
Mar 12 01:38:33 caverns last message repeated 4 times
Mar 12 01:48:32 caverns last message repeated 2 times
Mar 12 01:58:32 caverns last message repeated 2 times
Mar 12 02:08:32 caverns last message repeated 2 times
Mar 12 02:18:32 caverns last message repeated 4 times
Mar 12 02:29:37 caverns last message repeated 4 times
Mar 12 02:38:32 caverns last message repeated 4 times
Mar 12 02:48:32 caverns last message repeated 2 times
Mar 12 02:58:32 caverns last message repeated 2 times
Mar 12 03:12:13 caverns last message repeated 6 times
Mar 12 03:19:05 caverns last message repeated 4 times
Mar 12 03:28:33 caverns last message repeated 2 times
Mar 12 03:38:33 caverns last message repeated 2 times
Mar 12 03:48:33 caverns last message repeated 2 times
Mar 12 03:58:33 caverns last message repeated 2 times
Mar 12 04:08:33 caverns last message repeated 2 times
Mar 12 04:18:33 caverns last message repeated 2 times
Mar 12 04:28:33 caverns last message repeated 2 times
Mar 12 04:38:33 caverns last message repeated 2 times
Mar 12 04:52:27 caverns last message repeated 4 times
Mar 12 05:03:01 caverns last message repeated 4 times
Mar 12 05:08:33 caverns last message repeated 2 times
Mar 12 05:18:33 caverns last message repeated 4 times
Mar 12 05:28:33 caverns last message repeated 2 times
Mar 12 05:41:08 caverns last message repeated 6 times
Mar 12 05:48:34 caverns last message repeated 2 times
Mar 12 06:03:34 caverns /kernel: ipfw: 800 Deny UDP 10.0.0.1:67 255.255.255.255:68 in via ep0
Mar 12 06:08:34 caverns /kernel: ipfw: 800 Deny UDP 10.0.0.1:67 255.255.255.255:68 in via ep0
Mar 12 06:13:34 caverns /kernel: ipfw: 800 Deny UDP 10.0.0.1:67 255.255.255.255:68 in via ep0
Mar 12 06:23:34 caverns last message repeated 8 times
Mar 12 06:33:35 caverns last message repeated 4 times
Mar 12 06:43:20 caverns last message repeated 12 times
Mar 12 06:53:21 caverns last message repeated 8 times
Mar 12 07:03:21 caverns last message repeated 10 times
Mar 12 07:13:21 caverns last message repeated 6 times
Mar 12 07:23:21 caverns last message repeated 6 times
Mar 12 07:33:21 caverns last message repeated 4 times
Mar 12 07:43:21 caverns last message repeated 16 times
Mar 12 07:53:33 caverns last message repeated 14 times
Mar 12 08:03:34 caverns last message repeated 44 times
Mar 12 08:13:33 caverns last message repeated 50 times
Mar 12 08:23:34 caverns last message repeated 46 times
Mar 12 08:33:34 caverns last message repeated 54 times
Mar 12 08:43:34 caverns last message repeated 46 times
Mar 12 08:53:34 caverns last message repeated 46 times
Mar 12 09:03:35 caverns last message repeated 50 times
Mar 12 09:13:35 caverns last message repeated 42 times
Mar 12 09:23:35 caverns last message repeated 50 times
Mar 12 09:33:34 caverns last message repeated 56 times
Mar 12 09:43:35 caverns last message repeated 44 times
Mar 12 09:53:35 caverns last message repeated 46 times
Mar 12 10:03:34 caverns last message repeated 48 times
Mar 12 10:13:34 caverns last message repeated 42 times
Mar 12 10:23:34 caverns last message repeated 44 times
Mar 12 10:33:35 caverns last message repeated 46 times
Mar 12 10:43:35 caverns last message repeated 53 times
Mar 12 10:53:35 caverns last message repeated 52 times
Mar 12 11:03:35 caverns last message repeated 45 times
Mar 12 11:13:35 caverns last message repeated 48 times
Mar 12 11:23:35 caverns last message repeated 48 times
Mar 12 11:33:41 caverns last message repeated 54 times
Mar 12 11:43:36 caverns last message repeated 48 times
Mar 12 11:53:37 caverns last message repeated 47 times
Mar 12 12:03:36 caverns last message repeated 50 times
Mar 12 12:13:37 caverns last message repeated 52 times
Mar 12 12:23:37 caverns last message repeated 53 times
Mar 12 12:33:37 caverns last message repeated 51 times
Mar 12 12:43:38 caverns last message repeated 49 times
Mar 12 12:53:38 caverns last message repeated 52 times
Mar 12 13:03:38 caverns last message repeated 50 times
Mar 12 13:13:38 caverns last message repeated 52 times
Mar 12 13:23:38 caverns last message repeated 48 times
Mar 12 13:33:39 caverns last message repeated 49 times
Mar 12 13:43:39 caverns last message repeated 48 times
Mar 12 13:53:40 caverns last message repeated 58 times
Mar 12 14:03:40 caverns last message repeated 56 times
Mar 12 14:13:40 caverns last message repeated 50 times
Mar 12 14:23:43 caverns last message repeated 74 times
Mar 12 14:33:41 caverns last message repeated 82 times
Mar 12 14:43:41 caverns last message repeated 44 times
Mar 12 14:53:41 caverns last message repeated 44 times
Mar 12 15:03:42 caverns last message repeated 54 times
Mar 12 15:13:42 caverns last message repeated 48 times
Mar 12 15:23:42 caverns last message repeated 42 times
Mar 12 15:33:44 caverns last message repeated 48 times
Mar 12 15:35:41 caverns /kernel: ipfw: 800 Deny UDP 10.0.0.1:67 255.255.255.255:68 in via ep0
Mar 12 15:36:12 caverns last message repeated 5 times
Mar 12 15:38:11 caverns last message repeated 9 times
Mar 12 15:48:12 caverns last message repeated 44 times
Mar 12 15:51:12 caverns last message repeated 16 times
Mar 12 15:53:42 caverns /kernel: ipfw: 800 Deny UDP 10.0.0.1:67 255.255.255.255:68 in via ep0
Mar 12 15:54:13 caverns last message repeated 3 times
Mar 12 15:56:12 caverns last message repeated 8 times
Mar 12 15:58:13 caverns last message repeated 13 times
Mar 12 18:35:07 caverns /kernel: ipfw: 800 Deny UDP 10.0.0.1:67 255.255.255.255:68 in via ep0
Mar 12 18:44:48 caverns last message repeated 56 times
Mar 12 18:55:05 caverns last message repeated 58 times
Mar 12 19:04:48 caverns last message repeated 48 times
Mar 12 19:14:49 caverns last message repeated 48 times
Mar 12 19:24:49 caverns last message repeated 44 times
Mar 12 19:34:50 caverns last message repeated 47 times
Mar 12 19:44:49 caverns last message repeated 41 times
Mar 12 19:54:50 caverns last message repeated 48 times
Mar 12 20:04:50 caverns last message repeated 56 times
Mar 12 20:14:53 caverns last message repeated 64 times
Mar 12 20:24:59 caverns last message repeated 88 times
Mar 12 20:34:54 caverns last message repeated 86 times
Mar 12 20:44:54 caverns last message repeated 84 times
Mar 12 20:54:55 caverns last message repeated 84 times
[text was edited by author 2002-03-13 01:32:37] | |
|
powerhog
Stinkin' up the joint
Premium
join:2000-12-14
Owasso, OK
 ·AtlasOK
| From what you told toy4x4, it looks like you want Tulsa problems here too. Things aren't doing too well tonight on my usually "good" connection.
My line test: »/quality/nil/698284
Here's another for reference: »/quality/nil/693889
[text was edited by author 2002-03-12 22:54:51] | |
|
catseyenu
Ack Pfft
Premium
join:2001-11-17
Fix East
| Heh, if I could just make it past the "Gate".
These late night scans beat my day results by at least 100%.
»/quality/nil/697473 | |
|
cwren
join:2001-01-03
Oklahoma City, OK
| This one was done at 6:15 a.m. CST, so traffic should have been low.
Pinging 68.12.8.133 with 128 bytes of data:
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=13ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Request timed out.
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=11ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=8ms TTL=254
Reply from 68.12.8.133: bytes=128 time=27ms TTL=254
Reply from 68.12.8.133: bytes=128 time=8ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Request timed out.
Reply from 68.12.8.133: bytes=128 time=12ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=11ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=11ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Request timed out.
Reply from 68.12.8.133: bytes=128 time=8ms TTL=254
Reply from 68.12.8.133: bytes=128 time=8ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=8ms TTL=254
Reply from 68.12.8.133: bytes=128 time=11ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=17ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=8ms TTL=254
Reply from 68.12.8.133: bytes=128 time=11ms TTL=254
Reply from 68.12.8.133: bytes=128 time=8ms TTL=254
Request timed out.
Reply from 68.12.8.133: bytes=128 time=14ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=12ms TTL=254
Reply from 68.12.8.133: bytes=128 time=12ms TTL=254
Reply from 68.12.8.133: bytes=128 time=12ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=8ms TTL=254
Reply from 68.12.8.133: bytes=128 time=27ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Request timed out.
Reply from 68.12.8.133: bytes=128 time=12ms TTL=254
Reply from 68.12.8.133: bytes=128 time=11ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=11ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=13ms TTL=254
Reply from 68.12.8.133: bytes=128 time=12ms TTL=254
Reply from 68.12.8.133: bytes=128 time=15ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Request timed out.
Reply from 68.12.8.133: bytes=128 time=11ms TTL=254
Reply from 68.12.8.133: bytes=128 time=8ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=8ms TTL=254
Reply from 68.12.8.133: bytes=128 time=10ms TTL=254
Reply from 68.12.8.133: bytes=128 time=8ms TTL=254
Reply from 68.12.8.133: bytes=128 time=8ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=8ms TTL=254
Reply from 68.12.8.133: bytes=128 time=9ms TTL=254
Reply from 68.12.8.133: bytes=128 time=12ms TTL=254
Request timed out.
Reply from 68.12.8.133: bytes=128 time=12ms TTL=254
Reply from 68.12.8.133: bytes=128 time=13ms TTL=254
Reply from 68.12.8.133: bytes=128 time=11ms TTL=254
Ping statistics for 68.12.8.133:
Packets: Sent = 100, Received = 93, Lost = 7 (7% loss),
Approximate round trip times in milli-seconds:
Minimum = 8ms, Maximum = 27ms, Average = 10ms | |
|
Zar
Premium
join:2001-08-04
Platte City, MO
| March 13 2002 at 8:30am | |
|
|
Micheal64
join:2002-03-05
Oklahoma City, OK | Re: Latency in Oklahoma City »/quality/nil/698760
Still 10% loss on the 68.12.14.14 router. Also seeing the latency on my gateway on this one. I'm assuming that 68.12.8.14, 68.12.8.2, and 68.12.64.1 are the same unit. | |
|
PapaSmurf
A Smurfy Salute
VIP
join:2001-08-05
smurfville | Hey Dredster,
We worked through this post and identified what we think are possible candidates for NOC attention. Preparing tickets now. I'll be keeping an eye on those to see we get activity on them. | |
|
|
Micheal64
join:2002-03-05
Oklahoma City, OK
| Re: Latency in Oklahoma City Thanks for the help Papa Smurf,
In the meantime, can you provide any info on the DHCP broadcasts that I'm constantly seeing from 10.0.0.1? Is this normal for the current network configuration? If it is, I'll not worry about it any more.
[text was edited by author 2002-03-13 16:34:11] | |
|
|
Micheal64
join:2002-03-05
Oklahoma City, OK
| said by PapaSmurf:
Hey Dredster,
We worked through this post and identified what we think are possible candidates for NOC attention. Preparing tickets now. I'll be keeping an eye on those to see we get activity on them.
Care to fill us in on what you think may be the problem? Or would you prefer to wait and see what NOC/TOC/SOC says about it?:)
[text was edited by author 2002-03-13 16:38:43] | |
|
Zar
Premium
join:2001-08-04
Platte City, MO
| Cox called today. I am getting a truck roll. I tried to tell them that it is NOT my connection, its THEIR gateway that shows the packet losses..
68.12.8.53 BAD
68.12.8.61 GOOD!!
Well, whatever to make them happy, Will take notes and ask lots of questions..
And will show them my SWB DSL and how I get GREAT pings and NO packet loss!!
--
Don't knock on deaths door, ring the bell and run, he hates that. | |
|
|
Zar
Premium
join:2001-08-04
Platte City, MO
| March 13 4:30 pm | |
|
cwren
join:2001-01-03
Oklahoma City, OK
| Here are a couple of traces taken at 5:45 p.m. CST, March 13. | |
|
|
Micheal64
join:2002-03-05
Oklahoma City, OK
| Re: Latency in Oklahoma City »/quality/nil/698760
Here's test data from earlier today. I'm currently awaiting another one. At this time, I've got minor spikes.
Pinging 68.12.64.1 with 1500 bytes of data:
Reply from 68.12.64.1: bytes=1500 time=70ms TTL=254
Reply from 68.12.64.1: bytes=1500 time=154ms TTL=254
Reply from 68.12.64.1: bytes=1500 time=102ms TTL=254
Reply from 68.12.64.1: bytes=1500 time=54ms TTL=254
Reply from 68.12.64.1: bytes=1500 time=75ms TTL=254
Reply from 68.12.64.1: bytes=1500 time=47ms TTL=254
Reply from 68.12.64.1: bytes=1500 time=138ms TTL=254
Reply from 68.12.64.1: bytes=1500 time=138ms TTL=254
Reply from 68.12.64.1: bytes=1500 time=93ms TTL=254
Reply from 68.12.64.1: bytes=1500 time=128ms TTL=254
Ping statistics for 68.12.64.1:
Packets: Sent = 10, Received = 10, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 47ms, Maximum = 154ms, Average = 99ms | |
|
|
|
|
