!FIX! for Connection Issues (Lag, 90K, etc)

[Raist]

mileage can vary with this depending on vendor and their implementation of the feature. It's more or less like a bursting trick, and for it to work smoothly there needs to be compliant infrastructure in place. For instance, some cable or DSL subscribers may not notice much difference because of how the flow control works to cap bandwidth on the system--it already has a bursting mechanic in place of sorts. It might even worsen the condition depending on how much the modem queues between bursts if it leads to heavier fragmentation. Think of it like old RWIN tweaking and how things get flubbed when you disregarded MTU/MSS and such, or if you went too far with max connects per server settings--all the buffering needs to flow properly or you can wind up with increased retransmits.

{Edit:]
Out of curiosity I did some poking around with my Qualcomm, and apparently this setting may not be controlling the use of the feature, but toggling whether segmentation is being controlled at the NIC's engine or by the CPU. Depending on the chipset in use, some may get more mileage if they were able to get more optimized drivers for their network controller.

[KisaiTenshi]

mileage can vary with this depending on vendor and their implementation of the feature.

The reason it probably makes a difference probably has more to do with poor driver implementation combined with even poorer network infrastructure. To give an example, even if I disable nagle on my connection, it has no effect with this ISP, however the previous ADSL hardware it totally made a difference. I had to disable ECN (on a realtek chip) to play Mass Effect 2, but no other game.

What people should do before they dink around with this setting, because turning it off wholesale may break something.
Go to an administrative command prompt and type:
netsh interface tcp show global

You'll see something like this
Querying active state...

TCP Global Parameters
----------------------------------------------
Receive-Side Scaling State : enabled
Chimney Offload State : enabled
NetDMA State : enabled
Direct Cache Acess (DCA) : enabled
Receive Window Auto-Tuning Level : normal
Add-On Congestion Control Provider : ctcp
ECN Capability : enabled
RFC 1323 Timestamps : disabled

then type
netsh interface tcp show chimneystats

Idx Supp Atmpt TMax PMax Olc Failure Reason
--- ---- ----- ---- ---- --- --------------
22 No -n/a- 0 0 0 -n/a-
33 No -n/a- 0 0 0 -n/a-
25 No -n/a- 0 0 0 -n/a-
26 No -n/a- 0 0 0 -n/a-

If you see something like above, the TOE isn't even being used. So disabling it at the driver level is unlikely to change anything.

You can then force these settings off to troubleshoot things one at a time with:
netsh int tcp set global chimney=disabled
netsh int tcp set global ecncapability=disabled
netsh int tcp set global congestionprovider=none
netsh int tcp set global rss=none

Note do not set all of these at once, only set them to see if it fixes it, if it doesn't fix it, restore it to what it was before. In particular that last feature, receive side scaling (rss) can change the CPU load quite significantly.

[KisaiTenshi]

Just to bump this a little...

netsh interface tcp add chimneyapplication state=disable application="C:\Program Files (x86)\SquareEnix\FINAL FANTASY XIV - A Realm Reborn\game\ffxiv.exe"

Should disable TOE features as per the "seems like it fixed it" in the OP just for FFXIV, but I can't test it since my connection works fine.