• Log InLog In
• Register

Reduce ur latency on bnet and all other games

Post a Reply

no.1 516 Posts February 13 2008 01:13 GMT #1 MOD EDIT: Sorry, R!CH says this sucks, and I like him better.

ShaLLoW[baY] Canada12499 Posts February 13 2008 01:17 GMT #2 Can anyone confirm/deny that this is good?

no.1 516 Posts February 13 2008 01:20 GMT #3 just read the sources

skindzer Chile5114 Posts February 13 2008 01:30 GMT #4 Side effects?

ulszz Jamaica1787 Posts February 13 2008 01:35 GMT #5 I've used this and it greatly helped my ping in WoW. I was normally geting 250-300 ms but after this I consistently have 100-150. I've heard that it may affect torrent downloads, but mine seem to be the same as before I did this.

LumberJack United States3355 Posts February 13 2008 01:44 GMT #6 ill wait till one of our techies reads this and signs off on it.

werd 19 Posts February 13 2008 01:52 GMT #7 its been used for wow for like the last 2 months. there is a program that will edit the registery for you so you cant screw it up, the program is called fasterping.

R1CH Netherlands10342 Posts February 13 2008 02:22 GMT #8 I would strongly recommend against doing these tweaks as it will increase load on routers, servers and everything in general with minimal actual benefit. Explanations for why this appears to reduce latency but doesn't really have much effect other than wasting packets: TCPNoDelay forces every call to send() to immediately send a packet. send() is a function used by TCP to send data over a socket, typically an application will work in one of two ways - it will either use a large buffer of data and repeatedly call send() until it's emptied, or it will build up a packet by calling send() multiple times, eg: send (socket, "0x01") // indicates packet type send (socket, length) // length of message send (socket, data) //data TCPNoDelay 0 (default) makes send() wait a tiny bit before actually firing off a packet across the Internet, in the hopes another send() will happen soon after, and it can coalesce (merge) the data so instead of the above sequence using 3 packets, it only takes 1. This greatly improves throughput for such applications and reduces load on the OS, routers, etc as well as reducing wasted bandwidth from TCP/IP packet overhead (3 headers + 3 data will consume more bandwidth than 1 header + 1 data). Most applications don't care whether TCPNoDelay is enabled or not - the delay after waiting for send() is so short, it doesn't make any perceived difference. In applications where the latency is extremely sensitive, eg VoIP, streaming or SSH for example, the applications themselves can turn TCPNoDelay on. By forcing it on across the OS, you're generating a lot of extra traffic for minimal benefit. If WoW or whatever benefited from TCPNoDelay, the developers would have added support for it in the application. The second tweak, TcpAckFrequency does pretty much nothing except fill the media with useless acks. The data you transmit will arrive at the remote peer regardless, and data you receive has already been received so ACKing it immediately has no tangible benefit. I could perhaps see this being useful if a small TCP Window Size was negotiated, in which case the peer will not transmit until an ACK, but this is best fixed by increasing your TCP Window rather than sending out extra ACKs. Ping calculation in online games is a tricky business - without actually sending out-of-band data, how is it done? Usually, it's done from key frames that the client must acknowledge or some kind of time stamping mechanism. Games usually compensate for displayed ping to try and make it "feel" better - for example, in Source games, if I use a higher than default command rate, my ping will be 30-40 on a server that is physically 50ms away. No amount of tweaking is going to break the speed of light . If either of these tweaks actually cause noticeable improvements, it indicates there is an issue with either the application client / server or the TCP Window size. There's a very good reason why these settings are not the default, and altering core parts of TCP/IP in order to reduce your displayed ping seems very wasteful. Almost all games where latency is a big factor (pretty much every FPS game, RTS (BW included), etc) use UDP which has none of the issues with send windows and packet coalescing - packets are send and received immediately. The above tweaks only affect TCP which is predominately used for bulk data transfer (HTTP, P2P, etc). The WoW developers made a conscious decision to use TCP since latency in WoW is not that big of a deal - data throughput is, which can be better improved through Window Scaling and other non-detrimental tweaks. Finally, if you're on Vista, you shouldn't even touch anything, including Window Scaling. The TCP stack on Vista is completely rewritten and dynamically optimizes for each connection. Forcing specific values will just result on poor automatic optimization. For details on how to improve your connection in a way that doesn't cause excess traffic and mess with the core of TCP/IP, check out the TCP Window tweaks at the bottom of http://shsc.info/WebBrowserOptimization

FakeSteve[TPR] Valhalla18444 Posts February 13 2008 02:23 GMT #9 damn you're good

LumberJack United States3355 Posts February 13 2008 02:32 GMT #10 um yea, when i said techies, i mean people like him, he rocks

Narrator United States868 Posts February 13 2008 02:34 GMT #11 On February 13 2008 11:23 FakeSteve[TPR] wrote: damn you're good Hey R1CH, want to tell us about the FasterPing program too? Is it safe to use that or does it have the same side effects?

Myrmidon United States9452 Posts February 13 2008 02:42 GMT #12 R1CH Well, in general, a safe assumption to make is that if some professional has designed a system a certain way, you probably shouldn't make changes unless you know exactly what it is you're doing and why. I'm thinking that TCP parameter tweaking could possibly be worthwhile over a weak contention-high wireless link. General TCP performance is pretty bad in that scenario, but I'm not sure what exactly you could do to improve things, even if you knew what the network characteristics were really like. In any case, making tweaks at the link-layer might be more constructive than messing with the transport layer when you have link-layer challenges.

HotZhot Colombia677 Posts February 13 2008 02:55 GMT #13 Great explanation, you teacher or something?

EvilTeletubby Baltimore, USA22259 Posts February 13 2008 03:10 GMT #14 Wow R1ch... who are you and where did you come from? Frankly it doesn't matter either way as you are pure awesome. Thank you for gracing TL.net with your presence.

Please log in or register to reply.