packet loss icon on everytime, how do you avoid it?
i mean, registry settings, tricks, etc?
Well if its on the whole time, that sounds like its a poor internet connection. (Run some tests over a few days at different times and look at the results. If they’re poor (High Jitter/Packet Loss or latency, contact your ISP.) JDs Auto Speed Tester, www.pingtest.net or run tracert or pathping in CMD as admin to the server’s ip.
Funny thing is, in BF4, the Loss icon shows sometimes even though I don’t have any packet loss on my connection. Don’t have this with other games. There would be some lag if the connection was suffering. Seems to be serverside in BF4 because a lot of shots aren’t registered even though you see hitmarkers. (blood splattering everywhere) Sub 50ms ping.
13 hops with tracert
What you want to look for is how high is the latency (ms) at each hop. (Don’t post that tracert here for security as it shows your ip and isp’s ip etc.) You want low ms at the hops and no request timed out messages/dropped packets. You will see * where the packets are dropped. This could illustrate a problem along the connection. You will need to run tests at different times and collect the results either by a screenshot or copying it and saving to a txt file for forwarding it on to your ISP so they can look into it. Some connections slow down in the afternoons and evenings due to increased levels of traffic (users) and less bandwidth available. You may experience a small bit of packet loss and higher latency during these times, which is why its important to test your connection maybe once every hour for a couple of days. You will see a trend and or a problem somewhere.
The packet loss icon shows when it detects a packet has not arrived. Which it is fairly easy to do since the packets are numbered. So for example, you get packet 55, 56, 57 and the next packet after that is 59. It means that packet 58 has been lost or is late.
Almost all games can handle up to 2% packet loss without it impacting performance and I don’t know of many other games that actually have a packet loss icon or allow you to test your connection to the server.
So while other games it might seem like you aren’t getting packet loss or your tracert don’t show packet loss, you might get some packet loss in other games.
hmm kay. i have two hops with packet dropped
ill try everything . even playing on different isp . try to play on different OS win7/8.1/10 technical preview . terrible packetlloss and hitreg in bf4 about a week . BF3 runs fine . Pingtest.net - no problems . Ping via cmd directly to the servers IP - stable ping / packetloss 0% .
Test this again a few times over the next day or two and see if it keeps happening. See if it you get * during every test (Is it at the same hop or does it happen at different hops/points) or if its just at peak usage times, when you can have a little packet loss.
If you have packet loss every time you do the test, email the recorded data to your ISP to see if they can look in to it for you. If you are running through a router, check to make sure there aren’t any other MAC addresses showing up as active. ( Could be someone else using your line using up your bandwidth and causing high latency/packet loss for you ) A hard wired connection will result in the best gaming experience as you’ll net higher speeds vs using wifi. Try restarting your router every so often too. Hope you get it sorted soon.
how can I proof isp that I have packetloss in BF4 ? if my pingtest is ok 24h/7 days ?
even ping via cmd ping -n 1000 "server ip address " after test all packets are send and received ! But in game is shoving packet loss icon .
Just do all this…
Check the TCP/IP state
To check the current status of the Vista TCP/IP tweakable parameters, in elevated command prompt type the following command:
netsh int tcp show global
You will be presented with something like the following:
The settings, as well as their default and recommended state are explained below. The two most important tweakable parameters are “Auto-Tuning Level” and “Congestion Control Provider”.
When checking the TCP state with the “netsh int tcp show global” command, it is also possible to see the following message below all those parameters:
The above autotuninglevel setting is the result of Windows Scaling heuristics overriding any local/policy configuration on at least one profile.
It is displayed when the “Receive Window Auto-Tuning Level” is not explicitly set, or if the system deemed it necessary to make a change because of user prompted “repairing” of your network connection, for example.
Disable Windows Scaling heuristics
Windows Vista/7 has the ability to automatically change its own TCP Window auto-tuning behavior to a more conservative state regardless of any user settings. It is possible for Windows to override the autotuninlevel even after an user sets their custom TCP auto-tuning level. When that behavior occurs, it can have a very noticeable negative impact on throughput, and it does not automatically correct itself. If auto-tuning gets limited, the “netsh int tcp show global” command displays the following message:
The above autotuninglevel setting is the result of Windows Scaling heuristics
overriding any local/policy configuration on at least one profile.
To prevent that behavior and enforce any user-set TCP Window auto-tunning level, you should execute the following command:
netsh int tcp set heuristics disabled
possible settings are: disabled,enabled,default (sets to the Windows default state)
recommended: disabled (to retain user-set auto-tuning level)
Note this should be executed in elevated command prompt (with admin priviledges) before setting the autotuninlevel in next section. If the command is accepted by the OS you will see an “Ok.” on a new line.
The corresponding Registry value (not necessary to edit if setting via netsh) is located in:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Tcpip\Parameters
EnableWsd=0 (default: 1, recommended: 0)
Note: This automatic limitation of the TCP Window usually occurs in the presence of some packet loss, which can be common in longer transfers and server applications.
TCP Auto-Tuning
To turn off the default RWIN auto tuning behavior, (in elevated command prompt) type:
netsh int tcp set global autotuninglevel=disabled
The default auto-tuning level is “normal”, and the possible settings for the above command are:
disabled: uses a fixed value for the tcp receive window. Limits it to 64KB (limited at 65535).
highlyrestricted: allows the receive window to grow beyond its default value, very conservatively
restricted: somewhat restricted growth of the tcp receive window beyond its default value
normal: default value, allows the receive window to grow to accommodate most conditions
experimental: allows the receive window to grow to accommodate extreme scenarios (not recommended, it can degrade performance in common scenarios, only intended for research purposes. It enables RWIN values of over 16 MB)
Our recommendation: normal (unless you’re experiencing problems).
If you’re experiencing problems with your NAT router or SPI firewall, try the “restricted”, “highlyrestricted”, or even “disabled” state.
Notes:
- Reportedly, some older residential NAT routers with a SPI firewall may have problems with enabled tcp auto-tuning in it’s “normal” state, resulting in slow speeds, packet loss, reduced network performance in general.
- auto-tuning also causes problems with really old routers that do not support TCP Windows scaling. See MSKB 935400
- netsh set commands take effect immediately after executing, there is no need to reboot.
- sometimes when using “normal” mode and long lasting connections (p2p software / torrents), tcp windows can get very large and consume too much resources, if you’re experiencing problems try a more conservative (restricted) setting.
If you’re experiencing problems with Auto-Tuning, see also:
MSKB 835400 - email issues
MSKB 934430 - network connectivity behind firewall problems
MSKB 940646 - 3G WWAN throughput issues
MSKB 929868 - web browsing issues
MSKB 932170 - slow network file transfer
Compound TCP - Improve throughput
Add-On Congestion Control Provider
The traditional slow-start and congestion avoidance algorithms in TCP help avoid network congestion by gradually increasing the TCP window at the beginning of transfers until the TCP Receive Window boundary is reached, or packet loss occurs. For broadband internet connections that combine high TCP Window with higher latency (high BDP), these algorithms do not increase the TCP windows fast enough to fully utilize the bandwidth of the connection.
Compound TCP (CTCP) is a newer method, available in Vista and Server 2008 (there is also a hotfix available for XP x64 and 2003 Server - MSKB 949316). CTCP increases the TCP send window more aggressively for broadband connections (with large RWIN and BDP). CTCP attempts to maximize throughput by monitoring delay variations and packet loss. It also ensures that its behavior does not impact other TCP connections negatively.
By default, Vista and Windows 7 have CTCP turned off, it is only on by default under Server 2008. Turning this option on can significantly increase throughput and packet loss recovery.
To enable CTCP, in elevated command prompt type:
netsh int tcp set global congestionprovider=ctcp
To disable CTCP:
netsh int tcp set global congestionprovider=none
Possible options are: ctcp, none, default (restores the system default value).
Recommended setting: ctcp
It is better to use this newer generation CTCP congestion control algorithm for most broadband connections, we highly recommend it being turned on.
ECN Capability
ECN (Explicit Congestion Notification, RFC 3168) is a mechanism that provides routers with an alternate method of communicating network congestion. It is aimed to decrease retransmissions. In essence, ECN assumes that the cause of any packet loss is router congestion. It allows routers experiencing congestion to mark packets and allow clients to automatically lower their transfer rate to prevent further packet loss. Traditionally, TCP/IP networks signal congestion by dropping packets. When ECN is successfully negotiated, an ECN-aware router may set a bit in the IP header (in the DiffServ field) instead of dropping a packet in order to signal congestion. The receiver echoes the congestion indication to the sender, which must react as though a packet drop were detected.
ECN is disabled by default in Vista and other modern TCP/IP implementations, as it is possible that it may cause problems with some outdated routers that drop packets with the ECN bit set, rather than ignoring the bit. To check whether your router supports ECN, you can use the Microsoft Internet Connectivity Evaluation Tool. The results will be displayed under “Traffic Congestion Test”.
To change ECN, in elevated command prompt type:
netsh int tcp set global ecncapability=default
Possible settings are: enabled, disabled, default (restores the state to the system default).
The default state is: disabled
Recommendation: enabled (only for short-lived, interactive connections and HTTP requests with routers that support it, in the presense of congestion/packet loss), disabled otherwise (for pure bulk throughput with large TCP Window, no regular congestion/packet loss, or outdated routers without ECN support).
Notes: ECN is only effective in combination with AQM (Active Queue Management) router policy. It has more noticeable effect on performance with interactive connections and HTTP requests, in the presense of router congestion/packet loss. Its effect on bulk throughput with large TCP Window are less clear.
Currently, we do not recommend enabling this setting, as reportedly it has negative impact on throughput with some residential US ISPs. EA multiplayer games that require a profile logon do not support ECN as well (you will not be able to logon).
More information on ECN: Explicit Congestion Notification (ECN) for TCP/IP
RSS - Receive-side Scaling
The receive-side scaling setting enables parallelized processing of received packets on multiple processors, while avoiding packet reordering. It avoids packet reordering y separating packets into “flows”, and using a single processor for processing all the packets for a given flow. Packets are separated into flows by computing a hash value based on specific fields in each packet, and the resulting hash values are used to select a processor for processing the flow. This approach ensures that all packets belonging to a given TCP connection will be queued to the same processor, in the same order that they were received by the network adapter.
To set RSS:
netsh int tcp set global rss=enabled
Possible rss settings are: disabled, enabled, default (restores rss state to the system default).
Default state is: enabled
Recommended: enabled (if you have 2 or more processor cores and a NIC that can handle RSS)
In Windows Server 2008, the system default is for RSS to be enabled and to use a maximum of four CPUs. While this is usually enough, administrators can adjust the maximum number of RSS processors by setting the MaxNumRssCpus registry value in HKLM\System\CurrentControlSet\Services\NDIS\Parameters. The value type is DWORD, and if not present, the default value of four processors is assumed (do not use value greater than 32).
See also: Receive-Side Scaling Enhancements in Win
^^
LOL i would love an answer from the devs as to why the packet loss icon occasionally shows in BF4 even when you have zero packet loss on the connection! Another ‘Only in Battlefield’ thing i guess. 
Some people do have bad connections though which could well be OP’s case.
bookmark to watch
Let me guess, you are playing on WIFI?
wifi, no?
@dredg, i dont understand, why are you mentioning tcp protocol, FPS use UDP ???
All FPS still send some TCP packets once in awhile. Also the settings can affect UDP packets. Since the OS checks the packet to see if it is TCP or UDP before it sends them and does stuff according to which it is. Depending on your TCP settings, your packets can by pass this check.
sounds like a magic trick
easiest and most satisfying fix is to uninstall this POS game and origin
power off fixed the game for you?
Lmao so you guys are laggers…
yes we are. too far from dslam.