Sprint's '56k' service: Recall that this is just MMDS, with cells having a footprint with radius from 10-25 miles, as it currently exists and is being offered. Remember the issues related to the number of users within a cell that can access at the quoted rates, continuously. This alone makes the Sprint service only appropriate for brief text messaging. Recall, too, that MCOM's microcellular architecture is what allows a larger number of users within the same footprint of the Sprint MMDS system to attain higher data rates continuously.
Thanks to a poster on yahoo, most prolific today, here's a detailed comparison of the actual data rates between MCOM and Sprint, apart from the above issue.
Enjoy!
==============================================
messages.yahoo.com
Sprint 56k constant? Probably not.
by: mvpel (29/M/San Jose, CA) 8/5/00 5:27 pm
Msg: 82256 of 82264
If I understand it correctly, they're claiming to use compression on the link to reach this speed. Typical compression algorithms, such as gzip which is widely used on UNIX, can achieve 2:1 or 3:1 compression on typical text data - for example, my mailbox containing about 120 messages saw a 62.4% reduction in size with maximum-compression gzip, or close to 3:1.
Streaming compression, though, can be CPU intensive and if your CPU isn't fast enough, can lead to more delay than is saved by the reduction in data size. 2:1 on typical text and HTML is more realistic to expect.
However, the thing to bear firmly in mind is that most web pages have images, and the images make up the majority of the bytes on the page.
For example, on this posting page I'm on right now, the base HTML is 5,786 bytes long. It has an image of 1,294 bytes, the "Yahoo Finance" logo, for a total of 7080 bytes. (Yahoo is very good about having simple, fast-loading pages.) The image makes up 18.3% of the bytes.
Now, compressing the HTML page is fairly productive:
[mike@gamma /tmp]$ ls -ls post.html
6 -rw-rw-r-- 1 mike mike 5786 Aug 5 14:04 post.html
[mike@gamma /tmp]$ gzip -9 -v post.html
post.html: 67.7% -- replaced with post.html.gz
[mike@gamma /tmp]$ ls -ls post.html
l.gz
2 -rw-rw-r-- 1 mike mike 1892 Aug 5 14:04 post.html.gz
It was reduced at about 3:1, from 5786 to 1892, a savings of 3,894 bytes. However, the GIF image is ALREADY compressed - that's what a GIF or a JPG is, image data encoded for small size. Trying the same thing on the GIF actually yeilds an INCREASE in the size of the image:
2 -rw-rw-r-- 1 mike mike 1294 Aug 5 14:02 main4.gif
[mike@gamma /tmp]$ gzip -9 -v main4.gif
main4.gif: - 0.3% -- replaced with main4.gif.gz
[mike@gamma /tmp]$ ls -ls main4.gif.gz
2 -rw-rw-r-- 1 mike mike 1327 Aug 5 14:02 main4.gif.gz
The image had a NEGATIVE compression ratio, and went from 1,294 bytes to 1,327 bytes, an increase of 33 bytes!
There's a net gain in the case of this Yahoo posting page, but "compressing" the image with a net loss still took CPU time.
However, on more graphics-intensive pages than Yahoo, which tend to dominate the internet, this balance shifts decidedly in favor of the images. For instance, on this page: usbstuff.com
The HTML is 14,681 bytes, but all the images add up to 63,242 bytes. The total size of the page is 77,923, but after compressing every one of the files using 0.04 seconds of CPU time, the total size winds up being 60,346 bytes, for a savings of a mere 17,577 bytes.
Sure, the 14.7k html page was reduced by 71%, but most of the GIF files either shrunk by only a few bytes or actually increased in size.
If the base data rate is 19.2k, (supposing they're claiming 56k based on 3:1 compression) this compressed page will take about 31 seconds to load. So you've recieved 77,923 bytes in 31 seconds, meaning your effective data rate is actually about 24.8kbps.
By contrast, Ricochet can deliver 77,923 bytes in 9.5 seconds over a sluggish Windows serial port with their buggy device drivers, or in 6 seconds on a loaded network at 128kbps, or in under five seconds at the kinds of speeds that were seen during the beta test.
I'm sure Sprint's bit packing will make your text-based e-mail seem really zippy. I use streaming compression on many of my wide-area SSH connections, in fact.
But for most web-browsing on today's graphics-intensive sites, it will still be nothing even remotely close to a Ricochet experience. Particularly when you get the bill at the end of the month.
Sprint should stop flailing around trying to come up with wireless internet and just get on board with Metricom.
-Michael Pelletier. |
