|Home||Pauline's Pages||Howto Articles||Uniquely NZ||Small Firms||Search|
|Real Life Internet Access Rates|
The question you will all ask is "What rate should we achieve with a well set up Modem?" This is difficult as many factors determine this and much of the time the Internet itself is very slow. Any tests should be done at slack times - 0600 - 0700 is quiet both in UK and US. This gives good transfer rates without being a totally unreasonable time to be up and about.
Let us first look at the absolute maximum and work back. I will end up with figures in Kbytes/sec to match the displays in Netscape. 28.8K baud is 3.6 Kbytes/sec with no regard to the overheads from error correction, packet headers etc. etc. The data can be compressed up to 4 times giving 14.4 Kbytes/sec on very sparse data. It is difficult to tell how well the Modems compress data but we can get a rough indication of the opportunities by compressing using Zip as a check. HTM files being text typically compress to about 45%, a .EXE will compress about 50% (but note most .EXEs you will download are self extracting and fully compressed). Word processor documents are not only bigger than the equivalent TXT or .HTM files by circa 2 fold but are very redundant and will compress with Zip to 30-40 %. .GIF and .JPG will get a few percent compression at the best.
Most of the checks I have done have been at the 0600-0700 time and using big sites in the USA with powerful servers such as Microsoft (http://www.microsoft.com) and WinZip (http://www.winzip.com) These sites are no good in the UK evening for tests. The Internet Service Provider (ISP) can also slow transfers and those with plenty of capacity and a connection directly to the Internet backbone will be best. In the early morning all UK ISPs should all be capable of reasonable transfers - if not you should change your ISP!
The results I have obtained do not show marked differences between ISPs. Of the three that I used for a series of tests CompuServe was just ahead with Demon followed very closely by I-way (a local provider in Reading). Since then my wife has gained access to the Open University PPP entry which is through ENERGIS and that may just have an edge over CompuServe. All have delivered 500K plus downloads of .EXE files at between 3.1 and 3.4 Kbytes/sec. It is interesting that CompuServe which has gained a very poor reputation showed up at the top, although to be fair the results are within statistical error.
It is difficult to find big enough .DOC or .HTML files to really check the compressed performance although those are important to the speed of access to normal WWW pages. They are always mixed in with lots of .GIFs or other graphics. I have wondered about uploading big Word file to my own web site just to enable checks to be run.
The bottom line is that the results of the Modem installing and tuning is that I am prepared to abort any download where the rate looks like falling under 2Kbytes/sec and see nothing unusual in long periods at around 3Kbytes/sec. A useful trick is to click on the little modem icon on the task bar which puts up a screen which shows the send and receive lights on a Pictorial Modem, allowing one to see the uniformity of transfers, and it also shows a connect time clock and the number of bytes transferred in each direction. These rates should be slightly higher than the actual data because of the overheads like error correction and the occasional re-send of data refereed to above. If it is too different then it can indicate bad lines leading to data often needing to be sent again. The speed indicators in the various programs such as Netscape over-read at the start so either time the transfers or do long downloads if you want meaningful numbers.
One final practical point - do not get mesmerized into watching download speeds. Most of the latest Browsers allow you to go on viewing documents whilst you are downloading in the background and even to set up several simultaneous downloads or Windows. This will slow the download a bit but overall may be much more cost effective.
Copyright © Peter Curtis
Content revised: 14th August 1997