Cosmic Break
Welcome! to the Unofficial Fan Forums Please read the rules as soon as you can. It will only take a few minutes of your time to do so. If you are not willing to read them, you might not be here for long! Enjoy your stay and don't get into trouble.

Click here for Forum Rules

Click here for Cosmic Break Guides



 
HomeSearchMemberlistUsergroupsRegisterLog in

Share | 
 

 [Guide] "Anti" Connection Lag (sort of)

Go down 
Go to page : Previous  1, 2, 3
AuthorMessage
Verafice
Newbie
Newbie
Verafice

Male Posts : 62
Join date : 2011-07-10

PostSubject: Re: [Guide] "Anti" Connection Lag (sort of)   Wed Nov 09, 2011 9:56 pm

Hilarious thread.

1.
Quote :
This is because when Windows queues up an acknowledgement in order to
bundle it with the following one, the game server has to wait for the acknowledgment timer to expire before sending new data.
Cool, a tool made by a guy who doesn't understand the TCP protocol, which turns off a feature explicitly recommended in a congestion control RFC? [ http://www.faqs.org/rfcs/rfc2581.html ]
Quote :
The delayed ACK algorithm specified in [Bra89] SHOULD be used by a
TCP receiver.
....
We also emphasize that this is a SHOULD, meaning that an
implementor should indeed only deviate from this requirement after
careful consideration of the implications.
You're not convinced? I can explain it properly, don't worry.

I won't bother with an all-out lecture. After all you can wikipedia it or consult a good networking book. The fundamental point is that " the game server has to wait for the acknowledgment timer to expire before sending new data." is completely wrong. TCP isn't a naive protocol. If it really worked like "I'll send you a packet.... then wait for you to tell me you've got it" a small amount of network latency would completely kill throughput, since you'd be waiting for packets more often than actually getting them. In reality it uses a sliding window buffer. A sends a packet to B.... then keeps sending more packets. each packet has an incremental sequence number. B may eventually send an acknowledgement. If B acknowledges packet number 108, it is saying it has received packets 0->108 successfully. There is no need to acknowledge individual packets; this would waste bandwidth sending redundant packets. (hence the RFC recommendation for delayed acknowledgements) You're probably wondering how A can just keep sending packets to B without an acknowledgement? Because the TCP protocol's use of a buffer. when B sends an acknowledgement to A, it also says its "window size" -- basically how much more data its buffer can hold. A would only stop sending packets if it is under the impression B's buffer is full. This could happen if B doesn't acknowledge for a long time. But it will because it knows when it's buffer is filling! Get it?

Quote :
...the acknowledgement timer to expire before sending new data.
Regarding this - yes there is an acknowledgement timer in the TCP protocol. When it expires the sender presumes the receiver didn't get previous data, so it just re-sends it. (so on an unreliable connection with high packet corruption, network latency starts to become really important to throughput - more on this in a sec.) Finally, raw ACK packets are basically never going to be sent in the context of games. Because the client and server are constantly communicating with each-other, acknowledgements will be piggy-backed amongst data sends for efficiency. So whenever your client sends data to the server, it's probably also confirming all the packets it just received.


Now you understand why you can still download at 1mb/s from a server with a 500ping. Because of the use of buffers, packets don't need to be acknowledged immediately. The server can just keep putting packets on the wire and let them find their way there. Latency only starts to effect throughput as the rate of error increases. If the rate of corrupt packets is high, the time it takes for the resend request from the receiver to reach the sender becomes increasingly critical. This can definitely hurt game performance, which is why UDP is a better choice in some ways (design your protocol so reliability doesn't matter.) TCP is just easier and the built-in robustness makes programmers more comfortable, but it is horrific for real-time applications on latent networks. (hint: Most VoIP and video conferencing protocols work over UDP for this reason.)

But can changing the registry setting / using this tool actually work?
Yes, but it's far more likely you're just kidding yourself. Take deep breaths and check again. If it really does seem to help then maybe inadequate buffer lengths are being used, but this really shouldn't happen. For the curious: http://en.wikipedia.org/wiki/TCP_window_scale_option

You're probably doing more harm than good, by preventing the piggy-backing of acknowledgements, which was a motivation for delayed ACK in the first place. Here's somehting from a FreeBSD performance tuning guide on the matter. If you're already convinced you can skip this and go to 4. for stuff that's actually useful.

http://www.gsp.com/cgi-bin/man.cgi?section=7&topic=tuning
Quote :
The net.inet.tcp.delayed_ack TCP feature is largely misunderstood. Historically speaking, this feature was designed to allow the acknowledgement to transmitted data to be returned along with the response. For example, when you type over a remote shell, the acknowledgement to the character you send can be returned along with the data representing the echo of the character. With delayed acks turned off, the acknowledgement may be sent in its own packet, before the remote service has a chance to echo the data it just received. This same concept also applies to any interactive protocol (e.g. SMTP, WWW, POP3), and can cut the number of tiny packets flowing across the network in half.
The delayed ACK implementation also follows the TCP protocol rule that at least every other packet be acknowledged even if the standard 100ms timeout has not yet passed. Normally the worst a delayed ACK can do is slightly delay the teardown of a connection, or slightly delay the ramp-up of a slow-start TCP connection. While we are not sure we believe that the several FAQs related to packages such as SAMBA and SQUID which advise turning off delayed acks may be referring to the slow-start issue. In
.Fx , it would be more beneficial to increase the slow-start flightsize via the net.inet.tcp.slowstart_flightsize sysctl rather than disable delayed acks.

If a game server measures ping as the time between a packet being sent and receiving an ACK for it, this will "lower your PING", but it won't change actual latency....

2.
Yes, some ISPs have absolutely dire name servers. I used to be on one. Using opendns can greatly speed up name resolutions in this case. In-turn, this can greatly reduce lag when browsing the internet (you can't even start talking to a server if you don't know its IP, right?)

But this only effects the time it takes to resolve domains, which at most only occurs twice in CB. 1: To access the patch server. 2: to access the login/channel servers. Although these IPs may be hard-coded in to the client -- I've not bothered checking.
It's not going to do anything about in-game lag. Domain name servers only resolve domain names to IP addresses. Nothing else.

3.
I particularly enjoyed the "I have powershell installed, I'm a genius" show boating. I'll call bullshit until you actually know what you're talking about. (hint: If you can't explain why your latency has improved, you probably don't know what you're doing.) (hint2: tunnelling refers to the process of wrapping one protocol inside another protocol. A common example within networking would be an "SSH tunnel", in which your TCP/IP traffic is tunnelled via a secure shell to another machine, which then basically acts as a proxy for you. This generally adds more hops and makes latency worse, much like using a regular proxy server would.)

4.
The first link shows genuinely useful information. If you've read my previous critiques you will already understand what the receive window is, and how it being larger is generally a good thing. If you look through this page/site they tell you how to manually adjust various settings. I'm not going to endorse their tools since I've not used them. But the stuff here is more relevant than any of the other stuff in this thread. By default most OS will have optimum settings though. If "MTU Discovery" is "ON" you don't need to worry if your MTU is listed on the site as < 1500, regardless of their red text.

MTU is regarding the physical layer transmission unit size. TCP splits data in to packets and sends it. TCP is the end-to-end protocol used by software applications to talk to each other. It operates over IP - internet protocol - which handles routing these packets over a network. IP depends on underlying physical layer protocols connecting individual machines to each-other. Each physical layer connection (think of your ethernet cable or wi-fi!) will have its own MTU size.

(aside: Might not be completely precise in this next section coming up, I've forgotten stuff because like most people I only really care about high-level networking. But this should be correct.)

If you're trying to push a 1500 byte TCP packet over a wifi connection with an MTU of 1000bytes, it's going to end up as a 1000byte wifi packet and a sub-optimal 500byte wifi packet . This is known as Internet Protocol Fragmentation. That sounds bad doesn't it? It's actually a minor issue, but it can be cumulative because re-assembly only occurs at the final destination so: Then if the physical layer between the next routers has an MTU of 800, that first 1000 byte packet splits in to a 800byte packet and a 200 byte packet.
"MTU Path Discovery" basically finds the smallest MTU any physical layer on the path/route between your computer and whatever it's talking to. If we know this smallest MTU, we can just send TCP packets of that size -- then they will never fragment on the way to the recipient, avoiding IP fragmentation completely. Yeah!

TL;DR : MTU path discovery should be turned on. actual MTU size doesn't matter. Window size should be large, especially if your ISP is shit or you download lots of stuff from Chinese or Japanese servers/P2P. Most people will already have "Optimum" (or close enough) settings because OS designers aren't complete idiots. Turning off ACK bundling is generally a bad idea. Open DNS isn't going to solve your CB lag.
Back to top Go down
View user profile http://www.verafice.com
Nymph~
Ace Poster
Ace Poster
Nymph~

Posts : 1221
Join date : 2011-07-23

PostSubject: Re: [Guide] "Anti" Connection Lag (sort of)   Thu Nov 10, 2011 6:15 am

^ wow, loooong stuff you wrote there, i give up even b4 read it lol,
well I read tl;dr thou, I don't care about hard stuff as long as i don't lag xD
Back to top Go down
View user profile
Aria
Master Poster
Master Poster
Aria

Male Posts : 2859
Join date : 2011-03-24
Age : 28

PostSubject: Re: [Guide] "Anti" Connection Lag (sort of)   Fri Nov 11, 2011 7:36 am

Back to top Go down
View user profile
Aria
Master Poster
Master Poster
Aria

Male Posts : 2859
Join date : 2011-03-24
Age : 28

PostSubject: Re: [Guide] "Anti" Connection Lag (sort of)   Thu Dec 01, 2011 6:50 am

Bumping for update

Low Latency Rooms added (<=250ms)
Back to top Go down
View user profile
FreedomFighter
Ace Poster
Ace Poster
FreedomFighter

Posts : 1147
Join date : 2010-10-10

PostSubject: Re: [Guide] "Anti" Connection Lag (sort of)   Wed Dec 07, 2011 9:29 pm

gonna try method 2, Powershell is good but i don't know what the heck about it so i skipped it -_-"

if Aria could write a guide about it then i would be damn but since he already state about it freaking hard code
then it's up to him.

-------------------

tested in cmd
before : around 250
after : around 200
well better than nothing, gonna try another method if i have time.
Back to top Go down
View user profile
Sponsored content




PostSubject: Re: [Guide] "Anti" Connection Lag (sort of)   

Back to top Go down
 
[Guide] "Anti" Connection Lag (sort of)
Back to top 
Page 3 of 3Go to page : Previous  1, 2, 3

Permissions in this forum:You cannot reply to topics in this forum
Cosmic Break :: Cosmic Break :: Guides-
Jump to:  




Copyright©2007-2014 CyberStep, Inc. All Rights Reserved.

Theme by, Sean

Free forum | © phpBB | Free forum support | Contact | Report an abuse | Forumotion.com