[lug] Wireless ISP - Sprint Broadband

Sat May 5 09:10:03 MDT 2001

I've had SprintBBD since January or so.  The latency in the service is
quite high.  They state that their service isn't intended for highly
interactive applications, such as on-line gaming.  I suppose this
applies to telnet sessions as well - I find remote telnet sessions
almost unbearable.  In fact, I was considering hooking up the modem to
my backup ISP just for this purpose - smooth but not fast interactive
sessions.

Here is an example of a ping to boulder.net:

localhost.localdomain:/jcollins% ping boulder.net
Warning: no SO_TIMESTAMP support, falling back to SIOCGSTAMP
PING boulder.net (204.181.152.2) from 24.221.216.88 : 56(84) bytes of data.
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=0 ttl=56 time=210.399 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=1 ttl=56 time=64.146 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=2 ttl=56 time=162.973 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=3 ttl=56 time=61.529 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=4 ttl=56 time=162.642 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=5 ttl=56 time=285.722 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=6 ttl=56 time=305.895 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=7 ttl=56 time=323.752 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=8 ttl=56 time=405.983 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=9 ttl=56 time=519.654 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=10 ttl=56 time=540.233 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=11 ttl=56 time=483.833 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=12 ttl=56 time=101.629 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=13 ttl=56 time=69.098 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=14 ttl=56 time=340.931 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=15 ttl=56 time=53.723 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=16 ttl=56 time=65.983 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=17 ttl=56 time=384.392 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=18 ttl=56 time=296.840 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=19 ttl=56 time=417.960 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=20 ttl=56 time=423.828 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=21 ttl=56 time=148.680 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=22 ttl=56 time=95.982 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=23 ttl=56 time=136.134 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=24 ttl=56 time=383.879 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=25 ttl=56 time=103.846 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=26 ttl=56 time=98.824 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=27 ttl=56 time=188.533 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=28 ttl=56 time=217.748 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=29 ttl=56 time=116.238 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=30 ttl=56 time=218.103 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=31 ttl=56 time=263.082 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=32 ttl=56 time=106.993 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=33 ttl=56 time=153.825 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=34 ttl=56 time=181.169 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=35 ttl=56 time=232.328 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=36 ttl=56 time=598.589 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=37 ttl=56 time=490.198 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=38 ttl=56 time=38.640 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=39 ttl=56 time=99.020 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=40 ttl=56 time=403.480 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=41 ttl=56 time=240.865 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=42 ttl=56 time=97.233 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=43 ttl=56 time=54.234 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=44 ttl=56 time=825.006 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=45 ttl=56 time=98.363 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=46 ttl=56 time=402.577 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=47 ttl=56 time=359.114 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=48 ttl=56 time=49.951 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=49 ttl=56 time=97.611 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=50 ttl=56 time=528.081 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=51 ttl=56 time=224.415 msec
64 bytes from ares.csd.net (204.181.152.2): icmp_seq=52 ttl=56 time=80.337 msec

These widely distributed numbers are representative of a good
connection day.  Occasionally during the day, the latency will be on
the order of minutes.  And several times a day while browsing, I'll
get a "host not found" error from the browser (on www.google.com, for
example).  Reloading the page usually fixes the problem.

I was on travel during the last few days (or my response would have
been more prompt).  While on site, I had a 384kbps DSL connection.
Admittedly, it wasn't as burstily fast as SBBD, but it was much
smoother and remote telnet sessions were indistinguishable from local
ones.  I much prefer that situation.  Hopefully, some of the Denver
wireless companies will percolate to the area and provide a reasonable
alternative.

--
Jeff