Forum Discussion
Best way to test latency?
What is the best way to test my latency? Is the one on testmy.net a good, accurate one? It gives you locations to choose from for the test -- Miami, NY, Tokyo, google, amazon, etc. Which location shou...
Yes, 600-700 is normal for satellite internet.
Keep in mind that websites add to the delay because they have so much stuff on them that needs to load, such as images or videos. So on top of the normal server to server delay, you will have added delay from website content.
Found a video that said to use 'ping' as the command on a chromebook. It just keeps pinging until you stop it, here's the results. Looks like I'm getting mostly in the 650-700 ms range with sometimes wider variation. Is that normal?
Yes, 600-700 is normal for satellite internet.
Keep in mind that websites add to the delay because they have so much stuff on them that needs to load, such as images or videos. So on top of the normal server to server delay, you will have added delay from website content.
Thanks! I just ran it comparing wifi to ethernet cord.Virtually no pings above 700 with ethernet cord. Cutting out the wifi seems to shorten the delay by somewhere around 30-70 ms.
Is there any relationship between speed and latency? I ask because I'm wondering if checking latency is a shortcut way to check if you are having bandwidth/speed problems. Doing this test is so much quicker and easier than running a speed test on testmy.net, for instance.
I'd say yes, in the sense that latency is a time delay. So if you have more speed, the signal will span the distance between the points faster. With satellite, though, the distance is quite big, so there's always a minimum latency, which I think is no less than 532ms and has to do with physics, speed of light, etc. With terrestrial ISPs (say, cable), distances are much shorter, so latency is less.
As for the network speed, it will affect how you perceive the latency on websites, because that speed will impact how fast they load. So if your speed, as measured by testmy.net, is 40Mbps, the sites will load faster, but if it's 1Mbps, they will take longer.
I'm sure Mark can totally correct any mistakes in my answer and provide a better response.
zenman wrote:
Is there any relationship between speed and latency?
It's basically it. Aggregate speed to a website is different from a file transfer. It depends upon the number of components required to be individually downloaded (html, css, javascript, images), each of which has it's own additional latency if not asynchronously accessed. A single file transfer has only the initial latency to deal with so the impact on overall perceived speed isn't as noticable.
Places like testmy operate with a single file transfer when evaluating speed. I have no idea what they do to evaluate latency, but it seems that lag times appear to be over-exaggerated, indicating that they may be compounding in some instances.
Regarding ping: It only gives you an idea of overall latency to one destination point only, inclusive of the path it takes. It's kind of limiting as a diagnostic, because you have no idea where the problem is.
Traceroute tells you:
1. Latency through the gateway - what's only attributable to HughesNet - which is usually a 4-hop thing.
2. Who your gateway provider is - usually a source of high, erratic latency depending upon who it is.
3. The route the provider prescribed, how many hops it's taking, and which hops along that route have the biggest latency problems.
So it gives you a better indication of where problems may be.
Cheers, Sensei!
MarkJFine wrote:It's basically it. Aggregate speed to a website is different from a file transfer. It depends upon the number of components required to be individually downloaded (html, css, javascript, images), each of which has it's own additional latency if not asynchronously accessed. A single file transfer has only the initial latency to deal with so the impact on overall perceived speed isn't as noticable.
Places like testmy operate with a single file transfer when evaluating speed. I have no idea what they do to evaluate latency, but it seems that lag times appear to be over-exaggerated, indicating that they may be compounding in some instances.
Regarding ping: It only gives you an idea of overall latency to one destination point only, inclusive of the path it takes. It's kind of limiting as a diagnostic, because you have no idea where the problem is.
Traceroute tells you:
1. Latency through the gateway - what's only attributable to HughesNet - which is usually a 4-hop thing.
2. Who your gateway provider is - usually a source of high, erratic latency depending upon who it is.
3. The route the provider prescribed, how many hops it's taking, and which hops along that route have the biggest latency problems.
So it gives you a better indication of where problems may be.
My initial tracepath attempts were for netflix and google, which didn't work. I decided to try again with amazon.com, and it seemed to work -- screenshot is below. I have no idea how to read the information.
How do I read the latency in Hughes's piece of the chain, and what's a normal value for the their piece? What would be an unacceptably high value for their piece? There are times (not right now) when even simple browsing for me on Hughes seems very slow. Or maybe more accurately, it seems erratic. One minute it's doing well, a minute later it's crawling, then suddenly it's better again -- but when I check mbps, it's reasonable.
The other variable besides mbps that I'm aware of is latency, so I just want to be able to diagnose when I'm getting slow performance by also checking latency. Or more specifically Hughes's latency, since that's the piece of the chain I'm paying for.
The latency for the satellite internet is between 600-700ms on average, regardless of how much you pay for it.
Focusing on the latency for HN makes no sense, as the majority of your delays are caused outside of HN, by internet backbone providers (CenturyLink), and by the websites themselves. HN has no control over that.
Sounds like you're saying that if my latency is high, the odds of it being a problem with Hughes is very tiny? Are there any other variables? I know there are variables on my end, I mean otherwise. I know that periods of high traffic can affect performance, but I assume that's reflected in the mbps number when I do a download test.
"Sounds like you're saying that if my latency is high, the odds of it being a problem with Hughes is very tiny?"
Yes.
"Are there any other variables? I know there are variables on my end, I mean otherwise."
Yes. As the website indicates, your mileage may vary depending on
- the configuration of your computer
- the number of concurrent users
- network or Internet congestion
- the capabilities and content of the websites you are accessing
- network management practices as deemed necessary
- Other factors
and I get it, 600-700 is normal latency for sat and there's no way around that. I'm just looking to diagnose or understand why I sometimes experience slow or erratic performance, and yet my mbps download speeds are the same as when the performance is normal. So I wanted to figure out how to check latency the next time it happens, to see if that explains it.
No way around the laws of physics, so the latency can't be changed. When you experience slowdowns they're likely related to the other causes on the list, all of them things you have basically no control over.
What do you do when you experience slowdowns? Do you ever try to reboot your modem? That's a strategy that sometimes helps.
How to read:
The number at the left is the hop number.Hop 1 is 192.168.42.1, your modem.
Hops 2 and 3 are the HughesNet path to the gateway (thought there should be another one somewhere).
Hop 4 is Qwest (now owned by CenturyLink), your gateway provider.
Use 525mS as an easy to remember guide, because the radio path takes that much time to go to from you to the satellite, down to the groundstation, and then the return trip back to you.
These are all showing about 1-1.5 seconds more than that, which sounds to me like either a network compatibility problem or simple network congestion (congestion being too many users, causing a processing/routing backlog). CenturyLink is well-known for sporadic 1-minute gaps in service, not 1 second, so it's not the provider.
It could feasibly be peak time congestion, but it'd have to be pretty congested and I'd have to see what one of these looks like during a non-congested period. If it's that high (readings of 1500-2000mS) during non-peak time, then it's not congestion, it's a network compatibility issue.
But again, I don't know what tracepath is actually doing. I'm working from the assumption that it's something similar to traceroute and I might be wrong.
MarkjFine, So one doesn't add up the ms values on each hop to determine one's total round-trip latency? But rather, the ms value at far right on each of those lines (i.e. 1471.185ms on the third hop 3 line) reperesents a total round trip latency?
When I do a ping command, I get ms numbers on the right of each line in the 600-900 range, which seems more expected. Does that indicate that those 1-1.5 sec. values on each line after a tracepath command are probably not accurate? Or is the ping command not accurate?
When you talk of the possibility of a network compatibility problem, what networks are you talking about? I'm a guy in central florida using my Hughes service to ping amazon.com, why would any of the networks used to execute that very common route for me have incompatibility issues?
Each one on the right is basically a ping from you to that hop's location. It does three to each one so you can get an idea of the variance. In a traceroute, all three are on one line, but these have each on a separate line.
As I said, I don't exactly know what your tracepath is doing. If you can ping to any of those hop locations manually and get lower values, then there's something wrong with tracepath.
Lots of things can cause incompatibilities - packet size, MTU, what the network expects to see versus what you're generating... and when I say 'the network' I mean your local LAN (basically your Chromebook, since that's the only thing on it) versus what HugheNet's WAN expects (everything between the modem and the groundstation), versus what the groundstation's provider (Qwest) and the overall internet expects.
There are basically three different segments I'm grouping into the greater network here - which is why I keep saying knowing what's going on at each node in that chain is important. But if tracepath is broken and you have no access to a working traceroute, then it's just going to give you bad data.
MarkjFine, you said, "If you can ping to any of those hop locations manually," don't know for sure if this is what you mean, but I tried this:
My second hop was host977219357.direpc.com. I tried a ping command to that, then I tried 977219357direpc.com, and finally I tried just direpc.com. All three returned with 'name or service not known.' I also tried a tracepath command with all three of those, same result.
I guess my first problem is nobody in the conversation knows for certain how to do a traceroute with a chromebook. What I found via googling is that tracepath is how you do a traceroute on a chromebook, but I have no expertise to know if that's right, and applies to what we are using it for.
"I guess my first problem is nobody in the conversation knows for certain how to do a traceroute with a chromebook. "
You were told how to run a tracepath on a Chromebook. So yes, we know how to do it; but it's not our fault if the tracepath command may be buggy. That's for Google to fix.
It may require superuser access on a Chromebook to run traceroute.
Did you try typing "su" then hitting return before running traceroute, like I said way back?
I tired typed 'su' and it returned as 'unkown command."
Because su is not a Crosh command.
what about 'sudo traceroute'
No, not a Crosh command. Here's a list of commands for Crosh.
EDIT: while many Linux commands work, including sudo, it doesn't work with tracepath. And there's no tracert or traceroute command for Crosh that I know of. It's just tracepath (EDIT 2: poor, wonky, maligned, possibly buggy, tracepath).
What about:
1. Exiting the Crosh shell first using 'exit',
2. Switching to a bash shell using 'shell',
3. Then doing 'sudo traceroute'. -> might want to try just 'traceroute' first.
He should definitely try that. I'll test all this when I'm back at the firm and can get to the Chromebook. (Edit: though I thougth a bash shell is for running scripts....dunno, never used this on the Chromebook)
Nice page... bookmarked.
Incidentally, look at the ftp definition of 'hash'... crafty little buggers.
