Best way to test latency?

This is why I asked to see the whole screenshot -- maybe it picks up again after the many "no reply" hops, like it happens sometime with Windows tracert.  Anyway, your idea's good.   (I would also restart the modem)

---

GabeU wrote:

---

 

---

It may be, but the fact that there are no results from anything outside of the network suggests that something is blocking those hops from being tested.

---

---

maratsade wrote:

(I would also restart the modem) 

---

Good idea.  

zenman 

Like maratsade just suggested, it would be a good idea to restart the modem just in case there is anything "stuck" with it.  To do so, it would first be best to shut down your Chromebook, then unplug the HughesNet modem at either the wall outlet or the power pack.  Then, after waiting for at least 30 seconds, plug the modem back in.  Then, after waiting for at least five minutes in order to ensure that the modem is fully ready, start your Chromebook and give the tracepath a try again to see if your results are any different. 

tracepath is weird. No idea what it's doing.

traceroute is what you should be using. If Chromebooks run on Android, which I think they do, I think you have to su to root run traceroute first. I just ran it in Terminal Emulator:

MarkJFine 

They run on Chrome OS.  It's a type of Linux, I believe.  

So's Android.

I don't believe you can run a traceroute on a Chromebook.  Their command interface runs a tracepath, but if you type traceroute or tracert, you get nothing, or you get an error (I haven't my Chromebook here to test).  Chromebooks run on Chrome OS (Linux kernel-based).

MarkJFine wrote:

tracepath is weird. No idea what it's doing.

traceroute is what you should be using. If Chromebooks run on Android, which I think they do, I think you have to su to root run traceroute first. I just ran it in Terminal Emulator:

 

---

I'm back. I didn't send the whole screen because it was just like 30 lines of no reply that ended with:

Too many hops: pmtu 1500

Resume: pmtu 1500

-- and then a new command line, so I screenshot what I thought was the relevant part at the top. Tracepath seems to be the correct command. Like everything else on a chromebook, the terminal is also via the browser, maybe that's why the difference. I have ublock and https everywhere on the browser, but turned them off. I have installed nothing extra in the way of firewalls on my chromebook or its browser (other than the things I mentioned, which were turned off) or on the Hughes HT2000W wifi router. The router is connected via cable to the Hughes dish outside, and that's all folks.

I shut down the chromebook and router and let them cool. I hooked into the router via ethernet cord and ran the test again, and was running on the chromebook's battery -- not plugged into a power source. Same results.

I tried tracepath on Android and got the same thing - couldn't get past the gateway to the internet, and multiple lines for the same hop. Anything past that was no reply, just like your's. There were some command switches that could be changed but I didn't bother with them too much. Chances are there's something to open up the wait period because the default timeout is likely too small.

Good you were able to test it.  

I wonder if there's a bug that needs to be reported to Google (they might fix it within the next 50 years or so). 

https://bugs.chromium.org/p/chromium/issues/list

I thought there might be some underlying commonality, but apparently I was wrong:
https://www.difference.wiki/android-os-vs-chrome-os/

ChromeOS is basically a browser and a hard disk for local temp space with everything else in the cloud... lol - not what you really want on this network.

That's right. It works just fine on HN, though, and there are some things you can have offline (like Google Drive and some apps).   

I've used Google apps. They do work ok, but the data usage is... ugh.

I normally use my Chromebook at work, but I've brought it home and found no increase in data usage.   EDIT:  It doesn't work like a phone at all. I think apps on phones can eat data if the settings aren't changed, but it doesn't work this way on the Chromebook.  You're basically on the Chrome browser.  No wifi, no data usage.  Apps that need syncing (Docs, Wunderlist) will sync once back online, but the data usage is the same as you would've used if you were using the app on the wifi. 

Understand. And that's true if what you're working on was locally held when you last turned it off, then trurned it on without wifi access. Supposed you'd have to be careful about turning the wifi back on to retrieve your work from the cloud, then turn it off again once you had it, then synched it back later. I'm more concerned about the constant thrashing it does if you don't turn the wifi off.

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?

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