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"
BufferBloat
Because playing around with TCP auto tuning helps fixing UDP problems... 
Last edited by pkk on Fri Jul 01, 2016 10:00 pm, edited 1 time in total.
The Escapist (Justin Emerson) @ Dec 21 2010, 02:33 PM:
The history of open-source Allegiance is paved with the bodies of dead code branches, forum flame wars, and personal vendettas. But a community remains because people still love the game.
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.
im back again...
Or that machine isn't responding to ICMP or using a broken route which doesn't effect the end to end connection...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.
Most people using tools wrong to diagnose network problems.
The Escapist (Justin Emerson) @ Dec 21 2010, 02:33 PM:
The history of open-source Allegiance is paved with the bodies of dead code branches, forum flame wars, and personal vendettas. But a community remains because people still love the game.
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)
Nine out of 19 hops timed out.......the Internet sucks. (Or PKK is correct)
Last edited by raumvogel on Mon Jul 04, 2016 6:44 am, edited 1 time in total.
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.
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.
Last edited by Wasp on Mon Jul 04, 2016 1:10 pm, edited 1 time in total.
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.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.
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 @#(!.
The Escapist (Justin Emerson) @ Dec 21 2010, 02:33 PM:
The history of open-source Allegiance is paved with the bodies of dead code branches, forum flame wars, and personal vendettas. But a community remains because people still love the game.
Isn't that what they're experiencing? Huge delays and packet drops?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....
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.