pbarrow
Premium
join:2003-09-16
Montgomery, AL
| [HSI] AT&T problems
This problem has been going on here in Montgomery for a long time - with certain AT&T routers in Atlanta having much higher latency. I think this may be contributing to some of my speed issues.
Tracing route to dp.msnmessenger.akadns.net [65.54.239.210]
over a maximum of 30 hops:
1 1 ms 10 ms 10 ms 192.168.1.1
2 5 ms 11 ms 8 ms 10.108.64.1
3 16 ms 8 ms 7 ms cr1ge1-2-130mtgmal.mtgm.al.charter.com [66.168.2
40.1]
4 12 ms 15 ms 12 ms 12.116.116.45
5 75 ms 73 ms 73 ms tbr2.attga.ip.att.net [12.122.85.158] ===============
6 88 ms 78 ms 76 ms tbr2.sl9mo.ip.att.net [12.122.10.138]
7 85 ms 87 ms 85 ms tbr1.sl9mo.ip.att.net [12.122.9.141]
8 89 ms 86 ms 88 ms tbr2.sffca.ip.att.net [12.122.10.42]
9 81 ms 91 ms 80 ms 12.122.80.41
10 * * * Request timed out.
11 * *
Tracing route to dslreports.com [209.123.109.175]
over a maximum of 30 hops:
1 10 ms 10 ms 10 ms 192.168.1.1
2 9 ms 12 ms 11 ms 10.108.64.1
3 8 ms 9 ms 10 ms cr1ge1-2-130mtgmal.mtgm.al.charter.com [66.168.2
40.1]
4 15 ms 15 ms 17 ms 12.116.116.45
5 37 ms 41 ms 39 ms tbr2.attga.ip.att.net [12.122.85.158] ===============
6 41 ms 38 ms 46 ms 12.122.17.65
7 39 ms 40 ms 37 ms cr2.wswdc.ip.att.net [12.122.1.174]
8 54 ms 40 ms 40 ms cr2.n54ny.ip.att.net [12.122.3.37]
9 38 ms 37 ms 38 ms 12.122.16.142
10 37 ms 37 ms 37 ms gar1.nwrnj.ip.att.net [12.123.0.153]
11 42 ms 51 ms 44 ms att-gige.esd1.nwr.nac.net [12.119.140.26]
12 40 ms 36 ms 41 ms 3.ge-3-0-0.gbr2.nwr.nac.net [209.123.11.189]
13 38 ms 38 ms 231 ms 0.so-0-3-0.gbr1.oct.nac.net [209.123.11.233]
14 165 ms 42 ms 38 ms www.dslreports.com [209.123.109.175]
Trace complete.
Tracing route to www.oneringnetworks.com [66.187.177.19]
over a maximum of 30 hops:
1 1 ms 10 ms 10 ms 192.168.1.1
2 10 ms 8 ms 15 ms 10.108.64.1
3 7 ms 8 ms 8 ms cr1ge1-2-130mtgmal.mtgm.al.charter.com [66.168.2
40.1]
4 12 ms 26 ms 12 ms 12.116.116.45
5 14 ms 18 ms 16 ms tbr1.attga.ip.att.net [12.122.85.150] ===============
6 22 ms 26 ms 13 ms ggr2.attga.ip.att.net [12.123.20.201]
7 14 ms 14 ms 21 ms ar3-a3120s3.wswdc.ip.att.net [192.205.34.22]
8 14 ms 12 ms 11 ms bpr1-so-0-0-0.AtlantaPaix.savvis.net [208.172.75
.110]
9 13 ms 13 ms 11 ms 216.89.82.78
10 15 ms 13 ms 18 ms xconn.core2-edge1.atl.oneringnetworks.net [66.18
7.176.5]
11 12 ms 14 ms 18 ms oneringnetworks.com [66.187.177.19]
Trace complete.
Tracing route to google.navigation.opendns.com [208.69.32.230]
over a maximum of 30 hops:
1 1 ms 10 ms 10 ms 192.168.1.1
2 22 ms 10 ms 6 ms 10.108.64.1
3 9 ms 6 ms 17 ms cr1ge1-2-130mtgmal.mtgm.al.charter.com [66.168.2
40.1]
4 13 ms 17 ms 12 ms 12.116.116.45
5 12 ms 15 ms 15 ms tbr2.attga.ip.att.net [12.122.85.158] ===============
6 16 ms 13 ms 11 ms ggr2.attga.ip.att.net [12.122.81.153]
7 17 ms 15 ms 21 ms 192.205.33.46
8 14 ms 14 ms 12 ms 0.so-1-1-0.XT2.ATL4.ALTER.NET [152.63.86.174]
9 74 ms 32 ms 32 ms 0.so-5-0-0.XL2.IAD8.ALTER.NET [152.63.0.130]
10 32 ms 29 ms 33 ms POS7-0.GW5.IAD8.ALTER.NET [152.63.36.65]
11 30 ms 36 ms 30 ms 63.65.187.230
12 36 ms 36 ms 31 ms google.navigation.opendns.com [208.69.32.230]
Trace complete. |
|
NormanS
Premium,MVM
join:2001-02-14
San Jose, CA
 ·Pacific Bell - SBC
1 edit | Your first trace route shows a problem at the far end. AT&T has nothing to do with unresponsive far end servers. My packets don't even leave the SBC Global backbone:
I would guess that 'dp.msnmessenger.akadns.net' just isn't responding to trace route requests. Period. Nothing to do with AT&T. Not even a problem, really. ICMP response probably has an adverse affect on the MSN Messenger service, so it is disabled.
Your second trace route shows the first latency issue on a Net Access Corporation (NAC) router. Again, not an AT&T issue.
Your third trace route shows average latency to the far end is 14ms. There is nothing wrong there; high latency intermediate routers have no affect on packets passed through the router. It only means that those routers are delaying ICMP response. Not a problem. Not an AT&T issue.
If you are concerned about that 74ms latency at hop 9 in your fourth trace route, don't be. My comments on your third trace route apply to the fourth.
Frankly, I don't see any problems with your trace routes. Certainly nothing caused by AT&T Worldnet Services transit routers.
--
Norman
~Oh Lord, why have you come
~To Konnyu, with the Lion and the Drum |
|
pbarrow
Premium
join:2003-09-16
Montgomery, AL
3 edits | You are mistaken. That's not the issue at all. That site is unpingable and why it times out. It's the MSN IM server and MSN IM logs in fine. The problem is the higher responces times on some of the hop 5 traces.
Latency should not be double and up to 5 times as high as the latency on the hop preceeding it, especially on a hop so close to you - hop 5 is only 2 hops away from Charter. hop 4 is in Montgomery I assume but certainly in Alabama since it's the point where Charter joins to ATT and then it goes to hop5 - Atlanta and on some traces (like googleand some others) the atlanta response is always 12 - 26ms or so and and on others (like yahoo and others) it's always higher. I think this is part of the speed problems I have but as is it explained below I could be wrong. That's why I'd like to know if any of the rest of you in Alabama see similar responses on the Atlanta hop and if you have any speed problems or not. Try tracing to Google and Yahoo and see if you get similar results.
We all know from experience a few months back that response times around 100ms on hop 4 here were affecting most of you in Birmingham also. So maybe this condition is affecting some of us also.
-----------------------------------------------------
2007-07-12 10:06:20 : From charter_hsd
Paul,
I was able to reproduce the results you are seeing from a UNIX server located in the Leeds Headend.
I have sent my findings to the residential network engineers and they have confirmed that they can see the same thing through their tests.
If there is an issue, we believe it to be on the AT&T network.
I say "if there is an issue" because AT&T could simply be giving ICMP a low priority under certain circumstances. This practice can result in an ICMP ECHO reply taking an unusually long amount of time to be processed and returned. This practice does not affect traffic that is routed through the router, it only affects traffic to the router.
In my opinion this is probably not occurring. I say this because because the RTT to the network hops beyond AT&T will not be affected by this practice. However in both of our traces the hops beyond AT&T do appear to be affected.
One of the residential engineers will be contacting AT&T and requesting they investigate.
We'll just have to wait and see what they come up with.
Regards.
---------------------------------------------------------
Tracing route to yahoo.com [66.94.234.13]
over a maximum of 30 hops:
1 1 ms 10 ms 10 ms 192.168.1.1
2 7 ms 7 ms 7 ms 10.108.64.1
3 7 ms 12 ms 7 ms cr1ge1-2-130mtgmal.mtgm.al.charter.com [66.168.2
40.1]
4 12 ms 11 ms 13 ms 12.116.116.45
5 77 ms 78 ms 79 ms tbr2.attga.ip.att.net [12.122.85.158]
6 82 ms 81 ms 82 ms tbr2.sl9mo.ip.att.net [12.122.10.138]
7 83 ms 85 ms 84 ms tbr1.sl9mo.ip.att.net [12.122.9.141]
8 85 ms 85 ms 88 ms tbr2.sffca.ip.att.net [12.122.10.42]
9 84 ms 85 ms 85 ms 12.122.114.73
10 85 ms 88 ms 84 ms 12.86.154.18
11 86 ms 87 ms 87 ms ge-3-0-0-p240.msr1.scd.yahoo.com [216.115.106.17
7]
12 86 ms 84 ms 82 ms ten-1-3-bas2.scd.yahoo.com [66.218.82.219]
13 86 ms 86 ms 86 ms w2.rc.vip.scd.yahoo.com [66.94.234.13]
Trace complete.
Tracing route to www.l.google.com [209.85.165.104]
over a maximum of 30 hops:
1 1 ms 10 ms 10 ms 192.168.1.1
2 5 ms 5 ms 5 ms 10.108.64.1
3 6 ms 8 ms 7 ms cr1ge1-2-130mtgmal.mtgm.al.charter.com [66.168.2
40.1]
4 12 ms 12 ms 12 ms 12.116.116.45
5 13 ms 15 ms 14 ms tbr1.attga.ip.att.net [12.122.85.150]
6 11 ms 13 ms 12 ms ggr2.attga.ip.att.net [12.122.81.97]
7 14 ms 11 ms 11 ms 192.205.33.90
8 12 ms 15 ms 12 ms atl-core-02.inet.qwest.net [205.171.21.101]
9 14 ms 14 ms 13 ms atl-edge-18.inet.qwest.net [205.171.21.166]
10 12 ms 12 ms 11 ms 63.144.1.6
11 15 ms 12 ms 12 ms 66.249.95.167
12 15 ms 15 ms 13 ms 72.14.239.21
13 20 ms 14 ms 13 ms 216.239.43.138
14 15 ms 14 ms 13 ms eo-in-f104.google.com [209.85.165.104]
Trace complete. |
|
RobotLegs
@wkpttv.com | we are having the same problem in tn. my tracerts at night are even worse than yours, going from 10 to 100 at the backbone switchoff.
there is a topic for north east tn latency problems that shows the same results you are having |
|
charter_hsd
VIP
join:2001-08-07
Calera, AL
| reply to pbarrow
said by pbarrow  :The problem is the higher responces times on some of the hop 5 traces. Latency should not be double and up to 5 times as high as the latency on the hop preceeding it, especially on a hop so close to you - hop 5 is only 2 hops away from Charter. hop 4 is in Montgomery I assume but certainly in Alabama since it's the point where Charter joins to ATT and then it goes to hop5 - Atlanta and on some traces (like googleand some others) the atlanta response is always 12 - 26ms or so and and on others (like yahoo and others) it's always higher. I think this is part of the speed problems I have but as is it explained below I could be wrong. pbarrow,
I do not believe the AT&T latency is affecting your speeds, and further more I believe I mis-interpreted the latency in the original trace routes you sent me.
I now believe that the original conclusion I came to is incorrect.
I'll explain exactly what I mean below. In the PM you posted above, I said the following:
said by charter_hsd :I say "if there is an issue" because AT&T could simply be giving ICMP a low priority under certain circumstances. This practice can result in an ICMP ECHO reply taking an unusually long amount of time to be processed and returned. This practice does not affect traffic that is routed through the router, it only affects traffic to the router. In my opinion this is probably not occurring. I say this because because the RTT to the network hops beyond AT&T will not be affected by this practice. However in both of our traces the hops beyond AT&T do appear to be affected. I now believe that my original assertion that hops beyond the AT&T network were affected by this issue is incorrect. I came to this new conclusion after I realized that regardless of how AT&T manipulates ICMP on their routers, routers on the west coast are going to show 60 - 80ms of latency simply because the packet is crossing the country.
For example, 365main.com is hosted in San Francisco. Below is a trace route to 365main.com:
traceroute to 365main.com (64.127.100.60), 64 hops max, 40 byte packets
1 .dhcp.leds.al.charter.com (removed for my security) 1.422 ms 1.019 ms 0.984 ms
2 ts1c5-0-0-10mtval.lds.al.charter.com (10.105.0.1) 7.554 ms 7.907 ms 7.984 ms
3 dr1ge9-19ledsal.leds.al.charter.com (24.196.0.117) 8.995 ms 9.618 ms 9.869 ms
4 er1ge3-1ledsal.leds.al.charter.com (71.91.53.53) 10.043 ms 17.973 ms 9.856 ms
5 12.118.120.9 (12.118.120.9) 13.448 ms 13.321 ms 14.338 ms
6 tbr2.attga.ip.att.net (12.123.20.182) 14.204 ms 14.699 ms 13.821 ms
7 ggr2.attga.ip.att.net (12.122.81.153) 52.205 ms 12.089 ms 12.224 ms
8 192.205.33.38 (192.205.33.38) 11.867 ms 13.538 ms 11.995 ms
9 so-0-0-0.mpr1.atl6.us.above.net (64.125.27.49) 12.925 ms 12.542 ms 13.456 ms
10 so-1-2-1.mpr4.iah1.us.above.net (64.125.29.62) 25.523 ms 27.746 ms 27.167 ms
11 so-0-0-0.mpr3.iah1.us.above.net (64.125.26.13) 45.654 ms 25.851 ms 39.740 ms
12 64.125.25.18.available.above.net (64.125.25.18) 58.360 ms 58.903 ms 58.113 ms
13 so-0-1-0.mpr2.sjc2.us.above.net (64.125.26.30) 66.378 ms 67.562 ms 68.518 ms
14 so-0-0-0.mpr1.sjc2.us.above.net (64.125.27.245) 70.057 ms 71.319 ms 68.234 ms
15 gw-gni.above.net (64.124.73.34) 67.818 ms 67.559 ms 68.344 ms
16 core-01.ge-5-14.sfo1.gni.com (64.127.96.34) 73.104 ms 74.605 ms 73.946 ms
17 vhost.gni.com (64.127.100.60) 76.578 ms 76.243 ms 73.515 ms
As you can see, the latency to the last hop is between 73 and 76ms.
The trace below is also to 365main.com, this time it is sourced from the Global Crossing Route server, which appears to be located on the West Coast.
Tracing the route to 365main.com (64.127.100.60)
1 ge4-1-0-226-1000M.ar4.PHX1.gblx.net (67.17.64.89) 4 msec 0 msec 0 msec
2 ge1-1-10G.ar1.SNV2.gblx.net (67.17.105.2) 16 msec 20 msec 16 msec
3 204.246.200.22 20 msec 20 msec 16 msec
4 core-01.ge-1-1.sfo1.gni.com (64.127.96.58) [AS 26914] 192 msec 20 msec 16 msec
5 vhost.gni.com (64.127.100.60) [AS 26914] 20 msec 20 msec 20 msec
20ms latency to the last hop makes sense because the source and destination are both on the West Coast and therefore they are geographical close to one another.
Finally, a trace from the Global Crossing Route Server on the West Coast back to my IP address.
Type escape sequence to abort.
Tracing the route to .dhcp.leds.al.charter.com (removed form my security)
1 ge4-1-0-226-1000M.ar4.PHX1.gblx.net (67.17.64.89) 0 msec 0 msec 4 msec
2 te7-1-10G.ar2.DCA3.gblx.net (67.17.109.34) 52 msec 52 msec 52 msec
3 192.205.33.33 56 msec 56 msec 52 msec
4 tbr1.wswdc.ip.att.net (12.122.80.98) [AS 7018] 76 msec 76 msec 72 msec
5 12.122.16.21 [AS 7018] 76 msec 72 msec 76 msec
6 cr1.attga.ip.att.net (12.122.1.173) [AS 7018] 72 msec 72 msec 72 msec
7 12.122.17.50 [AS 7018] 76 msec 72 msec 72 msec
8 gar5.attga.ip.att.net (12.123.20.177) [AS 7018] 248 msec 140 msec 204 msec
9 12.118.120.10 [AS 7018] 76 msec 76 msec 76 msec
10 dr1ge9-2ledsal.leds.al.charter.com (71.91.53.54) [AS 20115] 76 msec 76 msec 76 msec
11 ts0ge1-0-0mntval.leds.al.charter.com (24.196.0.118) [AS 20115] 76 msec 76 msec 76 msec
12 .dhcp.leds.al.charter.com (removed for my security) [AS 20115] 84 msec 84 msec 84 msec
As you can see on this trace, the last hop, which is my IP address, has a RTT of about 84ms. This makes sense because the route server and my PC are on opposite sides of the country.
I think these examples clearly illustrate my point that latency on cross county links will be "high" regardless of how the transit service provider treats ICMP traffic on it's network.
Even thought we no longer believe there is a problem on the AT&T network, we will continue to work with the AT&T NOC until they provide us with a reasonable explanation for the unusually high RTT to some of their routers.
My theory is that they are employing Control Plane Policing or other measures to give ICMP a low priority on some of their routers. (If this is the case, it's fine with us as long as they will confirm that is in fact what they are doing.)
As I get additional info I'll add it to this thread.
Regards. |
|
pbarrow
Premium
join:2003-09-16
Montgomery, AL
| I can only bow to your superior knowledge - however it seems to me that if ATT hop 5 was set to give low priority to ICMP then it would be that hop only that would show a higher latency and the following hops would have a lower latency. But if you look at my google trace all the latencies from hop 5 to the end are basically in the teens while the yahoo trace from hop 5 onward are in the 80's. This would seem to indicate to me that the hop 5 for yahoo has increased the latency to that level and thus it remains that or higher until ot gets to the end.
Am I incorrect? |
|
neofate
Caveat Depascor
Premium
join:2003-11-11
Birmingham, AL
| Once your latency hits X ms, it is going to, often, remain at that level through the rest of the routers. So you shouldn't 'expect' it to hit a spike at two or three routers then come back down to the teens the rest of the way.
This does happen, but generally because the ICMP traffic on the routers that (spike), are set to very low priority, then the proceeding routers are not set so low. So you get conflicting results.. When in actuality the routers are all sending and receiving the data at a similar rate.
I'm in B'ham, and I'm posting some traces from around the country to back up HSD's theory. My speeds are perfect at this time, and the distance factor should speak for itself.
To 365Main: (West Coast)
To LA (West Coast) :
To New York, far, but not as far:
Now, close, to Atlanta:
So I don't think using ICMP packets to troubleshoot your 'speed' problems is getting you very far. (Not trying to shoot you down),.. I know your frustrated, but I think it might be for naught.
Your speed issues in Montgomery could be related to routes, and equipment. But, I don't believe your traces are leading to the right conclusions.
How are your speeds , typically, from Morning to Night?
--
Life is not a problem to be solved, but a reality to be experienced. |
|
pbarrow
Premium
join:2003-09-16
Montgomery, AL
4 edits | This a rather typical day (lately) over the course of the day. As you will see - O get very erratic results on some of the same sites throughout the day with the mornings being best. The response times on my CMTS seem better than a couple weeks ago so that why I don't understhand the still erratic speeds in the evenings. Also look at the drastic differences in the visualware.com links. They are no where near as stable as the results you got in the other thread you posted in.
There does seem to be a little improvement at times.
====================================================
08/01/2007
9:00am cst
Ping statistics for 10.108.64.1:
Packets: Sent = 40, Received = 40, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 6ms, Maximum = 17ms, Average = 7ms
8/1/2007 9:00 AM CDT 10107 kb/s 953 kb/s 232 ms Atlanta, GA
»msiad.visualware.com/myspeed/db/···=6732272
2:25pm cst
Ping statistics for 10.108.64.1:
Packets: Sent = 41, Received = 41, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 16ms, Average = 7ms
8/1/2007 2:28 PM CDT 10343 kb/s 962 kb/s 177 ms Atlanta, GA
»msiad.visualware.com/myspeed/db/···=6734652
7:29pm cst
Ping statistics for 10.108.64.1:
Packets: Sent = 42, Received = 42, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 5ms, Maximum = 17ms, Average = 7ms
8/1/2007 7:31 PM CDT 6175 kb/s 951 kb/s 121 ms Atlanta, GA
8/1/2007 7:32 PM CDT 4772 kb/s 951 kb/s 193 ms Atlanta, GA
www.speakeasy.net atlanta
Download Speed: 8526 kbps (1065.8 KB/sec transfer rate)
Upload Speed: 972 kbps (121.5 KB/sec transfer rate)
speedtest.fdn.com atlanta 7:35pm
Download Speed: 8263 kbps (1032.9 KB/sec transfer rate)
Upload Speed: 972 kbps (121.5 KB/sec transfer rate)
speedtest.knology.net atlanta
Download Speed: 5089 kbps (636.1 KB/sec transfer rate)
Upload Speed: 974 kbps (121.8 KB/sec transfer rate)
»msiad.visualware.com/myspeed/db/···=6736824
»msord.visualware.com/myspeed/db/···=1792618
7:44pm cst
8/1/2007 7:44 PM CDT 10153 kb/s 964 kb/s 229 ms Hopkinsville, KY
8/1/2007 7:46 PM CDT 8277 kb/s 961 kb/s 156 ms Atlanta, GA
www.speakeasy.net atlanta 7:47pm
Download Speed: 10156 kbps (1269.5 KB/sec transfer rate)
Upload Speed: 976 kbps (122 KB/sec transfer rate)
miranda.ctd.anl.gov:7123
TCP/Web100 Network Diagnostic Tool v5.3.4e
running 10s outbound test (client to server) . . . . . 998.01Kb/s
running 10s inbound test (server to client) . . . . . . 7.79Mb/s
Your PC is connected to a Cable/DSL modem
Web100 reports the Round trip time = 87.06 msec; the Packet size = 1460 Bytes; and
There were 3 packets retransmitted, 85 duplicate acks received, and 86 SACK blocks received
The connection stalled 1 times due to packet loss
The connection was idle 0.29 seconds (2.9%) of the time
This connection is receiver limited 20.89% of the time.
This connection is network limited 79.08% of the time.
11:08pm cst
Ping statistics for 10.108.64.1:
Packets: Sent = 42, Received = 42, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 6ms, Maximum = 21ms, Average = 9ms
www.speakeasy.net atlanta
Download Speed: 7219 kbps (902.4 KB/sec transfer rate)
Upload Speed: 974 kbps (121.8 KB/sec transfer rate)
Download Speed: 4321 kbps (540.1 KB/sec transfer rate)
Upload Speed: 972 kbps (121.5 KB/sec transfer rate)
8/1/2007 11:11 PM CDT 6602 kb/s 963 kb/s 128 ms Atlanta, GA
8/1/2007 11:12 PM CDT 8821 kb/s 952 kb/s 189 ms Atlanta, GA
speedtest.fdn.com atlanta
Download Speed: 4844 kbps (605.5 KB/sec transfer rate)
Upload Speed: 972 kbps (121.5 KB/sec transfer rate)
»msiad.visualware.com/myspeed/db/···=6738020 |
|
charter_hsd
VIP
join:2001-08-07
Calera, AL
| reply to pbarrow
I think you are incorrect. It is more likely that the other AT&T routers on the Yahoo trace are all configured in a similar manner and thus they all give ICMP a low priority. This may result in the RTTs reported by all of the the routers along that route appearing abnormally high.*
Because of the long distances involved in cross country IP transport, by the time the AT&T network sends the packet to the next transit network on the way to Yahoo, the actual RTT has reached 60 - 80ms. Therefore the hops beyond the AT&T network appear to be affected by AT&T's ICMP manipulation, when in fact they are actually reporting accurate RTTs.
For example, based on the rDNS it appears that AT&T hands off to Yahoo in or near San Francisco. It is reasonable to expect 60 - 80ms of latency from Birmingham to Atlanta and then onto San Francisco. In fact, the first hop that resolves to Yahoo reports a RTT of 86ms.
Just for a minute, try to think about these traces without looking at the RTTs on the AT&T network.
In the case of Google, it appears that the server you traced to is geographically near Atlanta, thus the very low RTTs. The Yahoo server you traced to appears to be located in California, therefore we should expect to see "high" RTTs in the 70 - 90ms range.
In both cases the RTTs to the final destinations are appropriate for their geographical locations. The RTTs reported by the AT&T network are irrelevant if the RTTs reported by the final destination devices appear to be accurate. In both of the cases you cited here this appears to be the case.
I can understand why you would like to see low or slowly upward incriminating RTTs across the AT&T network. (Probably the most obvious reason is to aid in troubleshooting over utilized links.) Unfortunately, for whatever reason, this isn't the case and so far there doesn't appear to be much we can to change AT&T's behavior.
(* Technically speaking, the routers don't report the RTT. The RTT is actually calculated by the trace route program on the host PC. The routers can however, delay replying to the ICMP ECHO request, and thus cause the reply packet to take longer to be received by the host PC. The extra time spent by the host PC, waiting to receive the delayed reply, results in the RTT increasing.)
Regards. |
|
pbarrow
Premium
join:2003-09-16
Montgomery, AL
| ok - thanks - maybe you can look at the visualware.com graph links and test I posted and tell me what you think that indicates? Again - in the mornings the graphs are more consistent and in the evenings when my speeds tend to drop they get more erratic. And their explanation seems to maybe explan why around Christmas I had problem trying to listen to streaming christmas music and the last few days when I've watched some streaming Courttv trial coverage around 5:00pm I have to restart the stream periodically to keep it working. |
|
dav0r
translate
Premium
join:2003-06-15
Albertville, MN
 ·Charter Pipeline
·Embarq
| Lately that site has been giving me weird results, btw... that don't match other speed tests. I'd choose a couple speakeasy POPs and another solid test site to compare. Visualware either doesn't throttle, doesn't care, or something?
TRACERT is something that I don't fully understand and it's tricky to use for diagnosis for reasons already pointed out. I'd only be sure about it if the same thing happens with UDP or TCP packets to the same destination with something like PingPlotter... but UDP is weird with the no acknowledge thingy (or XBox Live would REALLY suck bal... I mean as... I mean be bad). ICMP sucks at some routers and will give you flaked out results. Trust the end result. If pings go up and stay up all the way to the end there may be an issue. If they go up in the middle then go back down disregard is the key from what I've been told.
I'm a FREAK about my latency as you may know. I've had at least 3 people tell me to FO about it when my issue was even worse than the one you're reporting. Unless it's kind of critical gamer-esque latency issues are considered a moot point. It sucks but that's reality. The best time to game is 10AM to 3PM. How wretched is that? "1st Shift Business Gamers FTW"  |
|
pbarrow
Premium
join:2003-09-16
Montgomery, AL | I do get the same results with PingPlotter |
|
neofate
Caveat Depascor
Premium
join:2003-11-11
Birmingham, AL
| said by pbarrow :I do get the same results with PingPlotter While I don't have access to EQA, I have seen it in use, and it does report a very simple to read report on the modem in question. One technician has reported your Upstream SNR has been below 22 'regularly'.. I would look into this.
If its flaking 21-22, then no big deal, but if its dropping 18,19,20,21,ish .. Then you could have your answer.
(Btw, this is something 'we' on our customer side, cannot detect)
Again, while all of us could be wrong, I'd put less priority on the routing right now.. as it isn't likely to get you very far.
You've posted so many times on the issue I can't recall , have you swapped out the modem recently, or had it changed?
--
Life is not a problem to be solved, but a reality to be experienced. |
|
pbarrow
Premium
join:2003-09-16
Montgomery, AL
| Thanks neofate. I have been trying to get the locals to look into the upstream SNR. I just emailed (again) tot he local Plant manager as I mentioned in another post and to my Corporate Escalation contact and the local Broadband manager concering the Upstream SNR dropping to 22db and below as I've been told by bbt and charter_HSD on occasions.
This is one of the problems ongoing for months and I don't know why they won't take care of it. If it's fluctuating around 22db you know at times it's bound to be a problem.
I'm expecting my Downstream power at 8db to become a problem when colder weather starts to come back and I can't put another splitter in because my Upstream power is already at 46db much of the time. |
|
dav0r
translate
Premium
join:2003-06-15
Albertville, MN | My down power is -7 I want it to start snowing! lol... |
|
charter_hsd
VIP
join:2001-08-07
Calera, AL
| reply to pbarrow
pbarrow,
Our local IP engineers were able to get a definitive answer from the AT&T NOC as to why we are seeing unusually high latency on some routes.
From the AT&T NOC: The two trace routes you have mentioned below take different routes on hop three. Due too different paths being taken, this will result in a different router being involved, in this case an Avici device. A customer may see "cosmetic latency" when sending ICMP traffic across these devices. This is due to the low priority of traces and ping being sent. Below I have attached an "official statement from the vendor".
Traceroute transmits packets with small TTL values. The Time To Live is an IP header field that is designed to prevent packets from running in loops. Every router that handles a packet subtracts one from the packet's TTL. When the TTL reaches zero, the packet has expired and is discarded and the router sends an ICMP Time Exceeded message back to the sender when this occurs. By using small TTL values, which quickly expire, traceroute causes routers along a packet's normal delivery path to generate these ICMP messages, which identify the router. A TTL value of one should produce a message from the first router; a TTL value of two generates a message from the second; etc.
We process TTL packets (in this instance, sending the Time Exceeded message back to the sender) in our software code 4.2.16 by processing them efficiently for only a small threshold of packets. However, if the threshold of TTL packets are large enough, the response time for the TTL will vary from a long response time to a * * * response time. Our software regards TTL packets differently from normal transit packets. Normal transit packets have higher preference than TTL packets and, thus, do not get impacted. The average latency for normal transit traffic through our modules has been verified at AT&T to be in the low microsecond range and leads the industry. Based on AT&T's response I think we can call this issue resolved.
Regards. |
|
pbarrow
Premium
join:2003-09-16
Montgomery, AL | Thanks for the reply and looking into it. |
|
