Prolixium dot com: News >> Blog >> Searching for “std”

I had a chance to try out one of the new Sierra Wireless IntelliGo mobile Wi-Fi hotspots from Road Runner Mobile, today. The Wi-Fi hotspot is actually just a little router with WiMAX, CDMA (EV-DO), and Wi-Fi radios. The WiMAX radio represents one of the two so-called 4G cellular technologies, the other being LTE.

The Road Runner Mobile service provided by Time Warner Cable is actually Clearwire's WiMAX service, which falls back to Sprint's EV-DO network (3G) when WiMAX isn't available. It might fall back to 1xRTT, too, if 3G isn't available, but I had no easy way of testing this (well, without driving deep into South Carolina).

IntelliGo

To set the stage, I can currently get around 2.7Mbps (megabits per second) with 79ms of varying latency on AT&T's UMTS network on a very good day.

For testing, I used wget to this URL and ran MTR to dax.

I first tried powering up this thing in my condo, and after what seemed like over 90 seconds of staring at the bootup logo, it started up.. but on Sprint's EV-DO network (at 80% signal strength)! I ran my tests anyway, and peaked around 1.3Mbps but averaging around 640Kbps. Latency sucked:

HOST: six                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. foobarz.lan                   0.0%     8    1.7   2.7   1.5  10.2   3.0
  2. 68.28.249.69                  0.0%     8  124.7 264.0 124.7 463.1 127.0
  3. 68.28.249.91                  0.0%     8  135.8 258.7 127.8 451.9 117.1
  4. 68.28.251.54                  0.0%     8  154.9 265.8 147.8 455.1 121.1
  5. 68.28.255.9                   0.0%     8  173.9 262.9 135.3 449.9 118.2
  6. ???                          100.0     8    0.0   0.0   0.0   0.0   0.0
  7. 68.28.253.69                  0.0%     8  134.1 236.0 124.6 419.1 107.7
  8. sl-crs3-fw-0-1-3-0.sprintlin  0.0%     8  169.0 229.2 122.0 383.1  85.1
  9. sl-crs1-fw-0-7-0-0.sprintlin  0.0%     8  141.2 228.7 125.8 379.7 101.2
 10. sl-st21-dal-1-0-0.sprintlink  0.0%     8  128.4 236.8 128.4 377.6  94.6
 11. dls-bb1-link.telia.net        0.0%     8  132.3 214.7 129.1 319.1  72.3
 12. atl-bb1-link.telia.net        0.0%     8  229.4 256.4 170.0 447.0  87.0
 13. ash-bb1-link.telia.net        0.0%     8  240.5 272.1 173.7 449.7 109.7
 14. voxel-ic-129445-ash-bb1.c.te 12.5%     8  192.0 259.2 167.7 418.9 104.3
 15. 0.te6-2.tsr1.ewr1.us.voxel.n 12.5%     8  176.8 276.4 165.7 525.4 124.9
 16. 842.te1-7.csr2.lga6.us.voxel 12.5%     8  168.0 297.1 168.0 607.8 145.9
 17. dax.prolixium.com            12.5%     8  203.5 277.2 181.6 558.1 132.8

I had to toggle the option in the web interface to force the unit to only use 4G service. Only after I did this, it barely got a WiMAX signal and got me online. The web interface indicated I had poor signal strength at -88dBm (it rated this at 10% - I guess this is why it automatically picked 3G initially), and I agreed. I could only get roughly 360Kbps and the latency was all over the place:

HOST: six                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. foobarz.lan                   0.0%     8    1.6   2.1   1.6   3.1   0.5
  2. 71-23-64-2.clt.clearwire-wmx 12.5%     8  276.1 190.1  87.4 485.0 144.0
  3. 71-22-7-161.clt.clearwire-wm  0.0%     8  211.2 289.6 111.3 703.8 216.9
  4. 66-192-62-1.static.twtelecom 12.5%     8   85.4 316.1  85.4 673.8 225.5
  5. ash1-pr1-ge-2-0-0-1.us.twtel  0.0%     8  265.2 266.7  95.9 574.1 183.7
  6. 0.te6-2.tsr1.ewr1.us.voxel.n  0.0%     8  155.2 231.1  81.1 474.5 126.4
  7. 842.te1-7.csr2.lga6.us.voxel  0.0%     8  125.2 200.7 125.2 374.8  79.8
  8. dax.prolixium.com             0.0%     8  124.6 167.3  98.2 297.7  76.1

DNS is slightly intercepted on the IntelliGo, since the PTR record for 192.168.0.1 was translated to $my_ssid.lan. No, foobarz is not my real SSID.

After driving around Ballantyne a little bit, I managed to figure out which tower was providing the WiMAX coverage for the area. It ended up being the one near Toringdon that's easily seen from I-485. I got the signal strength up to -47dBm (80%) by sitting in a parking lot of one of the office buildings in the area:

WiMAX Tower

I could have gotten closer by walking across the grass, but I figured the orientation of the antennas would result in worse signal strength as I got closer. Oh, maybe I was just lazy.

I managed to peak at 6.76Mbps down, while the transfer rate typically hovered around 5.5Mbps. Latency was a little better, too:

HOST: six                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. foobarz.lan                   0.0%     8    1.7   6.0   1.7  18.2   7.3
  2. 71-23-64-2.clt.clearwire-wmx  0.0%     8   66.1  78.1  65.3  94.4  12.4
  3. 71-22-7-161.clt.clearwire-wm  0.0%     8   76.0  77.1  61.1  97.6  12.2
  4. 66-192-62-1.static.twtelecom 12.5%     8   65.8  69.7  50.9  92.2  12.1
  5. ash1-pr1-ge-2-0-0-1.us.twtel  0.0%     8   80.7  84.3  79.8  97.2   5.5
  6. 0.te6-2.tsr1.ewr1.us.voxel.n  0.0%     8   85.6  90.7  74.8 107.6  10.0
  7. 842.te1-7.csr2.lga6.us.voxel 12.5%     8   60.7  82.5  60.7 102.9  17.0
  8. dax.prolixium.com             0.0%     8   86.5  92.7  82.1 105.9   9.9

Although not shown above, I managed to get one response back from the second hop (the other end of the PPP connection, no doubt) in 40ms. Supposedly LTE's RTT is in the 30s, so this certainly comes close!

Stopping at different points around Ballantyne with an average of around -57dBm got me between 3-4Mbps. Not too bad, but not that big of a jump over AT&T in the middle of the night (ie, no iPhone users).

The IntelliGo device itself is slightly disappointing. Battery life on the unit dropped to around 50% after 50 minutes of moderate use. The startup time before even starting the initialization of the radios is way too long (I mentioned 90 seconds earlier, but it could have been longer). Also, I don't know if it's just a result of the high frequency used by WiMAX (>2GHz) compared to other mobile networks or a problem with the IntelliGo itself, but I was disconnected left & right when driving and moving around. The kicker was hearing a beep (it makes certain noises for connecting & disconnecting from the mobile network, and when clients connect) consistently when I drove under overpasses!

In conclusion, I probably wouldn't buy one of these, but I don't travel too much, either. It's probably great for Internet access at airports and other public places where Wi-Fi is either not free or terribly congested.. as long as you've got WiMAX coverage, which doesn't seem to be too widespread, yet. Sprint's 3G isn't too shabby, though, but still pales in comparison to the speeds and latency of AT&T's UMTS network, even when congested with iPhones.

All you IPv6-heads, check this out:

 HOST: dax.prolixium.com                        Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. prolixium-2.tunnel.tserv4.nyc4.ipv6.he.net  0.0%    16    4.5   4.3   3.8   4.8   0.3
 2. gige-g3-8.core1.nyc4.he.net                 0.0%    16    2.7   1.8   1.1   2.7   0.5
 3. 10gigabitethernet3-1.core1.sjc2.he.net      0.0%    16   80.8  83.1  80.1  93.1   4.3
 4. gige-g1-1.core1.fmt1.he.net                 0.0%    16   91.6  83.8  80.7  91.6   3.5
 5. 100m-0-0.tserv1.fmt.ipv6.he.net             0.0%    16   81.6  81.4  80.9  82.4   0.4
 6. apnic-1-pt.tunnel.tserv1.fmt.ipv6.he.net    0.0%    16  256.2 256.3 255.6 257.2   0.5
 7. 2001:dc0:8000:23::2                         0.0%    16  455.6 455.5 453.6 458.6   1.4
 8. 2001:cc8:6201:1::2                          0.0%    16  713.1 724.2 711.5 869.9  40.3
 9. ge0-2-35.v6wlg0.acsdata.co.nz               0.0%    16  730.5 744.5 722.4 882.3  40.2
10. nzwlg01.sixxs.net                           0.0%    16  732.0 732.5 722.1 751.2   8.2

Yeah, it's the way it looks. One of the SixXS PoPs is getting transit from a New Zealand-based ISP that is (apparently) getting transit from a Hurricane Electric tunnel. I feel sorry for folks hanging off the nzwlg01 PoP :-(

I just can't get enough of these patches. Here's another one I threw together tonight that implements PMTU detection for MTR:

                             My traceroute  [v0.72]
neodymium (0.0.0.0)                                    Thu May 15 01:17:41 2008
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                       Packets               Pings
 Host                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. 90.66.42.1                        0.0%    16    0.2   0.3   0.2   0.5   0.1
 2. 90.66.43.4 [PMTU: 1446]           0.0%    15    2.2   1.6   1.5   2.2   0.2
 3. 99.50.161.222                     0.0%    15   79.9  79.8  79.5  80.1   0.2
 4. 90.42.7.1                         0.0%    15   81.1  81.1  80.7  82.2   0.4
 5. 90.27.15.2                        0.0%    15   81.8  81.6  81.4  82.2   0.2
 6. 90.27.118.188                     0.0%    15   83.2  83.6  83.2  84.2   0.3

More information here, as always.

I added decoding support to MTR for MPLS extensions to ICMP, today. Grab the patch here and read info here. It's based on some of the code in the NANOG traceroute patches and draft-ietf-mpls-icmp-02. It looks something like this with the curses interface (and only IPv4):

 Host                                                Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. br0.proton.prolixium.net                          0.0%    25   16.4   1.6   0.8  16.4   3.1
 2. ax0.scimitar.prolixium.net                        0.0%    24    2.3   2.1   1.5   5.7   0.8
 3. 73.16.200.1                                       0.0%    24    8.9   9.2   6.9  11.5   1.2
 4. GE-2-38-ur01.proctorrd.fl.westfl.comcast.net      0.0%    24    7.6   9.5   7.6  13.6   1.5
 5. te-8-1-ur01.palmerranch.fl.westfl.comcast.net     0.0%    24    8.5  10.2   8.1  15.9   1.8
 6. te-9-1-ar01.venice.fl.westfl.comcast.net          0.0%    24    8.1  10.3   8.0  20.6   2.6
 7. 12.124.85.25                                      0.0%    24   12.6  14.5  12.0  20.6   2.3
 8. tbr2.ormfl.ip.att.net [MPLS: Label 27758 Exp 0]   0.0%    24   29.0  26.1  23.8  29.8   1.7
 9. cr2.ormfl.ip.att.net [MPLS: Label 16735 Exp 0]    0.0%    24   24.5  26.1  23.7  41.8   4.1
10. cr1.attga.ip.att.net [MPLS: Label 16707 Exp 0]    0.0%    24   28.2  25.4  23.8  28.2   1.3
11. tbr1.attga.ip.att.net [MPLS: Label 27974 Exp 0]   0.0%    24   24.1  26.4  23.7  31.6   2.1
12. ggr4.attga.ip.att.net                             0.0%    24   24.2  45.4  22.4 225.8  57.4
13. 192.205.35.90                                     0.0%    24   30.3  29.9  28.4  34.3   1.4
14. nlayer.te1-1.ar2.DCA3.gblx.net                    0.0%    24   43.3  44.7  39.5  79.1   9.4
15. tge4-3.ar1.iad1.us.nlayer.net                     0.0%    24   41.2  48.9  39.9 102.5  16.9
16. g0-1.aggr2.iad1.us.nlayer.net                     0.0%    24   40.0  41.8  39.9  47.6   1.6
17. route-server.nlayer.net                           0.0%    24   57.0  41.7  39.3  57.0   3.5

It's based on MTR 0.72 (my mistake). I'll add one for 0.73 soon.

We all love MTR, the ICMP-based continuous traceroute tool for Unix. Since sometimes ICMP doesn't give you the whole picture when doing a traceroute, I went ahead and added preliminary UDP support:

% mtr -P udp --report dax.prolixium.com
HOST: nat                         Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. 10.83.192.1                   0.0%    10    6.9   7.3   5.9   9.2   1.0
  2. dstswr2-vlan2.rh.pswynj.cv.n  0.0%    10    6.9   9.1   6.2  20.5   4.3
  3. r3-ge1-1.mhe.prnynj.cv.net    0.0%    10   64.6  14.8   8.2  64.6  17.5
  4. rtr4-tg11-3.wan.prnynj.cv.ne  0.0%    10    8.2  10.1   7.7  14.2   2.4
  5. rtr1-tg11-1.in.nwrknjmd.cv.n  0.0%    10   11.5  10.7   9.0  13.1   1.5
  6. ???                          100.0    10    0.0   0.0   0.0   0.0   0.0
  7. 0.te6-4.tsr1.lga3.us.voxel.n  0.0%    10   10.1  12.8   9.6  18.4   2.7
  8. 0.te1-49.dsr1.lga6.us.voxel.  0.0%    10    9.7  14.0   9.5  35.4   7.8
  9. 0.ge0-1.esr2.b3.lga6.us.voxe  0.0%    10   14.9  15.3   9.5  42.7   9.9
 10. dax.prolixium.com             0.0%    10   10.9  12.8   9.8  22.7   3.9

The patches and more information can be found here. The prox3 patch breaks IPv6 support, mostly because the kernel doesn't deliver the IPv6 header to the application with raw sockets, and mostly I just haven't had time, yet.

I finally acquired up some more horsepower for my lab, the other day (since a single Athlon 64 couldn't handle 9x dynamips instances and 5x VMs). Other than the forcedeth driver (from linux-image-2.6.18-4-amd64) reading the MAC address in the wrong byte order, installation of Debian Lenny amd64 (testing) was uneventful. I found out shortly after that this happens to be resolved in the linux-image-2.6.21-2-amd64 package.

VMware Server 1.0.3 (build 44356) installed fine, after applying the recommended patch, downgrading module-init-tools and installing the following compatibility packages:

ia32-libs
lib32bz2-1.0
lib32gcc1
lib32ncurses5
lib32objc1
lib32readline5
lib32stdc++6
lib32z1
libc6-i386

However, starting any VM results in a host system hang, several seconds into the bootup process of the guest OS. The log displays the following:

Jul 16 20:42:13: vcpu-0| MONITOR PANIC: vcpu-0:DoubleFault @ 0x4020:0x8a3b4 (0x63,0x2cc0)
Jul 16 20:42:13: vcpu-0| Core dump with build build-44356
[...]
Jul 16 20:42:14: vcpu-0| Monitor Panic. Last Disk I/O was to the MBR
Jul 16 20:42:14: vcpu-0| Msg_Post: Error
Jul 16 20:42:14: vcpu-0| [msg.log.monpanic.beta] *** VMware Server internal monitor error ***
Jul 16 20:42:14: vcpu-0| vcpu-0:DoubleFault @ 0x4020:0x8a3b4 (0x63,0x2cc0)
Jul 16 20:42:14: vcpu-0| There is a problem in this version of VMware Server.

Seems to happen with the two guests I've tried, which are Red Hat Enterprise 5.0 Server and Debian/GNU Linux 4.0. Toying with noapic and other kernel arguments in the guest doesn't seem to help. I suspect something is going horribly wrong with the vmnet module, since that's the only VMware module that is resident at the time. I'd submit a bug report to VMware, but I'm not running a “supported” host OS.

Oh well, at least dynamips runs nicely.

Ever wonder why sometimes, out of the blue, fonts in GTK/Qt applications become huge? Yep, me too.

The answer (most of the time) has to do with the DPI your X11 video driver assigns the particular display. Normally, the DPI setting is derived from the physical dimensions of the particular screen in use. This is an attempt for fonts, and other screen elements, to be sized correctly.

It seems that some drivers do this correctly, and some don't. The fglrx driver is way off, most of the time.

Here is a dialog with normal-sized fonts (DPI of 104 x 98):

Normal Fonts

Here's one with huge fonts (DPI of 127x127):

Huge Fonts

A quick way to determine the current DPI is to run the following:

lepton% dxpyinfo|grep dots
resolution: 104x98 dots per inch

One of the fixes is to override the display dimensions in your xorg.conf, and ignore any EDID information from the physical display. Example from xorg.conf:

Section "Monitor"
     Identifier     "LCD Panel"
     # Set Display Size
     DisplaySize    340 270
EndSection

The 340 x 270 mm size seems to work for me (even though it's not the physical dimensions of my monitor), and sets the DPI to 104 x 98.

Here's some output from Xorg.0.log after X is restarted with the DisplaySize directive:

(**) fglrx(0): Display dimensions: (340, 270) mm
(WW) fglrx(0): Probed monitor is 280x210 mm, using Displaysize 340x270 mm
(**) fglrx(0): DPI set to (104, 98)
(--) fglrx(0): Virtual size is 1400x1050 (pitch 1408)

Yeah, it's WW'ing since the DisplaySize has been overridden. This is fine.