Solved! Go to Solution.
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.
You can expect an average latency of between 600 and 700 ms with satellite internet, though it varies widely due to many factors.
To test latency, use the tracert command. EDIT: Trace routes to the servers of the sites you use (ex.: netflix.com; amazon.com, etc)
The Testmy.net latency test is completely unreliable, especially for statellite internet.
zenman wrote:
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 should I use? I'm in central Florida. How much latency should I expect on my Hughes connection?
For a chromebook, try this: https://www.howtogeek.com/170648/10-commands-included-in-chrome-oss-hidden-crosh-shell/
I think what you will need is a tracepath. There are instructions there on how to run it.
EDIT: instructions from another site:
How to Traceroute from a Chromebook
Example:
tracepath amazon.com
Post a screenshot of your results, please.
Like I said before, the average latency for satellite internet is between 600-700 ms. This may vary based on many factors.
Check my previous post. 🙂
Finally realized I needed to use the insertion tool here instead of copy/pasting! What a dingdong I am, trying to focus on too many things at once. So here's those tracepath results. One for Netflix and one for Google.
Are those the whole screenshots? They both look cut off at the bottom.
I think a firewall or something else may be blocking access for the tracepath. Something's not right, as most of those "no reply" lines should instead be filled with IP addresses and latency results.
Do you have a separate firewall device or firewall program that you're using? If so, it would be a good idea to disable it while running the tracepath, as it appears that something is blocking its ability to test anything outside of your own network.
I'm not at all familiar with Chromebooks, nor their OS, so I have no idea what else to try. 😞
I wonder if the "no reply" is similar to the *** of the Windows traceroute. I'd test this but my Chromebook is many miles away and I won't see it until 1/13.
EDIT:
See, like this:
1: 192.168.0.14 0.131ms pmtu 1500
1: no reply
2: dynamic-76-73-172-97.knology.net 119.110ms
3: 76-73-168-104.knology.net 97.118ms
4: xe-9-3-0.bar1.Cleveland1.Level3.net 102.568ms asymm 5
5: no reply
6: no reply
7: ae-104-3504.edge1.Washington12.Level3.net 135.317ms
8: att-level3-te.washingtondc12.Level3.net 102.696ms
9: cr1.wswdc.ip.att.net 101.485ms asymm 20
10: cr2.rlgnc.ip.att.net 102.262ms asymm 19
11: cr1.rlgnc.ip.att.net 193.578ms asymm 18
12: cr82.chlnc.ip.att.net 102.323ms asymm 17
13: 12.123.138.157 178.434ms asymm 16
14: 12.125.220.30 107.549ms asymm 17
@GabeU wrote:
I think a firewall or something else may be blocking access for the tracepath. Something's not right, as most of those "no reply" lines should instead be filled with IP addresses and latency results.
Do you have a separate firewall device or firewall program that you're using? If so, it would be a good idea to disable it while running the tracepath, as it appears that something is blocking its ability to test anything outside of your own network.
I'm not at all familiar with Chromebooks, nor their OS, so I have no idea what else to try. 😞
@maratsade wrote:I wonder if the "no reply" is similar to the *** of the Windows traceroute.
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.
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.
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:
So's Android.