PlayStation 4 (codename Orbis) technical hardware investigation (news and rumours)

Status
Not open for further replies.
It depends on the design and what's already in WebKit. Wondering if Sony will benefit from Apple's work one way or another.

I think most of Apple's energy saving work is in Safari rather than webkit. It think it would be hard to engineer these things in the webkit because the framework really has no concept of wider OS loads and has to work on multiple platforms. This is also part of the reason Google forked webkit into Blink for Chrome - they wanted to ditch all the legacy crap that comes with supporting other platforms, and they wanted a different model for security.

Unless Sony have some power throttling for the web browser I can't see how the power draw is ever going to meaningfully change. The fact that the available cores are relatively low-performance, that HTML is becoming more complicated and the fact that web browsing is probably a fairly niche use of the console means it'll never really be a priority for Sony to spend significant engineering effort in making it shave a few watts off the power draw.

Because it's plugged into a wall :yep2:
 
Noticed last night that Sony has adjusted the auto-generated recent pages page to support a "delete all" option which seems to work. So it is possible to fully delete the browser history now though it still is splattered over two sections (history, recent pages).
 
I think most of Apple's energy saving work is in Safari rather than webkit. It think it would be hard to engineer these things in the webkit because the framework really has no concept of wider OS loads and has to work on multiple platforms. This is also part of the reason Google forked webkit into Blink for Chrome - they wanted to ditch all the legacy crap that comes with supporting other platforms, and they wanted a different model for security.

Unless Sony have some power throttling for the web browser I can't see how the power draw is ever going to meaningfully change. The fact that the available cores are relatively low-performance, that HTML is becoming more complicated and the fact that web browsing is probably a fairly niche use of the console means it'll never really be a priority for Sony to spend significant engineering effort in making it shave a few watts off the power draw.

Because it's plugged into a wall :yep2:

*shrug* I might get to dig into WebKit if I take up a prospective project. Will have better idea.
 
It has been a long standing issue that PSN dowload speeds are often abysmal. The commonly offered solution is to switch to using Google's name servers instead of your local ISP. Out of frustration at my Far Cry 4 download taking over 12 hours to fully complete I decided to test changing name servers. After doing so, the last 2GB downloaded super fast.

So is this an issue with Akamai's CDN being poorly setup in my region and redirecting traffic to either network remote or overloaded servers? I can't seeing this as a pure DNS issue as once the initial lookups are done, the zone files will be cached and no more lookups needed. Presumably swithing to Google's DNS means I get what would be the CDN servers closest to Google.

Cheers

[edit]This may be the wrong thread, just was not sure where it should go (mods, please move if need be)[/edit]
 
It has been a long standing issue that PSN dowload speeds are often abysmal. The commonly offered solution is to switch to using Google's name servers instead of your local ISP. Out of frustration at my Far Cry 4 download taking over 12 hours to fully complete I decided to test changing name servers. After doing so, the last 2GB downloaded super fast.
Just curious. How do you do that?
 
The DNS servers are discussed here:

https://developers.google.com/speed/public-dns/

You can change it on the PS4 by going into the network settings and choosing "manual" for DNS and then entering Google's. The main downside is that this means that you have to implicitly trust Google. Theoretically they can return whatever IPs they want to (could return their own proxy server IPs instead of what you asked for) and they also will know every DNS request you make (which is probably why they run these open name servers in the first place). It seems safe to assume that your domain lookup statistics will end up in their ad system.

Cheers
 
The commonly offered solution is to switch to using Google's name servers instead of your local ISP.

How does this improve download speeds? DNS servers convert www.google.com to 74.125.230.101. Once the DNS provides the actual IP of the download server your PS4 will connect to it directly. Traffic isn't routed via the DNS server o_O
 
It affects download speeds (presumably) because you end up being served different IPs in Akamai's CDN than you would if you used your local DNS servers. Since you are using Google's DNS servers, their physical location will probably decide where the returned IPs are located. Whether that works out to being closer network-wise or just better connected (backbone) I do not know but whatever my local ISP is getting back from Akamai for PSN consistently sucks. Making the switch this morning was light and day. Next time I do a large download I will try it again and see if it continues to make a major difference.

You know this Dsoup but the IP returned for "www.google.com" is pulled from a large range of possible addresses depending on where you are and luck of the draw. It will be the same for Akamai servers (who I believe is the Sony CDN provider).

Cheers
 
It affects download speeds (presumably) because you end up being served different IPs in Akamai's CDN than you would if you used your local DNS servers. Since you are using Google's DNS servers, their physical location will probably decide where the returned IPs are located.

Google's DNS servers are also localised. When your system sends a name to resolve to 8.8.8.8 and 8.8.4.4, they redirect to a local server using anycast routing based upon your IP.
 
Which is exactly what I have been saying DSoup. My theory is that whatever is being returned from Google's name servers is different from that of my local ISP. I am having to assume this means that Akamai's geolocation or peering or something is messed up in a lot of areas. Or it could be as simple as my local ISP overriding Akamai's TTL (caching lookups for longer so more of us overload the same servers) and Google doesn't (so better distribution of requests).

I'd have to setup a packet sniffer on my local LAN to be 100% sure but based on my experience this morning and general experience of others it makes sense to me.

Cheers
 
Which is exactly what I have been saying DSoup. My theory is that whatever is being returned from Google's name servers is different from that of my local ISP.

Possible but less and less likely as Google deploy more locale DNS servers. But even if Google's not-so-local DNS server provided a difference target server IP from your ISP's DNS server (DNS tables are regionalised), routers themselves have regionalised routing tables. I don't know where you are but were you try to connect to an Akamai server far from you, one of more of the routers between you and it would almost certainly redirect you to local server anyway. That's their job ;)
 
https://blogs.akamai.com/2013/04/se...ormance-good-for-mitigating-ddos-part-ii.html

Moreover, Akamai's system is based on DNS, not BGP. We can, and frequently do, direct "east London users to Node A and west London users to Node B" from the same network. Or even "east London users to Node A for Customer Z and west London users to Node B for Customer Y" from the same or multiple networks.

More here:

http://www.akamai.com/dl/feature_sheets/Akamai_Global_Traffic_Management.pdf

So they are not returning a single IP address and letting routing sort it out, they are choosing specific ones from the CDN based on where you are.

Whatever IPs are being returned by Google's name servers are presumably better (less loaded, closer, better connected, something) than what my local ISP is returning.

Cheers
 
If you're curious you can use DNS comparison and test software that will check the results and latencies of multiple DNS servers. It's intended for checking change tables are being propagated properly but it's useful to troubleshoot oddities like this.

So they are not returning a single IP address and letting routing sort it out, they are choosing specific ones from the CDN based on where you are.
And because your IP dictates your local Akamai server it doesn't matter which DNS service you use.
 
DSoup, can you point at documentation that explains your argument? The blog / marketting PDF I just linked to specifically said they rely on DNS and not anycast routing to decide what server you talk to.

I may be wrong but for the DNS part of the process I believe we are talking about a caching server so it is the local name server's IP, not mine that Akamai will see initially. So they will be deciding what IPs should be returned (either directly as A records or indirectly via CNAMEs) based on the IP of the name server I use. Even if those IPs are just load balancers, they are likely different load balancers for each case, no?

Cheers
 
DSoup, can you point at documentation that explains your argument?

Well all of the internet's protocols are freely available but Wikipedia has good articles on DNS and BGP, which are the key ones here - they deal with DNS operation and routing.

The blog / marketting PDF I just linked to specifically said they rely on DNS and not anycast routing to decide what server you talk to.

Google use anycast routing to provide DNS functionality. That is you contact their 8.8.8.8/8.8.4.4 server and it redirects you to the most geo-locally available server, which then resolves a name into an IP. The Akamai document you linked states:

Akamai said:
The Global Traffic Management service integrates with a customer’s Web infrastructure using the Domain Name Service (DNS). End users rely on DNS to determine the location of a site on the Internet.

What this means is the initial Akamai server IP address you resolve will depend on the DNS server used. You use Google DNS which just redirects to a local server to you. Regardless of what Akamai server you initially connect too, it will also redirect you to the server with best availability based on your IP address. This is what is happening.
  1. Your PS4 asks Google's DNS server (8.8.8.8, 8.8.4.44) for Akamai's server IP.
  2. Google's master DNS server redirects that request to a locale Google DNS near to you.
  3. Google's local DNS server gives you an IP address for an Akamai server close to it.
  4. You connect to the Akamai server direct from your IP.
  5. Akamai's server immediately redirects you if there is a closer available server to you.
Whatever routers exist in the path between you and Akamai's server may make step 4 redundant anyway because Akamai propagate BGP (Border Gateway Protocol) tables on a regional basis for their servers. What this means is routing to Akamai servers, regardless of which specific Akamai server IP you are trying to reach, will be redirected by any BGP router.

Does that help?
 
Your assumption is that step 5 works perfectly. My assumption is that by step 5 something has gone wrong.

I live on the west coast and traffic has a choice of heading south through Seattle (via Group Telecom I think) to the backbone or east to Calgary where my ISP is based. I have no idea where in the network Google's servers are but I am guessing it is somewhere else than where my local name servers are located (hopefully within my ISP's network but likely in a machine room somewhere less regional). We apparently agree then that Google's name server may get different IPs back than my ISPs name servers.

Your assumption seems to be that all Akamai servers / load balancers know about all Akamai servers so that by step 5, everything should be equal. Since my experience suggests otherwise, my theory is that Akamai is relying more heavily on the initial DNS lookups and Google's DNS is getting better servers than my ISP is.

I am having trouble seeing how the BGP argument fits here. If you are saying traffic to whatever IP I get back will just be routed to the same node regardless, then a) that conflicts with what Akamai says they do and b) makes the initial DNS approach unnecessary.

Cheers
 
Your assumption is that step 5 works perfectly. My assumption is that by step 5 something has gone wrong. ... ... ... ... ... We apparently agree then that Google's name server may get different IPs back than my ISPs name servers.

Yes and no. DNS tables, like routing tables, are regionalised. If you use a DNS service where the nearest server is way out of town (in global terms) then the resolve will provide IP addresses for servers which are local to the DNS server but not to you.

However almost all internet traffic is built on the principle that traffic should be kept to a minimum where possible and that's why there are literally dozens of protocols in place to prevents accidental (or deliberate) "long routing" - especially when it comes to significant traffic.

Your assumption seems to be that all Akamai servers / load balancers know about all Akamai servers so that by step 5, everything should be equal. Since my experience suggests otherwise, my theory is that Akamai is relying more heavily on the initial DNS lookups and Google's DNS is getting better servers than my ISP is.

You don't need to theorycraft this, just use a visual traceroute with geolocation reporting. That'll show the exact routing and re-routing.

I am having trouble seeing how the BGP argument fits here. If you are saying traffic to whatever IP I get back will just be routed to the same node regardless, then a) that conflicts with what Akamai says they do and b) makes the initial DNS approach unnecessary.
If you look at the link in my last post, Akamai explains how (and why) they employ BGP routing. Any large infrastructure will be doing this, it's less about server load balancing than it is about traffic reduction.
 
You don't need to theorycraft this, just use a visual traceroute with geolocation reporting. That'll show the exact routing and re-routing.

Unfortunately, to do that I would need to set up a packet sniffer and catch my PS4 during the initial DNS lookup. And to be honest, I'd rather be playing the game that it took me 12 hours to download.

=)

Also, ICMP traffic may be treated differently (dropped, de-prioritized) than regular TCP/IP or UDP traffic.

If you look at the link in my last post, Akamai explains how (and why) they employ BGP routing. Any large infrastructure will be doing this, it's less about server load balancing than it is about traffic reduction.

That document seems to be pointing out a large number of potential networking issues as a marketting pitch / threat to ISPs to peer with them or else suffer the consequences. Maybe this issue is related to either my ISP or somebody upstream fighting over peering fees and it depends on which DNS server I use (so what IP I get back) as to whether I bump against that?

Is your argument DSoup that using Google's DNS is a placebo?

Cheers
 
Unfortunately, to do that I would need to set up a packet sniffer and catch my PS4 during the initial DNS lookup. And to be honest, I'd rather be playing the game that it took me 12 hours to download. =)

Ha! Fair enough :)

Is your argument DSoup that using Google's DNS is a placebo?

I'd more consider an explanation about how the internet works than an argument ;) What you're describing - better download performance when accessing Akamai servers from an alternative DNS - simply shouldn't happen. Regardless of how the initial Akamai server IP is passed to you (from local or far away DNS server), the backbone routers and Akamai's own internal referral system for their 147,000 servers will redirect to you a local server based on your actual IP.

Even if your ISP's DNS server is badly setup and referring you to an Akamai server on the other side of the planet, 400 hops and 10,000ms latency away, internet routing and Akamai's systems would make sure you end up downloading from an available local server. Now it could be you are equidistance, in internet terms, between two or more Akamai servers and sometimes are get a particularly heavily loaded server but this shouldn't happen consistently.
 
Status
Not open for further replies.
Back
Top