Home > Uncategorized > Review of ATT Wireless HSDPA and Verizon Wireless EVDO Rev A.

Review of ATT Wireless HSDPA and Verizon Wireless EVDO Rev A.

September 16th, 2009 Leave a comment Go to comments

Today I brought home a new ATT USBConnect Mercury card to test out the service in comparison to my trusty Dell Wireless 5720 EVDO Rev-A card built into my Latitude D630 (which is about 18 months old now).

Not wanting to pollute my primary work laptop with extra cruft, I installed the ATT card software on a spare Dell D800 I had laying around for test purposes.

Here is a screenshot of the ATT Communication Manager as connected from the master bedroom of my house in Beaverton/Hillsboro Oregon:

ATT Communication Manager

As you can see, the signal is decent, but not right under a tower.

The first test as always is to ping my favorite IP address.  Sorry for the long paste here, but it is important to see how the latency varies over time.  From this test (and numerous others earlier in the day from work) I was not very impressed with the latency of the card or the consistency in the latency (jitter).

C:\Documents and Settings\Administrator>ping 4.2.2.1 -t
Pinging 4.2.2.1 with 32 bytes of data:
Reply from 4.2.2.1: bytes=32 time=318ms TTL=53
Reply from 4.2.2.1: bytes=32 time=388ms TTL=53
Reply from 4.2.2.1: bytes=32 time=386ms TTL=53
Reply from 4.2.2.1: bytes=32 time=345ms TTL=53
Reply from 4.2.2.1: bytes=32 time=384ms TTL=53
Reply from 4.2.2.1: bytes=32 time=422ms TTL=53
Reply from 4.2.2.1: bytes=32 time=311ms TTL=53
Reply from 4.2.2.1: bytes=32 time=339ms TTL=53
Reply from 4.2.2.1: bytes=32 time=338ms TTL=53
Reply from 4.2.2.1: bytes=32 time=336ms TTL=53
Reply from 4.2.2.1: bytes=32 time=365ms TTL=53
Reply from 4.2.2.1: bytes=32 time=323ms TTL=53
Reply from 4.2.2.1: bytes=32 time=362ms TTL=53
Reply from 4.2.2.1: bytes=32 time=320ms TTL=53
Reply from 4.2.2.1: bytes=32 time=409ms TTL=53
Reply from 4.2.2.1: bytes=32 time=397ms TTL=53
Reply from 4.2.2.1: bytes=32 time=276ms TTL=53
Reply from 4.2.2.1: bytes=32 time=285ms TTL=53
Reply from 4.2.2.1: bytes=32 time=353ms TTL=53
Reply from 4.2.2.1: bytes=32 time=322ms TTL=53
Reply from 4.2.2.1: bytes=32 time=350ms TTL=53
Reply from 4.2.2.1: bytes=32 time=309ms TTL=53
Reply from 4.2.2.1: bytes=32 time=417ms TTL=53
Reply from 4.2.2.1: bytes=32 time=266ms TTL=53
Reply from 4.2.2.1: bytes=32 time=304ms TTL=53
Reply from 4.2.2.1: bytes=32 time=515ms TTL=53
Reply from 4.2.2.1: bytes=32 time=94ms TTL=53
Reply from 4.2.2.1: bytes=32 time=102ms TTL=53
Reply from 4.2.2.1: bytes=32 time=101ms TTL=53
Reply from 4.2.2.1: bytes=32 time=99ms TTL=53
Reply from 4.2.2.1: bytes=32 time=1056ms TTL=53
Reply from 4.2.2.1: bytes=32 time=369ms TTL=53
Reply from 4.2.2.1: bytes=32 time=353ms TTL=53
Reply from 4.2.2.1: bytes=32 time=431ms TTL=53
Reply from 4.2.2.1: bytes=32 time=390ms TTL=53
Reply from 4.2.2.1: bytes=32 time=308ms TTL=53
Reply from 4.2.2.1: bytes=32 time=337ms TTL=53
Ping statistics for 4.2.2.1:
    Packets: Sent = 37, Received = 37, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 94ms, Maximum = 1056ms, Average = 345ms
Control-C
^C
C:\Documents and Settings\Administrator>

The next test up was to see how fast the download/upload performance would be.  For this purpose I used Speedtest.net:

Speedtest.net ATT Test From Home

Hmm, that is certainly nothing to write home about, but not absolutely horrible for a mobile broadband card.

After checking latency and bandwidth, I moved on to test the maximum MTU size the connection would support.  Some applications are finicky about MTU sizes (especially UDP based ones).  I found that on ATT Wireless, the largest packet size it would support was 1450 bytes (note that in Windows ping tool below you specify this as the ICMP payload size of 1422 to which it adds 8 bytes of ICMP header and 20 bytes of IP header).

C:\Documents and Settings\Administrator>ping 4.2.2.1 -f -l 1422
Pinging 4.2.2.1 with 1422 bytes of data:
Reply from 4.2.2.1: bytes=1422 time=1021ms TTL=53
Reply from 4.2.2.1: bytes=1422 time=167ms TTL=53
Reply from 4.2.2.1: bytes=1422 time=178ms TTL=53
Reply from 4.2.2.1: bytes=1422 time=167ms TTL=53
Ping statistics for 4.2.2.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 167ms, Maximum = 1021ms, Average = 383ms
C:\Documents and Settings\Administrator>

The Verizon test

Here is the same ping test from the verizon card in my Dell Latitude D630:

C:\Users\eric.rosenberry>ping 4.2.2.1 -t
C:\Users\eric.rosenberry>ping 4.2.2.1 -t Pinging 4.2.2.1 with 32 bytes of data: Reply from 4.2.2.1: bytes=32 time=87ms TTL=49 Reply from 4.2.2.1: bytes=32 time=87ms TTL=49 Reply from 4.2.2.1: bytes=32 time=90ms TTL=49 Reply from 4.2.2.1: bytes=32 time=87ms TTL=49 Reply from 4.2.2.1: bytes=32 time=85ms TTL=49 Reply from 4.2.2.1: bytes=32 time=92ms TTL=49 Reply from 4.2.2.1: bytes=32 time=88ms TTL=49 Reply from 4.2.2.1: bytes=32 time=86ms TTL=49 Reply from 4.2.2.1: bytes=32 time=90ms TTL=49 Reply from 4.2.2.1: bytes=32 time=84ms TTL=49 Reply from 4.2.2.1: bytes=32 time=89ms TTL=49 Reply from 4.2.2.1: bytes=32 time=88ms TTL=49 Reply from 4.2.2.1: bytes=32 time=86ms TTL=49 Reply from 4.2.2.1: bytes=32 time=91ms TTL=49 Reply from 4.2.2.1: bytes=32 time=87ms TTL=49 Reply from 4.2.2.1: bytes=32 time=113ms TTL=49 Reply from 4.2.2.1: bytes=32 time=97ms TTL=49 Reply from 4.2.2.1: bytes=32 time=95ms TTL=49 Reply from 4.2.2.1: bytes=32 time=85ms TTL=49 Reply from 4.2.2.1: bytes=32 time=90ms TTL=49 Reply from 4.2.2.1: bytes=32 time=88ms TTL=49 Reply from 4.2.2.1: bytes=32 time=88ms TTL=49 Reply from 4.2.2.1: bytes=32 time=92ms TTL=49 Reply from 4.2.2.1: bytes=32 time=92ms TTL=49 Reply from 4.2.2.1: bytes=32 time=87ms TTL=49 Reply from 4.2.2.1: bytes=32 time=85ms TTL=49 Reply from 4.2.2.1: bytes=32 time=89ms TTL=49 Reply from 4.2.2.1: bytes=32 time=86ms TTL=49 Reply from 4.2.2.1: bytes=32 time=89ms TTL=49 Reply from 4.2.2.1: bytes=32 time=86ms TTL=49 Reply from 4.2.2.1: bytes=32 time=89ms TTL=49 Reply from 4.2.2.1: bytes=32 time=85ms TTL=49 Ping statistics for 4.2.2.1: Packets: Sent = 32, Received = 32, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 84ms, Maximum = 113ms, Average = 89ms Control-C ^C C:\Users\eric.rosenberry>

Note how much lower that is than the ATT HSDPA card!  An average of 89ms vs 345!  Verizon’s max ping time is nearly the same as ATT’s best!

How about the speed test?

Verizon Wireless Speedtest From HomeIt is still not great, but it is a bit better than ATT.  I often wonder how many of these speed test sites actually have enough bandwidth to provide realistic tests?

When testing the MTU size capabilities, I was plesently surprised to find that the Verizon EVDO card allowed full 1500 byte packets!

Wrap up

I feel I must point out the issues with my testing before drawing any conclusions:

  • My EVDO card is built into my Dell D630 and has diversity antennas spatially separated in the screen that are probably larger than the one in the ATT dongle.  I could get a card that would work with ATT for my D630 to do more apples-to-apples testing.
  • I only tested from a single location.  Wireless service is incredibly location dependent.  ATT could happen to have weaker signal at this particular location than Verizon (though I actually got similar results at my office earlier in the day in downtown Portland which provides a second data point).
  • Load on my particular tower may happen to have been heavy at the time of my testing, so these types of results are only useful in aggregate when enough samples are collected to be statistically significant.

It is also worth noting that anecdotally, browsing on the ATT card was painfully slow, where browsing on the Verizon card was pretty good.  I started this blog post on the ATT card and then switched over to the Verizon card to finish it.

Other things that can impact performance include:

  • Type of gear deployed on the tower you are connecting to (is it HSDPA capable)
  • Signal strength
  • Number of carrier channels deployed on the tower in question
  • Amount of other users on the tower (density)
  • The time of day (rush hour gets a lot of use)
  • The back-haul capacity from the tower (is it connected by one or two T-1’s, or do they have DS-3/OC-3 back-hauls?)

So my conclusion?  If purchasing a broadband card for myself I would definetly choose the Verizon card over the ATT card no questions asked.  In Portland Oregon, Verizon Wireless has a network that is extremely difficult to beat!

-Eric

Categories: Uncategorized Tags:
  1. September 17th, 2009 at 09:48 | #1

    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.

  2. September 17th, 2009 at 11:32 | #2

    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

  1. No trackbacks yet.