cancel
Showing results for 
Search instead for 
Did you mean: 

Why does this work for latency?

Highlighted
Junior

Re: Why does this work for latency?


@lighthope1 wrote:


I don't know what nslookup does.

 


No matter, it was a brain fart, it's not going to help you from the public side.  Basically the NS stands for name server, so you can lookup the IP address associated a domain name, like "nslookup google.com" will give you the IP address for google.com.  You can get more advanced info and traverse different types of domain records and CNames, which can allow you to see the IP addresses assigned to specific resources...but you have to be on the private side of that network to do it.

 

Where it can be helpful is that very few resources like google.com are actually a single server, they are often clusters of servers sitting behind load balancers, so you can use nslookup to see the different IPs being used and know that different requests will get routed to different servers based on rules that can change very fast.  So I was trying to determine if spamming the domain address (with your WinMRT running) kept you resolving to the same IP address, while hitting it more slowly would occasionally send you to a different different IP address which would introduce latency.  

 

Basically, my hunch is that you are encountering some sort of race condition (an issue that depends on timing of potentially non-related things) when you see the higher latency, and it seems you hit it more often when your traffic is has bigger intervals, but where and why, I don't have a good answer for you, sorry.

Highlighted
Senior

Re: Why does this work for latency?

The offending hop seems to be at 63-235-42-186.dia.static.qwest.net.  That is the one that -- when it does return something -- is always 2K - 5K latency.

Highlighted
Distinguished Professor IV

Re: Why does this work for latency?


@lighthope1 wrote:

The offending hop seems to be at 63-235-42-186.dia.static.qwest.net.  That is the one that -- when it does return something -- is always 2K - 5K latency.


With their track record as of late, it's not surprising to see that the problem may lie with something connected to CenturyLink.  Smiley Sad 


Ryzen 5 3400G | MSI B450M Pro-M2 MAX | 16GB Corsair Vengeance DDR4 3000 | XPG SX8200 Pro 512GB NVMe | Windows 10 Pro
Highlighted
Junior

Re: Why does this work for latency?

And is that server only in the trace when you have high latency?
Highlighted
Senior

Re: Why does this work for latency?


@GabeU wrote:

@lighthope1 wrote:

The offending hop seems to be at 63-235-42-186.dia.static.qwest.net.  That is the one that -- when it does return something -- is always 2K - 5K latency.


With their track record as of late, it's not surprising to see that the problem may lie with something connected to CenturyLink.  Smiley Sad 


Yeah.  When I saw that, I knew it was never going to be fixed.  Can't even route around because the hop before it is another CenturyLink owned node.


 

Highlighted
Senior

Re: Why does this work for latency?


@Michael57 wrote:
And is that server only in the trace when you have high latency?

Yes.

 

I did a full day of testing yesterday.  No issues with latency as long as I ran WinMTR.

 

Once I stopped running it, the latency started to come back.

Highlighted
Associate Professor

Re: Why does this work for latency?

MTU is Maximum Transmission Unit, basically the largest packet size a receiving side will accept. It's possible that CL is dynamically (and incorrectly) dropping theirs depending upon loading patterns. Then they're either rejecting or just flat out dropping whole packets (likely, from what I've seen) waiting for a timeout/resend.


* Disclaimer: I am a HughesNet customer and not a HughesNet employee. All of my comments are my own and do not necessarily represent HughesNet in any way.
Highlighted
Senior

Re: Why does this work for latency?


@MarkJFine wrote:

MTU is Maximum Transmission Unit, basically the largest packet size a receiving side will accept. It's possible that CL is dynamically (and incorrectly) dropping theirs depending upon loading patterns. Then they're either rejecting or just flat out dropping whole packets (likely, from what I've seen) waiting for a timeout/resend.


Some node waiting for a timeout was my guess, too.  Just couldn't figure out why.

 

On a terrestial connection, it would happen so fast it would probably be unnoticable. But if it is timing out three or four times on satellite, that is monsterous.

 

Wish there was something that could be done about it.

Highlighted
Junior

Re: Why does this work for latency?

To me it's weird that when you run WinMTR you don't get routed through that node.

 

If it is MTU you can try lowering it or turning off Jumbo Frames if you have it on.  I'm not sure if the HN router lets you adjust MTU size or not, but your ethernet card probably does.

Highlighted
Senior

Re: Why does this work for latency?


@Michael57 wrote:

To me it's weird that when you run WinMTR you don't get routed through that node.

 

If it is MTU you can try lowering it or turning off Jumbo Frames if you have it on.  I'm not sure if the HN router lets you adjust MTU size or not, but your ethernet card probably does.


I do get routed through that node.  It just doesn't experience the slowdown when I use MTR.  I have absolutely no explanation for that.

 

I have Jumbo Frames disabled on my Ethernet card.