Discussion:
Reasonable Ping Delay for DSL?
(too old to reply)
W
2015-01-18 01:27:07 UTC
Permalink
For an ATT DSL line in a major metro area, what is considered a reasonable
range for the latency/ping speed as recorded on a performance site like
speedtest.com?

I'm assuming an average data center would target around 10 ms for ping. An
ATT DSL might be 20 ms to 40 ms?

I have an office location getting 131 ms, which suggests to us something has
really gotten messed up. This is testing from a notebook directly
connected to the Internet router, with the internal network disconnected.
--
W
W
2015-01-18 01:28:54 UTC
Permalink
Post by W
For an ATT DSL line in a major metro area, what is considered a reasonable
range for the latency/ping speed as recorded on a performance site like
speedtest.com?
It is speedtest.net.
--
W
Jeff Liebermann
2015-01-18 04:15:06 UTC
Permalink
Post by W
For an ATT DSL line in a major metro area, what is considered a reasonable
range for the latency/ping speed as recorded on a performance site like
speedtest.com?
I'm assuming an average data center would target around 10 ms for ping. An
ATT DSL might be 20 ms to 40 ms?
I have an office location getting 131 ms, which suggests to us something has
really gotten messed up. This is testing from a notebook directly
connected to the Internet router, with the internal network disconnected.
10-20 msec is considered "normal" for DSL.
<http://www.dslreports.com/faq/694>

130 msec is much too high. Before assigning the blame, it would be
helpful if you determined where the high latency is coming from. Since
you're using Ouchlook Express 6.0, it appears that you're on an old
Windoze system. Worms, viruses, and other traffic on the network can
really slow you down. You might want to run the same test with a
different computah as well as check for malware.

Next, run a traceroute to speedtest.net. Here's mine on a 1.5Mbit/sec
Cruzio DSL line (with some streaming pipe organ music gobbling about
128Kbits/sec in the background).
Post by W
C:\>tracert www.speedtest.net
1 1 ms <1 ms <1 ms DD-WRT [192.168.1.1]
2 19 ms 19 ms 19 ms dsl-63-249-85-gateway.static.cruzio.com [63.249.85.1]
3 20 ms 17 ms 16 ms 114.at-5-0-0.gw3.200p-sf.sonic.net [74.220.64.17]
4 18 ms 17 ms 17 ms 0.ae2.gw.200p-sf.sonic.net [70.36.211.53]
5 18 ms 18 ms 19 ms 0.xe-5-1-0.gw.equinix-sj.sonic.net [208.106.27.121]
6 19 ms 19 ms 19 ms core1.sjo.edgecastcdn.net [206.223.116.170]
7 21 ms 18 ms 18 ms 192.229.128.89
8 19 ms 21 ms 19 ms 72.21.92.82
Trace complete.
Note that almost all of the 20 msec latency is between my router and
Cruzio gateway. However, I've seen tests which show a substantial
delay between the computer and owners router caused by bad firmware,
bad cabling, bad ethernet switches, and malware.

It is also possible that the first few hops will look perfectly normal
(10-20 msec for DSL) but some downstream router is having a bad day,
resulting in a high end to end latency. That will appear in the
traceroute output as a big jump in latency. Not much you can do about
that except to find another online speed test. I suggest:
<http://speedof.me>
<http://testmy.net>
Oops. Remind me not to do a test with streaming music running:
<Loading Image...>

Incidentally, you can also run a reverse traceroute from various
internet servers back to your IP address:
<http://www.traceroute.org>
--
Jeff Liebermann ***@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
W
2015-01-18 05:53:22 UTC
Permalink
Post by Jeff Liebermann
Post by W
For an ATT DSL line in a major metro area, what is considered a reasonable
range for the latency/ping speed as recorded on a performance site like
speedtest.com?
I'm assuming an average data center would target around 10 ms for ping.
An
Post by Jeff Liebermann
Post by W
ATT DSL might be 20 ms to 40 ms?
I have an office location getting 131 ms, which suggests to us something has
really gotten messed up. This is testing from a notebook directly
connected to the Internet router, with the internal network disconnected.
10-20 msec is considered "normal" for DSL.
<http://www.dslreports.com/faq/694>
130 msec is much too high. Before assigning the blame, it would be
helpful if you determined where the high latency is coming from. Since
you're using Ouchlook Express 6.0, it appears that you're on an old
Windoze system. Worms, viruses, and other traffic on the network can
really slow you down. You might want to run the same test with a
different computah as well as check for malware.
As I said in original post, we disconnected the internal network and
attached a notebook to the Internet router. Time from the notebook to the
router is <1ms.

The 130 ms is between the DSL modem and the next ATT hop.

Another internet I have DSL on is 40 ms at that first hop, so better but not
good.

ATT shows good ATM signal when they trace that. What would be the likely
cause of such high latency, assuming it was on the DSL side of the network?

If ATM tests as good, I'm not sure what to ask ATT for. How do we find the
cause? One cause could be that they simply overloaded their ATM
aggregator, and then ATT will fall back on saying that they don't have any
quality of service agreement for latency. ATT Tech Support quite often
uses a ping tool to your router that does NOT report latency to the
technician. They then try to blow smoke at you and claim that "no packets
were lost, therefore there must be a problem." Not sure how I should be
fighting this battle and would appreciate insights.


One thing I have always wondered about is what does it mean when a
traceroute shows a low latency for a router in the middle? For example what
would this mean:

1 1 ms <1 ms <1 ms DD-WRT [192.168.1.1]
2 19 ms 19 ms 19 ms dsl-63-249-85-gateway.static.cruzio.com
[63.249.85.1]
3 20 ms 17 ms 16 ms 114.at-5-0-0.gw3.200p-sf.sonic.net
[74.220.64.17]
4 3 ms 2 ms 4 ms 0.ae2.gw.200p-sf.sonic.net [70.36.211.53]
5 19 ms 21 ms 19 ms 72.21.92.82

I thought that a traceroute to hop #4 would always be additive of the hops
that came before it?

Thanks for your input.
--
W
Jeff Liebermann
2015-01-18 06:54:28 UTC
Permalink
Post by W
As I said in original post,
You didn't reference your original post and I didn't see any previous
article. An article number or Google Groups link would be helpful if
you don't want to duplicate the original information.
Post by W
we disconnected the internal network and
attached a notebook to the Internet router. Time from the notebook to the
router is <1ms.
Ok, it's not the router. Try a different DSL modem perhaps?
Post by W
The 130 ms is between the DSL modem and the next ATT hop.
Humor me and post a traceroute (tracert in Windoze) result. Also,
what maker and model modem, and subscribed speed (1.5, 3.0, 6.0, or
U-verse)? Numbers are amazingly helpful.

Incidentally, if you really do have 130 msec latency, you should see
some problems with real time packets, such as VoIP. You might want to
try the VoIP test at:
<http://myspeed.visualware.com>
Select VoIP and G.711 when it asks. You should see a fairly awful MOS
score.
Post by W
Another internet I have DSL on is 40 ms at that first hop, so better but not
good.
This is beginning to sound like a DSL signal level/quality problem,
possibly a "disturber" in the cable bundle, such as a mess of other
DSL signals in the same bundle. (I'm guessing).

With the laptop connected to the DSL modem, login to the modem config
page and extract the SNR (signal to noise ratio) and line attenuation.
Compare with:
<http://www.dslreports.com/faq/16220>
A low SNR will produce latency as the modem will lose a fair number of
packets. You should see considerable CRC errors with a low SNR.

Here's mine from an Efficient/Siemens 4100 modem showing about 13
GBits transferred since the last power cycle:

To Modem To Internet
Max Allowed Speed (kbps) 1536 384
SN Margin (dB) 21.5 -
Line Attenuation (dB) 42.5 -
Loss of Signal 0 -
Loss of Frame 0 0
CRC Errors 317 2
Post by W
ATT shows good ATM signal when they trace that. What would be the likely
cause of such high latency, assuming it was on the DSL side of the network?
You can have a good signal level and still have tons of errors (and
packet loss) if there's interference on the line. It will show up on
your modem as good signal levels with lousy (low) SNR.

Ignoring your symptoms, a very large percentage of the troubleshooting
I've done turn out to be problems with inside wiring and badly
installed DSL filters. Do you have a "dry" line, or is it shared with
POTS service?

Move you DSL modem to the NID (network interface device) and plug
directly into the phone line, disconnecting all the internal wiring.
If the latency magically becomes normal, your problem is inside your
building, not with AT&T.

Incidentally, I recently helped a friend deal with a POTS and DSL
problem in his house. When I was done, I had replaced literally
everything except the NID and Siecor splitter. Rotten wires, cables
chewed by mice, bad punch down connections, shorts to ground, broken
instruments, unbalanced pairs, spade lugs falling off line blocks, and
most amazingly, a 50ft length of brand new CAT5e with a broken wire.
I've seen all of these before, but never in one house.
Post by W
If ATM tests as good, I'm not sure what to ask ATT for.
I would ask AT&T for what it will take to terminate the contract and
get a reputable DSL vendor.
Post by W
How do we find the cause?
You have to have practically a dead line before their support will
declare a problem. Worse, if you do complain about the line quality,
you'll either be forced to switch to U-verse, or get throttled by the
DSLAM to some lower speed, where the errors are less.
Post by W
One cause could be that they simply overloaded their ATM
aggregator, and then ATT will fall back on saying that they don't have any
quality of service agreement for latency.
True, but I haven't seen that personally. In general, if there's too
much traffic, there will always be some time of the day when it's
sufficiently clear to get decent latency and speeds. if you're
getting 130 msec at any random hour of the day, then it's probably not
traffic related. I have seen overloaded backhauls on RT's (remote
terminals). Again, the degree of overloading varies with the time of
day.
Post by W
ATT Tech Support quite often
uses a ping tool to your router that does NOT report latency to the
technician. They then try to blow smoke at you and claim that "no packets
were lost, therefore there must be a problem." Not sure how I should be
fighting this battle and would appreciate insights.
This is roughly what AT&T support sees:
<Loading Image...>
Yes, it's 10 years old, but little seems to have changed. Notice that
they only have access to the last few hours of operation.

What I used to do was plug in my Acterna(JDSI) HST-3000 DSL tester,
and run channel plots and other numbers. Something like this:
<http://dsl.11junk.com/slides/jeffl.html>
See the "ADSL Summary" section. I can tell quite a bit about what's
happening from the plots and numbers. However, it was stolen about 3
years ago, and I haven't bothered to replace it.

Besides the lousy latency, are you seeing any other problems?
Post by W
One thing I have always wondered about is what does it mean when a
traceroute shows a low latency for a router in the middle? For example what
1 1 ms <1 ms <1 ms DD-WRT [192.168.1.1]
2 19 ms 19 ms 19 ms dsl-63-249-85-gateway.static.cruzio.com [63.249.85.1]
3 20 ms 17 ms 16 ms 114.at-5-0-0.gw3.200p-sf.sonic.net [74.220.64.17]
4 3 ms 2 ms 4 ms 0.ae2.gw.200p-sf.sonic.net [70.36.211.53]
5 19 ms 21 ms 19 ms 72.21.92.82
I thought that a traceroute to hop #4 would always be additive of the hops
that came before it?
I have no idea. You obviously edited my results. The latency from
any router beyond your ISP's gateway router must be equal or greater
than the first hop (your router to your ISP's router). Lower
downstream latencies are impossible unless your ISP's gateway router
is dropping or delaying ICMP packets.
--
Jeff Liebermann ***@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
David Kaye
2015-01-18 08:23:13 UTC
Permalink
Post by Jeff Liebermann
Ok, it's not the router. Try a different DSL modem perhaps?
My first inclination is to suspect the AT&T POTS drop being corroded,
reflecting signal back, etc. I once had a customer where I went around and
around with an AT&T tech until she suggested that she DEcrease the speed.
It worked. No more dropped packets and delays went WAY down.




---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
W
2015-01-19 07:07:18 UTC
Permalink
Post by David Kaye
Post by Jeff Liebermann
Ok, it's not the router. Try a different DSL modem perhaps?
My first inclination is to suspect the AT&T POTS drop being corroded,
reflecting signal back, etc. I once had a customer where I went around and
around with an AT&T tech until she suggested that she DEcrease the speed.
It worked. No more dropped packets and delays went WAY down.
ATT has two profiles for a DSL line:

"Fast Profile" is used for connections up to 7500 feet from the DSLAM. It
is tuned for high signal to noise ratio.

"ILeave Profile" is used for connections > 7500 feet from the DSLAM. It is
tuned for higher noise ratio and therefore is slower but finds fewer errors.

When the 131 ms site was on the "ILeave Profile" it had latency of 500
ms!!!!! And speed was 700 Mbit download. I asked them to move it to the
Fast Profile and that got the 130 ms latency and 2.9 Mbit download speed.
This site previously had 5 to 6 Mbps downloads and latency < 40 ms.
--
W
David Kaye
2015-01-18 08:20:05 UTC
Permalink
Post by W
1 1 ms <1 ms <1 ms DD-WRT [192.168.1.1]
2 19 ms 19 ms 19 ms dsl-63-249-85-gateway.static.cruzio.com [63.249.85.1]
3 20 ms 17 ms 16 ms 114.at-5-0-0.gw3.200p-sf.sonic.net [74.220.64.17]
4 18 ms 17 ms 17 ms 0.ae2.gw.200p-sf.sonic.net [70.36.211.53]
5 18 ms 18 ms 19 ms 0.xe-5-1-0.gw.equinix-sj.sonic.net [208.106.27.121]
6 19 ms 19 ms 19 ms core1.sjo.edgecastcdn.net
[206.223.116.170]
7 21 ms 18 ms 18 ms 192.229.128.89
8 19 ms 21 ms 19 ms 72.21.92.82
Trace complete.
Interesting. Running my "Windoze" computer, XP to be exact into Comcast I
get faster throughput at every hop than you do. So much for the idea that
Windows is to blame... :)

Tracing route to cs62.adn.xicdn.net [72.21.92.82] over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.11.1
2 9 ms 10 ms 8 ms 50.161.66.1
3 19 ms 11 ms 9 ms te-4-6-ur01.sffolsom.ca.sfba.comcast.net
[162.15
1.30.181]
4 10 ms 11 ms 11 ms te-1-14-0-9-ar01.sfsutro.ca.sfba.comcast.net
[68
.87.194.70]
5 11 ms 11 ms 11 ms he-2-5-0-0-cr01.sanjose.ca.ibone.comcast.net
[68
.86.166.141]
6 13 ms 12 ms 11 ms
he-0-13-0-0-pe03.11greatoaks.ca.ibone.comcast.ne
t [68.86.83.134]
7 11 ms 14 ms 11 ms 173.167.57.194
8 11 ms 11 ms 11 ms 72.21.92.82

Trace complete.

C:\Documents and Settings\User>



---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com
Jeff Liebermann
2015-01-18 17:46:35 UTC
Permalink
On Sun, 18 Jan 2015 00:20:05 -0800, "David Kaye"
Post by David Kaye
Interesting. Running my "Windoze" computer, XP to be exact into Comcast I
get faster throughput at every hop than you do. So much for the idea that
Windows is to blame... :)
(...)
Post by David Kaye
8 11 ms 11 ms 11 ms 72.21.92.82
Trace complete.
Traceroute does not measure throughput (download speed). It measures
latency or the round trip time it takes for a packet to get to a
particular machine (usually a router) along the path. Very high
latency has no effect on download speed. For example, satellite
providers, with their >500 msec latency, work just fine at high speeds
(with jumbo packets).

Incidentally, the speed-o-light is 5.37 microseconds/mile. Therefore
a cross country ping of 2500 miles (SF to NY) will have a minimum
latency of 26.8 msec. I just pinged nyi.net and panix.com in New Yuck
and got latencies around 90 msec. The difference of about 68 msec is
in all the routers along the way, and my 19 msec DSL latency.
--
Jeff Liebermann ***@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
Loading...