Sprint 3G CDMA2000 1x test drive

Sprint has a 15 day free trial of their CDMA2000 1x service, so I’m trying it. Here’s my first impressions. [updated Sept. 19]

I’ll start with the service itself, technically, rather than the issues with sales/support.

They advertise the service as ‘speeds up to 150kbit/s’ with an ‘average speed of 70k bps’. They don’t say anything about packet latency. In real life, the transfer rate seems okay, probably close to that average of 70k bps. However, latency is a killer, with round-trip turn-around (RTT) times of 300ms to over 1000ms, probably averaging about 500-600ms in my experience. This translates to delays of a half-second to over a second when one clicks a web page before the page even starts to load.

What’s worse is the whole thing is not direct IP. Frankly, I have not studied the details yet, but it appears to be some kind of VPN like service, over TCP, or something like TCP. This wreaks havoc with any apps that want to be closer to the network layer. For example, one behavior I found is using VoIP, with an 8K GSM codec, I experienced situations where the Sprint network must have kept trying to deliver the ‘stale’ packets, in order, even though they were UDP, with the result being that the destination played my words, legibly, literally several *minutes* after I said them. When will these providers get the Isenberg ‘stupid network’ thing?

Like all 3G services, coverage is still spotty. Coverage has actually been a bit better than I expected, so far. I have usually been able to connect from most places, but often not with a very strong signal (probably a factor in the above RTT times).

In terms of the product, support for it etc. It is almost funny. I could not find it under ‘products’ at all on their website, even though I could find it in their sales literature and press releases, and I knew they offered it because I know people that have it. I finally had to call the sales number and talk to a human being to order the service.

It is a data-only service, with no phone, and no phone number. This totally screws up Sprint systems. When you dial any Sprint support number, the first thing they always want is your Sprint phone number, which I don’t have, via IVR of course, before you can get. anywhere. Even the number that came with the ‘modem’ for the data-only service that the ‘quick-start’ instructions say to call to activate the service works this way, requiring a phone number, and NOT responding to ‘0’ for an operator/human. The modem actually works out of the box and is pre-activated, so I didn’t really need to call the number in the quick-start to try the service. In fact, much of the ‘quick-start’ instructions (the only document that came with the service) were irrelevant. I’m a bit of a geek and managed to get it working, but I have to imagine that this sort of thing causes lots of problems for many customers.

It uses RAS dial-up for the connection, like a modem, not like an ethernet. It requires some ‘special’ Sprint software. I don’t know yet if this is a wrapper to plain-old standard stuff or not, so I don’t know if this would work under Linux etc. or not yet (I believe there are ways, depending on the particular modem device).

The Sprint data service is $80 for unlimited access. If it could really deliver 150Kbit/s, or even 80Kbit/s with decent latency, it would probably be worth it. As it is, it has higher latency than dial-up with slightly better transfer rates. Web browsing feels about like dial-up, but maybe a little better for loading graphics. It nominally works for telnet/ssh, but is a bit annoying with those high latencies.

About all it seems good for is simple web browsing and maybe using an email client to get mail via POP/IMAP. I’m not even sure IM would work very well with it, given these packet latencies. I doubt that will be enough for me to keep the service beyond the 15-day trial, but I’ll keep playing with it to see.

UPDATE: I switched to using a CF card version of the Sprint Modem, that allows me to use it on my laptop and Sharp Zaurus Linux PDA. That may be enough reason to keep the servicefor a while. However, as for performance, it’s worse than I originally thought. There appears to be a lot of caching and optimization to make web performance seem better, but for other protocols, like IRC and such, I see delays of up a minute or more (not one second, but 60 seconds) in terms of the time that the client application sends the data and when the server gets it. This is something more than packet latency and is some kind of a buffering a retransmit issue. The data back from the server to the client appears to arrive without quite as much delay.