High Latency and Packet Loss

I have similar problems, I have a higher ping (I used to have a ping of 25 and now I have a 38 ping) And I have a constant packet loss .. And all since Friday.

@HaterCZ Hope we get an answer from the support soon. I'm waiting 2 days already for a reply on the ticket I opened, I'll keep you posted if I find a solution.

Let me know as as well if you find a fix on your side too.

THIS is not possible .. My latency has increased again !! It's not my fault. 

It's been already 3 days with not being able to use my Shadow and no reply from the ticket or here... Great.

Let's not beat about the bush, there are some serious issues lately. May I ask why tickets are being ignored? We shouldn't have to be sorting out issues, that's your job.

@gabkivitz@HaterCZ@dario90vlcshadow@Waspiflab 

I know you're likely convinced that network problems are on Shadow’s data center end, but there is actually no way for us to prove that one way or the other.

I'm not asking you to take what I'm saying here at face value, but I am asking that you seek a 2nd opinion from a network professional if you have doubts.

In terms of network quality, your local equipment and connectivity type come into play (such as Ethernet vs. WiFi, router/modem equipment issues, even software/driver/firmware versions on the local device(s) you're using). You should ALWAYS evaluate Internet connectivity issues using a wired Ethernet connection, no matter how awesome you think your 5Ghz WiFi is (and it might be, but you can't rely on that).

People tend to think that there are two parties involved in the network "transaction" - their ISP and Shadow’s. That can be the case, but it's more common to have at least one other ISP involved along the Internet path (route) between you and Shadow’s data center in a given region.

The TL;DR is that congestion (data overload) can happen anywhere along the Internet path (and more commonly happens during "prime time"), and it's difficult to know "where" that is happening for the type of traffic used by game streaming services. It's also important to point out, that for people with different ISPs than yours (and sometimes even with the same ISP), their path to the data center might be completely different from yours, up until the very "end" (at Shadow’s entry point). In other words, Paris can be peachy for hundreds (or thousands) of Shadow users, while at the same time being problematic for hundreds/thousands of others, depending on the latters' condition of the Internet path.

If sessions with Paris are problematic, all it means is that "something" along the Internet path between you and the Shadow system is causing a problem. While it is possible that Shadow’s own ISP is the source of the problem, it is much more likely that there is something else (such as a link controlled by another ISP) "in the middle" causing it. If the problem source were to be Shadow’s own ISP, that would impact larger numbers of people, and would be very "visible" to both Shadow and the ISP...meaning they'd take action to remediate it.

ISPs are aware when their own links are congested, and can sometimes reroute traffic to bypass problems. However, that also means the traffic could take a longer-than-normal route to its destination, making things slower. If ISPs have links which are chronically congested, they should be taking action to improve those links...but that isn't something that can necessarily happen quickly.

It is a common dilemma for all cloud gaming services, and we'll always see the posts of "fix your damn servers" from the less-knowledgeable folks experiencing network problems. It’s a bit like living on one end of a city, with your favorite store on the other end…and complaining to the store when it takes you 20 minutes instead of the usual 10 to travel to it. There are some scenarios where it might be the store’s “fault,” but it likely isn’t.

"BUT WAIT! I'm using [my favorite traceroute/ping/pathping utility] which PROVES the problem is at Shadow’s end!" ...this would be great, if it were possible...but it is not, and here's why: Game streaming services including Shadow use an efficient form of data transfer using UDP-based streaming protocols. UDP is fast and efficient, because it does not include acknowledgements (verification) that the other side received the data as part of the "conversation." The "problem" with UDP, is that link testing can only happen between two points, which your friendly network/systems engineer has control over.

Here's a "visual" example. Let's say the internet path from your house to Shadow went from point A to point G. A is your computer (specifically the Shadow app) connected to the ISP device at your house, and G is Shadow’s streamer in their data center. Traffic is passed along by other "hops" (routers or similar devices) along the path, B C D E and F. When the Shadow app is reporting packet loss, that means it knows about data that was sent from Shadow (G), which wasn't received by your computer (A). So then, how do you know where that loss occurred - was it at B, C, D, E, or F ... or some combination of those?

With traceroute utilities, you can actually measure (to a point) how certain types of data are flowing between those points (the most meaningful being a measure of latency, which is “electronic distance”). However, with UDP protocols, this is not possible. To properly measure UDP data between all of the devices, we would need to control all of them, in order to configure UDP senders/receivers on them. In other words, UDP loss between A and G might be happening at any of those points, but in order to determine which one, we'd need to test UDP between A and B, A and C, A and D, A and E, and A and F. The ONLY way we could to that, is if we had control of those B through F devices. We don't. Some folks see UDP options in traceroute utilities (like PingPlotter), but that is something different. That is sending a UDP probe to the hops along the path, and measuring responses to those probes. That's not what we need - we'd need those hops to actually send streams of UDP data to us, and track whether that data made it or not.

There is a nuance with Shadow that is different from other providers, in that they also offer a TCP-based streaming protocol option. If your experience is better when using that option, that’s another indication that “something in the middle” is interfering with UDP streaming traffic.

I cannot prove the problem is not at Shadow’s [isp] end; but at the same time, you cannot prove that it is. Without proof, it's all speculation/assumptions.

It should also be noted, that UDP traffic can be treated differently [by ISPs] over congested links than other traffic. In plain English, UDP is one of the first things to get "thrown away" (discarded). Shadow and other game streaming services, rely on relatively high-bitrate UDP streams, which transfer more data than "simpler" TV/movie streaming services like Netflix, even in 4K.

Ever since the migration, my latency went from 17-20 to 40-50. I am in the Santa Clara server area. This is nuts. I used the shadow speed test that says I should be at 17. Not sure whats going on. I reset my internet a few times same issue.