Free Allegiance Forums

Bufferbloat is the enemy of every gamer. Here's how to reduce it.


goto www.dslreports.com and run their speedtest. Select cable as your provider. Do the test a couple of times and make note of your bufferbloat.

Open a command prompt as administrator. If you don't know how to do that, google it.

type in "netsh int tcp set global autotuninglevel=disabled" (without the quotes) and hit enter. Then REBOOT.

Run the speedtest again and see if your bufferbloat improved.

To change back , simply replace "disabled" with "enabled"

Because playing around with TCP auto tuning helps fixing UDP problems...

pkk wrote:QUOTE (pkk @ Jul 1 2016, 05:56 PM) Because playing around with TCP auto tuning helps fixing UDP problems...

who said anything about udp problems?

Wasp wrote:QUOTE (Wasp @ Jul 1 2016, 06:32 PM) Bufferbloat is the enemy of every gamer. Here's how to reduce it.


goto www.dslreports.com and run their speedtest. Select cable as your provider. Do the test a couple of times and make note of your bufferbloat.

Open a command prompt as administrator. If you don't know how to do that, google it.

type in "netsh int tcp set global autotuninglevel=disabled" (without the quotes) and hit enter. Then REBOOT.

Run the speedtest again and see if your bufferbloat improved.

To change back , simply replace "disabled" with "enabled"

Yeah, I did all this protocol... with sg tcp too, but still got ping issues.
Checked all connection here, its all good. It seems the problem is with this virginia server, on nuremberg mach3 i got no ping issues.
Nuremberg is very far from here, virginia no. So whats wrong with this server?
Virginia: lag 123; ping:0 to 240!!
Nuremberg: lag 243; ping: 0 to 5 (normal).
Can someone help me? thanks.

the lag you're experiencing on the USA server is likely do to a hop between you and the server.

To check connections along the way, open a command prompt and type in "tracert 52.22.100.172" (without the quotes).

If you see any * along the way, that is the hop that is giving you trouble.

Wasp wrote:QUOTE (Wasp @ Jul 4 2016, 12:07 AM) If you see any * along the way, that is the hop that is giving you trouble.

Or that machine isn't responding to ICMP or using a broken route which doesn't effect the end to end connection...

Most people using tools wrong to diagnose network problems.

I tried that and got 9...yes 9 " * * * request timed out".

Nine out of 19 hops timed out.......the Internet sucks. (Or PKK is correct)

PKK is just trying to be argumentative.

If you see * along the way, check it on another day and compare. Yes some machines don't respond to ping, but that's not to be construed as bad if hops beyond that are functioning.

The hop with the first * is suspect. If you see a ping returned on that same hop that has an * such as: 43 * 87 , then you can bet that hop has trouble.

In my case, a tracert to the server shows 7 hops that don't return pings. They are hops 8, 9, 13-17. All the hops in between show equally low times and the server returns a ping of 25ms.

IF a hop was giving me trouble, the ping times would likely be increasing along the way or not being returned at all, even at the server.

My point is; don't be so quick to blame the server, it's more than likely a network issue.

Wasp wrote:QUOTE (Wasp @ Jul 4 2016, 02:43 PM) In my case, a tracert to the server shows 7 hops that don't return pings. They are hops 8, 9, 13-17. All the hops in between show equally low times and the server returns a ping of 25ms.

Every hope uses it's own routing table, that's why they sometimes return faster/slower. Some don't even respond to ping requests or don't have a route to reach the source.

The more hops you have, the more odd the results can be, because every hop can have a different return path.



There is no "one way" your packets travel over the internet (interconnected networks).

In the end only the connection between endpoints are important, not the individual return paths of each hop/router.

If there is a huge delay or packet drop, starting at one hop and is running until the end (destination), then you might blame that hop (or the one in front) causing the problems. Otherwise, don't give a @#(!.

pkk wrote:QUOTE (pkk @ Jul 4 2016, 12:34 PM) ...If there is a huge delay or packet drop, starting at one hop and is running until the end (destination), then you might blame that hop (or the one in front) causing the problems....

Isn't that what they're experiencing? Huge delays and packet drops?

Is it just a coincidence that when this very issue arises that the hops in between show it?...and when the problem disappears, those hops reflect it?

This has been my experience over the years and I check that connection regularly.