• Ps4 Download In Rest Mode

Game downloads on PS4 have a reputation of being very slow, with many peoplereporting downloads being an order of magnitude faster on Steam orXbox. This had long been on my list of things to look into, but ata pretty low priority. After all, the PS4 operating system isbased on a reasonably modern FreeBSD (9.0), so there should not beany crippling issues in the TCP stack. The implication is that theproblem is something boring, like an inadequately dimensioned CDN.But then I heard that people were successfully using local HTTPproxies as a workaround. It should be pretty rare for that toactually help with download speeds, which made this sound like amuch more interesting problem.This is going to be a long-winded technical post.

So, I'm downloading a game right now on PS4, and I will probably leave the console powered for the night, but I want to know if it will auto shut-off when the download will end, I don't wanna really leave the console powered for no reason for 16 hours or so until I'll come home from work.

If you're notinterested in the details of the investigation but just want arecommendation on speeding up PS4 downloads, skip straight to the.BackgroundBefore running any experiments, it's good to have a mental modelof how the thing we're testing works, and where the problems mightbe. If nothing else, it will guide the initial experiment design.The speed of a steady-state TCP connection is basically defined bythree numbers. The amount of data the client is will to receive ona single round-trip (TCP receive window), the amount of data theserver is willing to send on a single round-trip (TCP congestionwindow), and the round trip latency between the client and the server (RTT).To a first approximation, the connection speed will be:speed = min(rwin, cwin) / RTTWith this model, how could a proxy speed up the connection? Well,with a proxy the original connection will be split into two mostlyindependent parts; one connection between the client and theproxy, and another between the proxy and the server.

The speed ofthe end-to-end connection will be determined by the slower ofthose two independent connections:speedproxyclient = min(client rwin, proxy cwin) / client-proxy RTTspeedserverproxy = min(proxy rwin, server cwin) / proxy-server RTTspeed = min(speedproxyclient, speedserverproxy)With a local proxy the client-proxy RTT will be very low; thatconnection is almost guaranteed to be the faster one. Theimprovement will have to be from the server-proxy connection beingsomehow better than the direct client-server one.

The RTT will notchange, so there are just two options: either the client has amuch smaller receive window than the proxy, or the client issomehow causing the server's congestion window todecrease. The client is randomly dropping received packets,while the proxy isn't).Out of these two theories, the receive window one should be muchmore likely, so we should concentrate on it first. But that justreplaces our original question with a new one: why would theclient's receive window be so low that it becomes a noticeablebottleneck? There's a fairly limited number of causes for lowreceive windows that I've seen in the wild, and they don't reallyseem to fit here. Maybe the client doesn't support the TCP window scaling option,while the proxy does. Without window scaling, the receive windowwill be limited to 64kB. But since we know Sony started with aTCP stack that supports window scaling, they would have had togo out of their way to disable it.

Slow downloads, for no benefit. Maybe the actual downloader application is very slow. The operatingsystem is supposed to have a certain amount of buffer space availablefor each connection. If the network is delivering data to the OSfaster than the application is reading it, the buffer will start tofill up, and the OS will reduce the receive window as a formof back-pressure. But this can't be the reason; if the applicationis the bottleneck, it'll be a bottleneck with or without theproxy.

The operating system is trying to dynamically scale thereceive window to match the actual network conditions, butsomething is going wrong. This would be interesting, so it'swhat we're hoping to find.The initial theories are in place, let's get digging.Experiment #1For our first experiment, we'll start a PSN download on a baselinenon-Slim PS4, firmware 4.73. The network connection of the PS4 isbridged through a Linux machine, where we can add latency to thenetwork using tc netem. By varying the added latency,we should be able to find out two things: whether the receivewindow really is the bottleneck, and whether the receive windowis being automatically scaled by the operating system.This is what the client-server RTTs (measured from a packetcapture using TCP timestamps) look like for the experimentalperiod. Each dot represents 10 seconds of time for a singleconnection, with the Y axis showing the minimum RTT seen for thatconnection in those 10 seconds.The next graph shows the amount of data sent by the server in oneround trip in red, and the receive windows advertised by theclient in blue.First, since the blue dots are staying constantly at about 128kB,the operating system doesn't appear to be doing any kind ofreceive window scaling based on the RTT. (So much for thattheory).

Ps4 Download In Rest Mode

Though at the very right end of the graph the receivewindow shoots out to 650kB, so it isn't totallyfixed either.Second, is the receive window the bottleneck here? If so, theblue dots would be close to the red dots. This is the caseuntil about 10:50. And then mysteriously the bottleneck moves tothe server.So we didn't find quite what we were looking for, but there are acouple of very interesting things that are correlated with eventson the PS4.