Good morning folks,
Just received an update that the network adjustments to address this concern have been implemented. Please let me know if the intermittent connectivity persists for you today.
WooHoo!
After at least 2 full months of poor service, and after forking out $125 to have my radio replaced and then replacing the modem and then the problem remaining just as bad as ever for several days ever since, just a few minutes ago my app that tracks success rates on PING messages started registering 100% success all the time! Somebody somewhere fixed something for sure. I suspect one of those engineers did something at the gateway that really made a difference.
Well now I am really confused. It turns out that my PING messages only enjoy a 100% success rate if I connect my Belkin WiFi router to the Ethernet circuit. Even though the computer itself is still connected by Ethernet (and not wirelessly) to the router, the router is doing something that causes the 100% PING success rate that I do not get when the computer is connected directly to the modem by Ethernet cable without the router involved at all. Perhaps the router provides a layer of retransmission protocol that covers up the dropped PING messages. Or perhaps the router is providing better Ethernet drivers or transmission cable terminations, thereby improving the success rate between my computer and the modem. In any case, I think I shall stop blaming HughesNet for my low PING message success rates, and I shall keep my router connected unless I need to remove it for a test.
I will still be monitoring for the long dropouts of HughesNet service. I have been gathering some information about timing that may help the engineers. Assuming the long dropouts continue, I will be back with that information soon.
Lets look at what a "ping" is:
It is a request for a response from your local computer or device to a specified server somewhere in the world that is connected to the Internet.
That is usualy a more or less straight forward thing when using a ground based ISP.
Path: yours to theirs:
Looks like this:
Simple isn't it. Your ISP is connected to the Internet backbone at its "head-end" and then your ping is routed through a number of routing switches to finally reach the desired server that responds. when it can depending on its load.
That constitutes a "loop". Lets call this Loop #3.
Lets look a little deeper:
Your connect wirelessly to your Router ... that connection is all "local" .... that is a "loop". Lets call this Loop #1. Loop #1 is all on the user end.
Your router router passes the info to the Hughes Modem
The Modem also has a loop. Modem>Satellite>Gateway>Headend. Lets call this Loop #2. Loop #2 is all on the Hughes end.
Your data then is passed onto Loop #3 ... the Real Internet.
You have total control of Loop #1 .... wireless with the exception of perhaps the wireless portion of a HT2000w
Loop #2 is totally Hughes.
Loop #3 is not under Hughes control.
The sever you task with a request for a responce is beyond Hughes's control.
You have to break things down to determine just where the issue is.
The Hughes Modem offer a Gateway Continuity test with the SCC at 192.168.0.1
This is a test of Loop #2 ... the one that has control of.
(Amanda and Liz may find the latter part of this of interest as well.)
In working on a reply to your post, I discovered something very important. I will get to that in a moment.
First, let me point out that during these tests, at no time have I used the wireless WiFi facilities of the Belkin router. I normally connect the router only so that we have WiFi access via a Samsung tablet elsewhere in the house. All of my PING tests run on my PC which is hard wired via an Ethernet cable to either the router or directly to the satellite modem, depending on the scenario being tested.
I would suggest that there are, in fact, 3 loops when my PC is connected directly to the modem and 4 loops when the PC is connected to the router which is then connected to the modem.
What I found hard to understand was that there are far fewer, if any, dropped PING messages when the router is added to the scenario. Therefore, I was postulating that perhaps there is something about the electrical connection between my PC and the satellite modem that is aided by having the router in between them.
While writing this reply, I thought more about that and performed a PING test between the PC and the satellite modem itself with them being directly connected via an Ethernet cable. Then the scenario contains only 1 loop.
To perform this test, I typed the following statement into a command box:
PING /n 1000 192.168.0.1
Of the 1000 PING messages sent, 37% were dropped, a really poor result for a direct hard wired Ethernet connection. More than a third of all PING messages couldn't even make the round trip just across the Ethernet cable to the satellite modem and back to the PC. By the way, the longest round trip time of those messages that did make the round trip successfully was 1 millisecond.
Then I repeated the test with the router in the circuit. This constituted a 2 loop test.
This time, 0% of the PING messages were dropped. Every PING message from the PC made the full round trip. However, while the average round trip time was still 1 millisecond, the maximum round trip time was 40 milliseconds. Some further testing showed that only 1.3% of the PING messages are ever taking longer than 1 millisecond in this 2 loop test.
So while it is desireable to remove my router to eliminate it as a source of problems when troubleshooting some issues, I find that my apparent overall performance is improved by having the router between my PC and the satelllite modem, even when I am not using the WiFi functionality the router provides.
I am already well aware that there is a connectivity test available for testing the link between the satellite modem and the gateway but that does not test the communications in a way that truly emulates normal traffic timing such as takes place during a PING test. It would be desireable to know the IP address of the server at the gateway which is serving my communication channel. It would be valuable to me to be able to perform PING tests between my PC and that gateway server, thereby eliminating the internet itself as a source of issues. Is there any chance I can get the IP address of that gateway server? Where would I look for it?
