Slashdot Mirror
Ask Slashdot: What Is an Acceptable Broadband Latency?
holmedog writes "A simple question with a lot of answers (I hope). I recently had issues with my DSL broadband at home, and after a month of no resolution, I was told 300ms latency (to their test servers) was the acceptable range for Centurylink 10.0Mbps. This got a shocked reaction out of me to say the least. I would think anything over 125ms to be in the unacceptable range. So, I have come to you to ask: What do you consider to be acceptable broadband latency and why?"
I used to work for AT&T Uverse and over 200ms was enough to get a tech onsite to look at the problem.
First pos... Dammit!
Maybe if you're coming from off-continent.
300ms is the typical latency of an analog modem.
Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
...of the broadband wars. All consumers really seem to care about is faster download speeds, so networks offer it - by munging up their network so much that latency is measured in seconds. With the death of the network engineer, people just aren't educated enough to realize that part of the whole broadband experience is getting your packets sent and received fast, not just your GET or retrieve request getting all the data it asked for quickly. If you have to wait more than a second or two for your requests to even get there, then most people are gonna give up and try somewhere else.
What are you using your connection for?
If you're sending emails, then 300 is perfectly fine.
Turn based games would be fine. Real time games would be rough.
We can't really tell you what's "acceptable". That ultimately depends on what you're using it for.
Maybe the right question is, are you getting a worse ratio-vs.-price situation than is found in most markets in your country?
Or are you asking whether or not the provided is in breach of the law because they're offering something so bad that their advertising is deceptive?
I can't see 300ms being acceptable anywhere in North America unless you are on a satellite link, however if you are testing over continents then yes.
Testing to the providers own test servers within the same country seems insane to be that high.
EA David Gardner -"... but the consumers have proven that actually what they want is fun."
If there isn't a perfectly linear tube filled(emptied?) with hard vacuum between their GBIC and my GBIC, providing the lowest possible roundtrip time(that fiber crap can slow your photons by 30-50%), the connection isn't good enough.
My 10Mbps cable gets 33/80ms at average/peak. A church I set up with 3Mbps DSL gets 60ms. My old satellite rig got about 500ms (less with modem uplink). Do they keep their test servers local, or does a tracert show a number of hops? 300ms is completely unacceptable for the first hop.
Just where exactly are these 'test servers' in relation to you? What, exactly, was this 'test'? This seems a bit of a worthless test. It's entirely possible your DSL has less than 100 ms latency, but the delay is on the server end or the links in between. This is too vague a scenario to comment on.
My feelings about 'acceptable' latency depend on how much I am paying for it, at what bandwidth, with what level of SLA, and for what purpose.
If you're connecting to the house next door, I would expect 25ms or under. If you're connecting to a tentacle porn henti site in Japan, latency can be upwards of 128ms. In other words, there is nothing magic about broadband that reduces the size of the world or gets around the speed of light limitations.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
When you say the word "latency" most tech-savvy folks think about the propagation speed of the technology (e.g. electricity in copper, or light in fiber), and thus assume it's basically proportional to distance.
However, latency comes from other things as well. Serialization delay adds latency, and the lower the symbol speed the more it adds. Multiaccess media adds latency while waiting to transit. Multiplexing anything adds a small amount of latency looking for a time slot.
The biggest culprit? Bufferbloat. This is a term that has been coined to describe the fact that many networking devices have entirely too much buffer. In the best case someone has sized the buffer for the max line rate that device may see (perhaps 25Mbps for your DSL modem, when your link is only 10Mbps), in the worst some misguided engineer thought "more == better" when figuring out how much to buffer, or just didn't care. There are a number of efforts to try and fix this poor situation, http://www.bufferbloat.net/ is the place to start. Basically buffers add latency. A small amount of buffering increases throughput, but beyond that it does nothing but increase latency and generally make the user experience crappy. When the link is full you need to drop packets _quickly_, because that's the signal to TCP to back off. Packet loss is a _good_ thing on a full link.
Try running ICSI's Netalyzr (http://netalyzr.icsi.berkeley.edu/) which will attempt to estimate your uplink and downlink buffering. If you have a "router" in front of your DSL modem it may have some tuning, or "QoS rate shaping" that will help. If it's a device provided by your service provider you may not have access to the settings, and it may simply be configured wrong. With some vendors asking for a different model of device may help, with others, you may be screwed.
The technologies involved should deliver 20ms latencies if properly configured. You should absolutely expect that, but getting them to acknowledge a problem may take latencies over 50ms. If your service provider thinks 300ms is normal, you need to escalate or move to a different provider.
Yup, I'd say 10ms is not uncommon for modern
The FCC Says:
Results by ISP. The highest average round-trip latency among ISPs
was 75 ms, while the lowest average latency was 14 ms.
This is from "Measuring Broadband America - FCC" found on the FCC website.
I just averaged together the data for a few thousand DSL circuits, and it seems that the average response time is in the area of 65 ms. Anything above 150ms is out of the ordinary. There are even a few CenturyLink circuits in there (reseller), and the average response time for those is a little higher, around 70 ms. Usually slow response times are because of an over-utilized circuit, but if that's not an issue here, then you should probably check the signal and margins on your modem or have CenturyLink send a tech to do so.
I do have a 10 Mbps DSL at home with the following ping time statistics:
First hop to ISP over DSL line in Finland: 22 ms
City 500 km away within the same ISP network: 33 ms
International connection to 10 hops and about 2500 km away: 50 ms
International connection over some European countries and over Atlantic to New York (~8000 km): 125 ms
Continuing journey from New York to Tokyo, Japan (lots of kilometers): 300 ms
How far is their test server anyway?
From
http://www.dslreports.com/faq/694
DSL/Cable 10-20ms
I would also think with those latency numbers you would have a hard time reaching 10Mbps. My guess is that you are a bit too far from the nearest POP which is cause attenuation in the line. Do a bandwidth test; see what the actual speeds are.
-- By all means let's be open-minded, but not so open-minded that our brains drop out.
I had a VPN customer on CenturyLink and a previous network engineer had put their home office LAN on 192.168.1.xxx (which is pretty common). The outlying offices were on 10.x.x.x subnets. One day, suddenly, no one could reach the home office file server. I discovered that there was a whole collection of computers with 192.168.1.xxx addresses on the WAN side of the routers. This, of course, broke the VPN links. He didn't just have them on that subnet but he had addressed one as 192.168.1.1 and up through a numerical sequence. When I finally got through to the chief admin guy (in Portland, OR) and told him he had internal IP addresses on a routable network he responded that the WAN side of our network was his INTERNAL network and he saw nothing wrong with putting a bunch of servers on those IP addresses. Nothing could convince him otherwise, either... because he was studying to take his Cisco Certified Network Administrator test.
We readdressed the home office (that was fun!) and then moved to a better provider; one who at least would listen.
No one ever had to evacuate a city because the solar panels broke!
He's spot on. The other question is how you're measuring the latency - lots of systems place a low priority on responding to pings, for instance.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
I had a client with a similar issue. Turned out there was a phone in the basement he had forgotten about and did not have a filter. Installed the filter and he got between 60 - 100ms to his default gateway where before it was 250+ ms
I would be interested in a few pieces of information before attempting to judge the latency. First, what is your distance from your DSLAM/SLICK/remote? If you are on a 10 meg connection on DSL (are you actually on ADSL or a different service?) then 300MS latency to pretty much anything should be a red flag. Are you testing on a clean machine? Malware can consume massive amounts of bandwidth silently. Can you isolate the network and test directly through the ADSL router/modem? Again, if this is actually ADSL, do you use the circuit for voice communications as well or is it only in place for broadband? Is the voice quality acceptable? If it is only in place for broadband, what are the noise margin readings and what is your attenuation? If you are on a clean network (no malware, one PC directly connected to router), with no malfunctioning hardware on your side, and testing directly to one of your provider's servers/routers, then a 300ms ping time would definitely constitute a problem (at least by the standards of the company for which I provide support) and would warrant a technician further investigating the trouble.
The first question I'd have about high latency numbers is how you're measuring them. Lots of devices are pretty slow about responding to pings and traceroutes. (Big routers, in particular, tend to make that a much lower priority than routing packets or doing other useful work, and the ping response comes from the CPU. while the actual packet routing happens in ASICs.) On the other hand, doing a traceroute to some distant site can let you see a bunch of dubious measurements, and the smallest numbers tell you a lot because they're a ceiling on the latency of everything up to that point. I've also seen throughput measurement tools that think sending 18000-byte pings is a good idea, and they're not only hopelessly broken for measuring throughput, they get really entertaining latency results as well. The quick and dirty test is "ping 8.8.8.8" followed by "traceroute 8.8.8.8", which points you to Google's anycasted DNS servers.
Traceroute also gives you some hints about routing - if you're in San Francisco, and your route to google.com is going by way of New York, something's weird with your ISP's peering. (I've seen that kind of thing happen - the user's ISP in Denver had recently moved, so their upstream link to the Tier 1 the user's headquarters used was down for a couple of months until they got a bigger access line built to the new site, and their ISP's other Tier 1 upstream didn't peer with the first Tier1 in Denver, and the San Francisco peering was overloaded back then so they were getting routed somewhere awkwardly far away.) But even so, it's really hard to burn more than an extra 120ms with bad routing unless you cross an ocean. (That's two extra round-trips across North America, or dancing around Europe; Asian users can occasionally get weird routes.)
The next thing to do is be sure you're really really not running anything else while running your latency tests. Jim Gettys's "Bufferbloat" paper is really insightful, and you need to read it (but don't measure your latency while you're downloading it :-) A typical latency problem is that you're trying to download more bandwidth than something on your access line can support (such as your wifi router), so the device buffers traffic, and what you're really seeing is that bittorrent or big http transfer is filling up your wifi to maximize throughput, which is trashing your latency. Or alternatively, you've got something hogging your upstream, making it difficult for ACKs on downstream traffic to get through.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks