Comments on: Review of ATT Wireless HSDPA and Verizon Wireless EVDO Rev A. http://www.bitplumber.net/2009/09/review-of-att-wireless-hsdpa-and-verizon-wireless-evdo-rev-a/ A place for Google to index my learnings Fri, 06 Jan 2012 08:18:20 +0000 hourly 1 http://wordpress.org/?v=3.3 By: EVDOalex http://www.bitplumber.net/2009/09/review-of-att-wireless-hsdpa-and-verizon-wireless-evdo-rev-a/comment-page-1/#comment-4123 EVDOalex Thu, 17 Sep 2009 19:32:17 +0000 http://www.bitplumber.net/?p=403#comment-4123 i noticed that the screenshot for att connection manager shows -88 signal strength. thats not great. perhaps all you need is a high gain antenna for the USB mercury? check these: http://bit.ly/1IcP1V i noticed that the screenshot for att connection manager shows -88 signal strength. thats not great.
perhaps all you need is a high gain antenna for the USB mercury? check these: http://bit.ly/1IcP1V

]]> By: Mithrandir http://www.bitplumber.net/2009/09/review-of-att-wireless-hsdpa-and-verizon-wireless-evdo-rev-a/comment-page-1/#comment-4120 Mithrandir Thu, 17 Sep 2009 17:48:40 +0000 http://www.bitplumber.net/?p=403#comment-4120 Those AT&T results are consistent with what I experience with my iPhone. The bandwidth is fine, but the latency is huge. It takes a very long time to load nytimes.com, not because the page is large, or because the processor is slow, but because it contains so many different resources, each of which must be fetched individually, which requires separate server round trips. Lets assume that there are only two servers to worry about, and they're infinitely fast: the front page server, and the static resource server (serves images, css and javascript). The browser looks up nytimes.com in dns, makes the HTTP request, loads the HTML, then starts fetching resources that the HTML document needs. The first resource requires a DNS lookup for the static resource server, and opens a TCP session with the server, requesting the first resource. Then (assuming keepalives) it asks for the next, and the next. It can have a limited number of parallel TCP streams, which helps a bit. So, for the first request from each server, we have: DNS, handshake, http. That's three round trips (the HTTP request can be the payload on the third leg of the handshake), at one full second given the latencies on the AT&T network. Then we do it again, for the first request to the resource server. After that, it's just one round-trip for each resource, most of which are only a couple KB. But there are like 80 additional resources on that page. The reality is more complex, of course. There aren't two servers. There are about a dozen requests to distinct advertising and tracking servers, each of which requires a DNS lookup, handshake, and HTTP request. Which is why it takes around a full minute to load the NY Times web page on my iPhone over 3G, but around half that over Wifi. Partially, that's poor site design. NYTimes.com is one of the heaviest landing pages on the web. They could cut their high latency load time by 90% by consolidating their images into an image bundle and their front-page Javascript into a single resource. Those things aren't trivial to maintain for a dynamic page like that, but I'm pretty sure it would be worth it. I'd be very curious to know what causes the latency disparity between AT&T and Verizon. I'm sure the AT&T network has more broadband users than Verizon, and iPhone users tend to have more demanding usage patterns than users of other devices, so I wonder if it's mostly a requests per tower bottleneck. Those AT&T results are consistent with what I experience with my iPhone. The bandwidth is fine, but the latency is huge. It takes a very long time to load nytimes.com, not because the page is large, or because the processor is slow, but because it contains so many different resources, each of which must be fetched individually, which requires separate server round trips.

Lets assume that there are only two servers to worry about, and they’re infinitely fast: the front page server, and the static resource server (serves images, css and javascript). The browser looks up nytimes.com in dns, makes the HTTP request, loads the HTML, then starts fetching resources that the HTML document needs. The first resource requires a DNS lookup for the static resource server, and opens a TCP session with the server, requesting the first resource. Then (assuming keepalives) it asks for the next, and the next. It can have a limited number of parallel TCP streams, which helps a bit.

So, for the first request from each server, we have: DNS, handshake, http. That’s three round trips (the HTTP request can be the payload on the third leg of the handshake), at one full second given the latencies on the AT&T network. Then we do it again, for the first request to the resource server.

After that, it’s just one round-trip for each resource, most of which are only a couple KB. But there are like 80 additional resources on that page.

The reality is more complex, of course. There aren’t two servers. There are about a dozen requests to distinct advertising and tracking servers, each of which requires a DNS lookup, handshake, and HTTP request. Which is why it takes around a full minute to load the NY Times web page on my iPhone over 3G, but around half that over Wifi.

Partially, that’s poor site design. NYTimes.com is one of the heaviest landing pages on the web. They could cut their high latency load time by 90% by consolidating their images into an image bundle and their front-page Javascript into a single resource. Those things aren’t trivial to maintain for a dynamic page like that, but I’m pretty sure it would be worth it.

I’d be very curious to know what causes the latency disparity between AT&T and Verizon. I’m sure the AT&T network has more broadband users than Verizon, and iPhone users tend to have more demanding usage patterns than users of other devices, so I wonder if it’s mostly a requests per tower bottleneck.

]]>