cancel
Showing results for 
Search instead for 
Did you mean: 

Why does this work for latency?

Highlighted
Senior

Why does this work for latency?

On EchoStar 19, beam 5.

 

Had impossible latency spikes. Wildly swinging between 700ms and 44000ms. Latency swings are by the second.

 

Unable to determine source of latency. Could be HughesNet or could be CenturyLink. There is one hop that returns No Response From Host, but every once in a while will return an address.  I can't remember what it is, but it is a qwest domain.  When it does return, the ping time is something like 4000ms or so.

 

What is strange is that, if I run a program called WinMTR and put into it the destination IP, the latency disappears for the most part.  It still will rear its ugly head, but only on occassion.  Without running that, latency is almost always there.

 

For those who do not know, WinMTR will continuously run a traceroute or some such every second, testing the ping from each hop.

 

If I run it with an interval > 1 second, the latency returns.

 

Very strange, and I can't figure out why this works.

 

It is imperfect.  Latency still crawls in there, but at least it is something.

20 REPLIES 20
Highlighted
Sophomore

Re: Why does this work for latency?

It can be hard to say.  The most likely scenario is usually the simplest, so it is most likely where your trace is showing it.  The thing is, TCPIP is a self clocking protocol, and there's a bit of handshaking and acknowledging that goes, so when you a spamming with WinMTR you can be generating what appears to be "fast" traffic and lower latency, which is likley why when you slow the intervals down you get different results.  Note: I don't know too much about WinMTR, so I'm just guessing that's what it is doing based on your post.

 

We do a lot of work with throttle proxies (we wrote a custom one, but Charles is sufficient for most purposes) that basically allows you to limit your bandwidth or add latency so you can simulate various scenarios.  It's super helpful when you want to see the way various traffic or URLs are being routed and prioritized, what bandwidth limits are, and how latency maniftests itself on your traffic.  Latency is notoriously weird

 

I bet if you add latency on your end, you'll make the upstream latency more obvious, (which is sort of what you are seeing when youslow your intervals).

Highlighted
Senior

Re: Why does this work for latency?


@Michael57 wrote:

It can be hard to say.  The most likely scenario is usually the simplest, so it is most likely where your trace is showing it.  The thing is, TCPIP is a self clocking protocol, and there's a bit of handshaking and acknowledging that goes, so when you a spamming with WinMTR you can be generating what appears to be "fast" traffic and lower latency, which is likley why when you slow the intervals down you get different results.  Note: I don't know too much about WinMTR, so I'm just guessing that's what it is doing based on your post.


Ah, I left out an important detail.

 

I am running a second program while I am running WinMTR.  It is with the SECOND program that I am seeing the latency improvement.

 

For example:

 

I run a game called World of Warcraft.

 

Without WinMTR running, I get latency from 2000 to 5000ms.

 

With WinMTR running, I get latency from 900 to 1300ms. (With occassional spikes)

 

Odd, huh?

Highlighted
Sophomore

Re: Why does this work for latency?

Oh wow (pun intended), I played World of Warcraft when it first came out through like the 3rd expansion.  That actually makes it a bit more complex, because we don't know if both sets of traffic are following the same prioritization.  If deep packet inspection is happening, they likely are not prioritized the same, but if it's just based on the destination then assuming WinMTR is hitting the same destination, it would be probably the same.

 

Still, I don't really have an explanation for you, other than guesses like the MTR traffic is keeping you cached or hot in some way, though that's not typical behavior...Can you see the difference in gameplay?  I ask that because it could also be false reporting.

 

 

Highlighted
Senior

Re: Why does this work for latency?


@Michael57 wrote:

Can you see the difference in gameplay?  I ask that because it could also be false reporting.

 


Yes.  There is clearly a difference.  Actions don't take as much time.  Plus there is a monitor in game so you can see your latency.  Latency is absolutely higher when WinMTR is not running.

Highlighted
Associate Professor

Re: Why does this work for latency?

It's possible this all points to an erratic MTU issue somewhere.


* 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
Sophomore

Re: Why does this work for latency?

Yeah, I remember that there was an in game monitor, but I was hoping maybe it was being fooled by something, but if you can see the effects in the game, then it's likely legit. 

 

If you do nslookup, to the same WoW servers every couple seconds versus spamming it via a script, do you get different IPs?  I'm reaching here, but maybe this could highlight if caching or some sort of sticky load balancing was happening.  The challenge is you'd think that WoW traffic would be enough for you to benefity from any of those behaviors, it shouldn't take that additional trace traffic to push it over some threshold.

Highlighted
Senior

Re: Why does this work for latency?


@MarkJFine wrote:

It's possible this all points to an erratic MTU issue somewhere.


I don't know what that means.

 

Highlighted
Senior

Re: Why does this work for latency?


@Michael57 wrote:

Yeah, I remember that there was an in game monitor, but I was hoping maybe it was being fooled by something, but if you can see the effects in the game, then it's likely legit. 

 

If you do nslookup, to the same WoW servers every couple seconds versus spamming it via a script, do you get different IPs?  I'm reaching here, but maybe this could highlight if caching or some sort of sticky load balancing was happening.  The challenge is you'd think that WoW traffic would be enough for you to benefity from any of those behaviors, it shouldn't take that additional trace traffic to push it over some threshold.


I don't know what nslookup does.

 

I haven't tested this with any other game yet.  I plan to see if it has any affect on Guild Wars 2, since that has an in-game latency monitor as well.  It will be interesting to see the results.

Highlighted
Senior

Re: Why does this work for latency?

It seems to work in Guild Wars 2 as well, but I've only been able to test it once.

 

It's a bit harder to test in there.  I'll keep trying over a couple days and see what I come up with.