6% Loss Out issues


Blizzard I am seeing 6% loss out on the game since the patching from January. Any suggestions here? I’ve tried this with a different NIC. Still having the same issues. I had the ISP come out change network hardware on their end. I just don’t see any way this is working out. Especially for hitscan playing. :frowning:


Can you post the networking test you used to spot this 6%? https://us.battle.net/support/en/article/27780


would you happen to have a different download for MTR. I found this latest one to have tripped the alarm on the network stating the download might contain a Trojan Virus.


That is a link to the official download for it, so no, I wouldn’t suggest getting it elsewhere.


I can post an upload photo of my Packet loss on the game. for the time being I know that several times sourceforge has been compromised in the past. Back when they were first available they had some security holes that caused downloads to have files piggybacked.

What I got from this website the other day while trying to download the program was someone that had put a R.A.T. or as we call a Remote Access Trojan into it. It was some sort of injection. But it came back to that specific download at the time of Event when it had happened.

I am sure in a day or two they might have it patched.

The link below is a google-type drop box for photo uploads. I included a photo upload of this morning’s gameplay on Blizzard World. Just so we are on the same page here, as to what is going on.

(do NOT include spaces in the URL, the (-) IS a required character)

https: //dasaries -player .blogspot . com/2017/11/dasaries-computer-performance-blog.html

Thank you!



You could attempt to run a Pathping at the exact time the loss is occurring instead of a WinMTR.

We know the issue is packet loss but now we need to find it. The WinMTR is nice because it’s more like a movie of your connection over time via a snapshot of a Pathping. Either way if you can run a few pathpings when the issue is occurring and get them back here that may do the trick. You could also try a LookingGlass report. Make sure to run all the tests and post the full results back here.

Thank you.


Thank you! Yes I would be more than happy to do that. I should have the test results sometime finished within the afternoon or early evening. I will begin logging.

Path ping tests

Path Ping test 1: Numbani . Widow player kept hitting me before I even seen them. Player was at CP 1. Top guard rails. Kill cam shows I was leaving Defenders spawn. Player position shows me peaking from the street and hitting me before I even saw them in Cross hairs.

Average observable loss: 3.3-4%

Tracing route to over a maximum of 30 hops

2 * * *
Computing statistics for 25 seconds…
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0/ 100 = 0% |
1 0ms 0/ 100 = 0% 0/ 100 = 0%

Trace complete.

Test #2. Route 66.

Average observable loss: 4-7%

Average observable loss:

Tracing route to over a maximum of 30 hops

2 * * *
Computing statistics for 25 seconds…
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0/ 100 = 0% |
1 0ms 0/ 100 = 0% 0/ 100 = 0%

Trace complete.

Test #3

Numbani Defense

Average observable loss: 3.3-5%

Tracing route to over a maximum of 30 hops

2 * * *
Computing statistics for 25 seconds…
Source to Here This Node/Link
Hop RTT Lost/Sent = Pct Lost/Sent = Pct Address
0/ 100 = 0% |
1 0ms 0/ 100 = 0% 0/ 100 = 0%

Trace complete.


traceroute to (, 15 hops max, 60 byte packets
1 Blizzard Blizzard 1.100 ms 1.058 ms 1.052 ms Blizzard( 4.793 ms 4.884 ms 5.135 ms
3 ( 1.067 ms 1.066 ms 1.165 ms
4 ( 1.036 ms 1.035 ms 1.034 ms
5 ( 13.347 ms 13.347 ms 13.346 ms
6 ( 17.053 ms 14.341 ms 14.270 ms
7 ( 12.776 ms 12.762 ms 12.996 ms
8 ( 12.995 ms 12.985 ms 12.979 ms
9 ( 12.584 ms 13.107 ms 13.090 ms
10 eqix-sv1.windstream. com ( 12.436 ms 12.430 ms 12.412 ms
11 ae3-0.cr02.snju01-ca.us.windstream. net ( 12.401 ms 12.426 ms 12.515 ms
12 ae2-0.cr01.dnvt01-co.us.windstream. net ( 42.167 ms 42.157 ms 42.151 ms
13 et3-0-0-0.cr02.dnvt01-co.us.windstream. net ( 42.124 ms 42.129 ms 42.260 ms
14 ae7-0.agr02.lncl01-ne.us.windstream. net ( 50.371 ms 50.364 ms 51.075 ms
15 * * *

Blizzard Looking Glass. (Idle no gameplay)
Start: Fri Feb 22 21:10:49 2019 Blizzard 1.|-- Blizzard 0.0% 10 0.3 0.3 0.2 0.4 0.0
2.|-- 0.0% 10 0.6 1.7 0.5 11.1 3.3
3.|-- 0.0% 10 0.8 0.6 0.5 0.8 0.0
4.|-- 0.0% 10 0.8 0.7 0.5 0.8 0.0
5.|-- 0.0% 10 12.9 13.4 12.7 18.0 1.5
6.|-- 0.0% 10 12.8 38.2 12.7 115.5 35.6
7.|-- 0.0% 10 12.8 20.7 12.7 59.1 15.3
8.|-- 0.0% 10 12.7 14.5 12.7 28.5 4.9
9.|-- 0.0% 10 12.7 12.6 12.6 12.7 0.0
10.|-- eqix-sv1.windstream. com 0.0% 10 12.5 12.6 12.4 13.3 0.0
11.|-- h80.83.138.40.static.ip.windstream.n et 0.0% 10 12.7 12.6 12.5 12.8 0.0
12.|-- ae2-0.cr01.dnvt01-co.us.windstream. net 0.0% 10 42.4 44.7 42.0 66.7 7.7
13.|-- et3-0-0-0.cr02.dnvt01-co.us.windstream. net 0.0% 10 42.3 42.3 42.1 42.6 0.0
14.|-- ae7-0.agr02.lncl01-ne.us.windstream. net 0.0% 10 50.8 50.6 50.5 50.8 0.0
15.|-- port3-2-2.bng01.lncl01-ne.us.windstream. net 90.0% 10 13391 13391 13391 13391 0.0
16.|-- h37.215.29.71.dynamic.ip.windstream. net 10.0% 10 60.5 60.3 60.0 60.6 0.0

22/02/2019 21:10:49 UTC

Game in Progress results.

Start: Fri Feb 22 21:14:53 2019 Blizzard 1.|-- Blizzard 0.0% 10 0.4 0.3 0.2 0.4 0.0
2.|-- 0.0% 10 0.7 1.1 0.5 4.8 1.2
3.|-- 0.0% 10 0.7 0.6 0.5 0.8 0.0
4.|-- 0.0% 10 0.9 0.7 0.6 1.2 0.0
5.|-- 0.0% 10 12.9 13.8 12.8 21.7 2.7
6.|-- 0.0% 10 12.9 15.2 12.8 31.8 6.0
7.|-- 0.0% 10 13.0 14.5 12.8 29.4 5.2
8.|-- 0.0% 10 13.0 16.4 12.7 45.9 10.4
9.|-- 0.0% 10 12.6 12.7 12.5 12.8 0.0
10.|-- eqix-sv1.windstream. com 0.0% 10 13.0 12.7 12.4 13.5 0.0
11.|-- ae3-0.cr02.snju01-ca.us.windstream. net 0.0% 10 12.7 12.6 12.5 12.7 0.0
12.|-- ae2-0.cr01.dnvt01-co.us.windstream. net 0.0% 10 42.3 42.2 42.1 42.3 0.0
13.|-- et3-0-0-0.cr02.dnvt01-co.us.windstream. net 0.0% 10 42.4 42.3 42.2 42.4 0.0
14.|-- ae7-0.agr02.lncl01-ne.us.windstream. net 0.0% 10 86.0 54.5 50.5 86.0 11.1
15.|-- port3-2-2.bng01.lncl01-ne.us.windstream. net 80.0% 10 12713 12706 12698 12713 10.0
16.|-- h37.215.29.71.dynamic.ip.windstream. net 0.0% 10 60.4 60.2 59.7 60.7 0.0

22/02/2019 21:14:53 UTC

Ping Test.

PING 56(84) bytes of data.
64 bytes from icmp_seq=1 ttl=52 time=60.8 ms
64 bytes from: icmp_seq=2 ttl=52 time=60.8 ms
64 bytes from : icmp_seq=3 ttl=52 time=60.5 ms
64 bytes from icmp_seq=4 ttl=52 time=60.4 ms

— ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3003ms
rtt min/avg/max/mdev = 60.479/60.676/60.844/0.290 ms

Okay. I guess that pretty much sums up what I can do on my end here. For me, when it is Hitscan vs hitscan fights. And even fast moving targets. I take the shot and it becomes a “non register” shot.I always lose because they are seeing me, before I can see them. I can watch my screen and observe that I am FULLY exposed to them, before They are exposed to me, on my screen.

Thank you very much! :slight_smile:


Oh hey again, Dasaries.

None of that data was usable, unfortunately. It appears that your modem or whatever’s after it is blocking ICMP echo requests which makes the pathping useless in this regard. You can try the winMTRNet clone instead if you’d like but I would wager anything on the winMTR website is a false positive.

Is the packet loss coming and going, or has it been pretty consistent these last few months?


HI again Drakuloth! Happy to hear you are here!

I guess I am still hanging around the forums. . First troubleshooting FPS loss. and then now the Packet loss. Trouble always follows me wherever I go. LOL . I have a lot to say so I’d suggest free time and some coffee or a beverage of your choosing :slight_smile: … And so it begins… again!

Well Yes, I am racking up the leaver penalties in conjunction with the troubleshooting. Maybe someday answers will be here…

Packet issues:. January’s Patch day for the new content gave me this incredible issue with Packet loss from the game’s End. Prior to that date. I probably saw about 0.5%-1% from November, but nothing too bad. Then January came and RIGHT on patch day the game never ran good again. I reinstalled the game, wiped the game from the registry TWICE and I still see the same issue here.

The Winmtr download: What I caught was a file that was initiated at that exact time stamp when the download occurred. Where a Trojan was being saved to the desktop. It was actually a hidden file located on the desktop during the exact time of the download. So it wasn’t “there” but it was “there”. during that download. I mean it could have been a MITM attack at that point in time. My antivirus software showed it was a payload that piggybacked onto the download But I might try it again tomorrow. Today it actually shows the website is down. when going to the official website. So i will see what happens tomorrow and try again :slight_smile:

The long answer…

So here is what I did…

I had the ISP come out to the NID box and swap the DSL POT out and put a new one in. They came out with a new router and even had me try their new router/modem. Same thing. I have really good connection from other games from this point on in and then Overwatch just seams to not like how the Network operates. I’ve got NO other devices on the network. No wireless. Just 12’ of Cat 6 from this computer to the Modem, and when my ISP came out we worked together to run 6’ of telcom wire right into the NID. Yes, I put a hole through my wall with the hammer drill and we pulled exactly 6’ of telcom wire from the NID.

Now to me, I know that we were out there with the hardsided network equipment testing stuff, at the box by the street. That run is about 125’ to the lug terminal box from the NID to the street and their cable itself is ALL buried out this way. Then, Before it hits a repeater station and then goes out to the highway’s fiber run. The old military base out here has buried cables and they leased it to the ISP. So phone poles and weather are NOT a problem! :slight_smile: One of the telcom operators was nice enough to actually check it on his end and didn’t see anything out of the ordinary. I personally know a few people that worked there before decommissioning and the wire under the ground is no laughing matter. It’s VERY robust.

Hardware wise I did a swap to see if it was something on my end. I ordered in an ASRock Z370 SLI, swapped around the RTX2060 and the GTX1060, an i5 hex core cpu and even a pair of dominator platinum ram sticks. FPS issues never went away, packet loss was still there (infact slightly even WORSE) and I just decided at that point to sell everything off but the RAM and the GPU. So I made my money back. :slight_smile: I’d say the input lag was WORSE on the i5 hex cores

For the previous story and it’s outcome:

FPS wise: You know I never did get that fairly perfect. But even on the RTX 2060 and swapping a board with a NEW O.S., windows update, Processor RAM sticks and hardware swaps. Same issues. It wasn’t Until i switched this game into Windows 7 Compatibility mode. Much smoother. February’s Windows update at the start of the month BOGGED this machine down. So I pulled it, locked down windows and it went back to much better behavior. However, whatever it IS that is causing it. is outside of my training.

To me, I don’t like pressing the matter on Blizzard, but if a person NEVER knows what they tested this game on (hardware specs) and the exact environmental perimeters here. I could be troubleshooting endlessly and never see results. First thing that comes to my mind is maybe the BAUD rate is wrong here on my end. Who knows.

yes, I’d love to visit the studio myself and see what they test the games on (dont know what they are allowing or are not on the tours,) but I am not going to be in California this year to pull honeybee hives out of the almond orchards after pollination. Many professional keepers aren’t. Bakersfield was calling us left and right for pollination. and national loss on bees was 65% with the USDA even calling us and asking us what the deal is on bees. So I am kinda stuck here Freezing in the Midwest.

I guess that is pretty much where I am at :slight_smile:


Heya Dasaries,

I vaguely remember you asking that question (re: specs of the machines) back in the day, but we’re not directly privy to that information. What I can tell you is that our QA team does it on a large number of different hardware configurations/combinations. We usually grab a few copies of new hardware too. (Our QA folks are always putting in tickets for new and old toys to test on. :D)

As long as your machine meets requirements and you’re running supported hardware, and there isn’t some kind of bug or hardware/software level issue, you shouldn’t see odd behavior from a performance perspective. That’s the point of the troubleshooting after all. We have been monitoring some reports of the 10x0/20x0 series cards (Mainly the RTX) experiencing Rendering Device Lost crashes lately. Currently we suspect it has something to do with NVidia profiling. More on that here. Maybe the work around here gives you some love with the FPS issues? Beyond that you mentioned basically building a whole new rig from scratch, so we’d be back to square one on that.

Let’s take this one thing at a time though. Right now you’ve got something a bit more easily measurable. Once you’ve got a winMTR which captures the issue, definitely post it so we can take a peek. If you can also get a screenshot of your netgraph when the loss is happening, upload it to imgur, and link it to us, we’ll give that a look too.


Okay Everything is a “Green light” on this download and I have it up and ready to go.

Which address do you want me to examine and how much of a snapshot of this would you like me to take?


I should ask. Just OUT of curiosity. (which I strongly emphasize) Which hardware config are they finding keeps the game ABOVE 200fps at Medium-high settings. I mean I just put in this RTX 2060 and I think I have a processor or Monitor issue here TBH. Rialto is a stunning map to look at, but when combat is going on. I go from 220fps down to a 96FPS. I tried an i5 hex core on a Z370 board and that dipped hard, too.

Thank you!


Regarding the winMTR - snag the IP address from the network graph in game where you’re having loss. (Ctrl+Shift+N to bring it up.) There’s more information on what to do with it in the WinMTR article itself.

As for the performance spec machines, again, we do not have that information. I am absolutely willing to help troubleshoot the connection issue, but as I have mentioned to you on multiple occasions including this one, we do not create ‘performance spec’ machine lists because we cannot guarantee performance due to a myriad of factors with individual hardware types and manufacturers. These days most hardware works together most of the time, but we’re not going to open the floodgates for “You said this would get a consistent 200 FPS” or something of that nature when it’s not really in our control. In general, our hardware requirements are not set for you to achieve anything above 60 fps most of the time.

Your system exceeds those requirements, and your hardware’s pretty good, but you’re getting over 60 FPS consistently. Anything beyond that is considered enthusiast, and is on you to optimize on your own time which you can use community help for if anybody’s got hints for you. I THINK I already linked you the guide Wyomingmist put together for it, but just in case, check it out if you haven’t yet. It’s good stuff. At this point I can’t address this in any more ways than I already have, so any further inquiries on this are probably going to go unresponded to so that we can focus on one thing at a time - that connection issue.


Okay sounds good.

Which IP address would you like me to route to for the test? I know that it says I have to have a destination address to test for.

When I begin this test. What kind of data spread are you looking for. I can run this thing for x amount of hops or tests here. How many do you need me to run.

Now onto the other one. A big “thank you from me”. Sincerely I cannot believe I over-looked that setting.

…and yes. I will look at their link. I did not see that. Thank you!! :smiley:

Update: on the link suggestion.

I did take a look at that link to the Guide you sent me. I want to thank you again!!!

RANDOM FPS LOSS IS SOLVED!! Thank you :smiley: :smiley: :smiley: It is actually gone!!

I went in, read the guide. Copied it down. Changed the Nvidia scaling mode to aspect ratio and PhysX to the GPU ONLY OPTION. After that. No more frame crashing. Game runs very smooth now :slight_smile:


Haha don’t thank me, thank Wyomingmist and the community, they’re the lovely folks who came up with the methods and put all that information together. Glad this is resolved finally, as I know you’ve had problems for a very long time with it. Also, thank you for letting us know exactly what step handled this! I’m going to keep an eye out for future reports.

Regarding the IP address for your test and how to run it, there is a network graph in game (Ctrl+Shift+N) - when you are having the problems, you’re going to open that and copy down the IP address in the top right. Information on how to edit this address is in the WinMTR guide I sent you earlier. Then, run the winMTR using this address for one game while you are having problems. If you post the results of that single test, we will scope it out.


Good morning.

I did take a look at the test thing here. I should ask. Do i need the numbers after the " : " from the adress or not. It gives me an error message if I do.

If I put in the numbers before the " : " It wont even give me a reading. So I am wondering here how we should go about this.

Thank you!


The will want to omit the colon and the numbers that come after that. That is going to be the port and the test will only require the the IP address.


I just ran it again the following address ranges with No response from the servers.

WinMTR does NOT have a port number entry field on it.


That is correct, there is no port field which is why we only need the IP address. With that said, if we’re only getting No response from the servers then this is likely an indication that the test is being blocked by security either on the computer or the router\modem. This is likely also why the previous pathping tests only showed up with 1 hop.

One thing we did notice with your previous looking glass results are these hops here:

15.|-- port3-2-2.bng01.lncl01-ne.us.windstream. net 80.0% 10 12713 12706 12698 12713 10.0
15.|-- port3-2-2.bng01.lncl01-ne.us.windstream. net 90.0% 10 13391 13391 13391 13391 0.0

Its likely that the packet loss here is just going to be shaping on those nodes however we are going to want to try to get something to compare and make sure. If you have a separate router\modem, then we’d like to try bypassing the router altogether and run the WinMTR while connected directly to the modem.

We can also try running a traceroute using the IPs you found and see if we can get any more info from that.


How do you suggest we should go about this? The company I have out here. Comes out of a service office about 30 miles away and they did try this with me when they were out there. It was the same type of packet loss.

If it is on their end. Which it more than likely appears to be, with this information you have provided me. . What would you like me to ask of them to do for me?

Thank you! :slight_smile:


If it turns out to be a routing issue going through those hops then it would be on the ISP to see if they’re able to advertise a different route for the connection or look into those hops specifically to see if there’s an issue that can be resolved.

As far as routing goes, the only way to really go about changing it yourself would be to either test with a VPN or with a different connection altogether. VPNs aren’t something we generally support and so if its something you wanted to try, you’d have to do the research on the options available. Many usually have a free trial (usually with a bandwidth limit) that would let you test for free. As far as a different connection goes, if you or someone you know has a phone and data plan that supports tethering, we could try the mobile connection and see if we notice any difference. Either of these steps could potentially help us narrow down the issue and determine if the problem is the routing.