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!
...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.
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.
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 consider anything past 80ms to be slow for my cable connection (to 8.8.8.8).
I just tested 19,17,18,18
I previous test had a 60 something thrown in. This is via a boring home VPN router, shared connection, but under a dozen, and all light users.
13 hops to 8.8.8.8 from here.
33,34,33,63 to /.
300 is what I get on hotel wifi, or my cellphone (to be fair, on my cell phone it goes up to 1000), as can hotel wifi become unusable, I swear most hotels must have 300+ rooms sharing a T1 line.
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
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.
Generally 1ms or less.
Pinging one of my servers in co-lo on the other side of London and traversing my moderate-speed (~4Mbps/1Mbps) ASDL only takes just over 14ms round-trip.
Pinging my server in the US gives ~110ms.
Singapore: ~270ms.
Sydney, Australia: ~310ms.
So I can get right round the globe and back in about 300ms, *starting* the trip over ADSL.
Rgds
Damon
Rgds
Damon
http://m.earth.org.uk/
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
Pinging DamonHD [794830] with 32 bytes of data:
Rgds
Damon
Rgds
Damon
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