The Internet as a multimedia snailway

How fast is the Internet? Can it perform well enough to serve as a vehicle for multimedia? Three Perth based clients logged in to nine Web servers for a period of three months, measuring the number of seconds required to download home pages. Of 375 connections, 12% failed, with successful connections often taking more than a minute to complete. Relationships between download time and server location, time of day, and client type, Ethemet and SLIP dialup, are reported, with SLIP performance found to lag much less than anticipated. The best Internet performance obtainable during the period of the study gave an effective throughput rate only about one percent of that commonly delivered by late model CD-ROM drives.

The Internet's World Wide Web, and its expected successor, the so-called Information Superhighway, or Infobahn, continues to be touted as a vehicle which will carry multimedia to homes, schools, and businesses. This very conference, the 3rd International Interactive Multimedia Symposium, is dedicated to the "learning superhighway", and to exploring an expected fusing of two emerging technologies, multimedia and the Web.

Is the Web truly a suitable vehicle for transporting multimedia? Are we satisfied that the Web can presently deliver graphics and text at an acceptable rate? Is the Web, and our browsers, really multimedia capable? Rich media capable? Truly interactive?

Most of us know that the Web, as found mid-1995, handled rich media only via the use of "helpers", and was only beginning to show signs of interactivity beyond hyperlinks. Multimedia tyros might be excused for believing that such facilities constitute interactive multimedia, but the rest of us know better. Let's put aside thoughts of rich media for the moment, and interactivity, and focus just on the delivery infrastructure on which we expect the Infobahn to grow. Let's agree to be content with text and graphics, and focus on access speeds to Internet Web servers.

Speeds? I say ... pulling down typical Web pages with our "show graphics" browser option on is more often than not a chelonian activity, not something one would undertake at the front of a lecture theatre (unless, perhaps, it was empty). Web browsing is for people with time to spare, not for surfies, not for someone who needs to be somewhere else in ten minutes. Web browsing is rather like going to the museum on a wintry afternoon; interesting things to see, but we don't necessarily expect to see them in a hurry. Or, perhaps it's more like going for a ride on the Ferris wheel at Royal Show time: we think it'll be fun once we're on, but we expect to queue up, and to wait what might be many minutes before the action begins.

One doesn't surf the Web. Not even in Perth, a city known for its propensity to good surfing beaches. One browses the Web in a leisurely manner, at best, and is never surprised to end up crawling. Blasphemy? Some people get red in the face on hearing such talk. We have all heard that the Web is the future, and no one expects to get there on hands and knees.

It was with such thoughts in mind that I decided to knuckle down and collect some hard data on the time it takes to access typical Web sites, both at home and abroad. I selected nine sites, three in Perth, one in New Zealand, four in the United States, and one in the United Kingdom. I accessed these sites via a SLIP connection from my Perth residence, and from my office via our university's Ethernet backbone. I was assisted by Christy Pinfold, a colleague at another Perth based university, who logged into the same Web sites from her office, working over her university's Ethernet network.

We attempted several hundred connections over a period spanning close to three months, mid-May through early July, 1995. Our dependent variable was the number of seconds it took for our browsers to announce that they had completed the downloading of a site's initial Web page. Independent variables included time of day for both client and server; day of the week; and, for SLIP, connection speed.

The only surprise likely to be found among our results is that the SLIP connection gave performance figures which were essentially, or at least tolerably, close to those obtained over a direct Ethernet wire-up. SLIP connection speed varied considerably, but in the end had an unnoticeable impact on the results. I summarise our results in detail below. Perhaps as much as anything else they may come to serve as reference points against which we can compare future soundings.

The sites (servers)

Site 1: http://www.curtin.edu.au/mirror/planets/
This was Curtin University's mirror of "Welcome to the Planets", the "collection of many of the best images from NASA's planetary exploration program" (as quoted from the welcome screen itself). Curtin University is in Perth, Western Australia. [verified 21 Feb 2001]

Site 2: http://scruffy.phast.umass.edu/welcome.html
The University of Massachusetts' mirror of "Welcome to the Planets" (same material as at Site 1). [verified 21 Feb 2001]

Site 3: http://www.ast.cam.ac.uk/Pictures/planets/
Cambridge University's mirror of "Welcome to the Planets" (same material as at Sites 1 and 2). [verified 21 Feb 2001]

Site 4: http://www.state.wi.us/agencies/dpi
Home page for the Wisconsin Department of Public Instruction, in Madison, Wisconsin. The address given above is the new URL for http://badger.state.wi.us:8010/agencies/dpi/www/dpi_home.html which was the URL used during our data collection stage. [19 Feb 2001: home page is now http://www.dpi.state.wi.us/]

Site 5: http://infopages.com/
Maximised Online's InfoPages guide to current events in Orange County and the Southern California area.

Site 6: http://www.otago.ac.nz/home-page.html
University of Otago (Dunedin, New Zealand) home page. [19 Feb 2001 at http://www.otago.ac.nz/]

Site 7: http://ipl.sils.umich.edu/
The home page for the IPL, Internet Public Library, located at the University of Michigan. [21 Feb 2001 now at http://www.ipl.org/]

Site 8: http://cleo.murdoch.edu.au/murdoch/murd_map.html
Murdoch University's home page. Murdoch is located in Perth, Western Australia. This site has a simple home page, consisting of only one file. The pages of all the other sites were typical of current Web servers in that they involved the transfer of multiple files. (Some readers may be unaware of the fact that current http protocol requires a new handshake for each file to be transferred; because of this it is advantageous to design Web pages as single files, but this is not always feasible.) [19 Feb 2001 Murdoch University home page is http://www.murdoch.edu.au/ and http://cleo.murdoch.edu.au/ ceased on 30 Sep 2002]

Site 9: http://134.115.224.48/vetsc/indexlst.htm
Home page for veterinary science at Murdoch University. (Same university as Site 8, but different server.) [21 Feb 2001 home page is at http://wwwvet.murdoch.edu.au/]

The clients

We both used Netscape as our browser, Christy version 0.94B2, me version 1.0N. We did not update the browser over the course of the data collection. Nor did we change the browser's settings during the study.

At the time of the study, Curtin University was using a dedicated 126 kbps ISDN line to Perth's Internet gateway, while Edith Cowan University was using a 256 kbps microwave link. Curtin, Edith Cowan, and Murdoch are expected to upgrade to 34 Mbps microwave links before the end of 1995.

Local and host times of day are important variables in this sort of study. Perth is eight hours ahead of GMT; when it's 8 AM in Perth on Monday, it's 7 PM Sunday in Chicago (same as Madison, Wisconsin). One would think this time differential would give Perth Internetters good access to sites in the United States - as we head into our day, the US is heading into evening, and, presumably, US Web users are logging off. Eight of a Perth morning equates to 12 midnight of the evening before in Cambridge (UK), while 8 AM Perth maps to 1 PM of the same day in the beautiful city of Dunedin, New Zealand.

The method

We programmed our browsers with the URLs given above. We'd point the browser at one of the sites, double click with the mouse and simultaneously start a stop watch. We then watched the bottom left side of the Netscape screen for the "Document done" message to appear. When it did we stopped the watch and recorded data.

Of course the "Document done" message did not always appear. We agreed that we would abandon a download after five minutes, although I at times hung on longer in those cases where there remained sonic evidence of traffic. (If some day you decide you might have time on your side, and patience, you'll see rather quickly that it's a pretty straightforward matter to predict whether or not a site access is going to hold up for the time needed... in the majority of those cases where we waited five minutes before giving up, it was evident long beforehand that the connection had failed ... on the other hand, there were a few cases where things were still moving at the five-minute mark... in a couple of these cases I stayed tuned just to see how long it might take, and was once rewarded 11.5 minutes later, and once 22.25 minutes later.)

Results as simple descriptive statistics

In these tables, the 25th, 50th, and 75th percentiles head columns two through four; IQR is the inter-quartile range; n is the number of connections which were completed in less than five minutes; mean is the average; s.d. refers to standard deviation; bad is the number of connections which either could not be made, or which exceeded five minutes; and %bad is the number of bad connections as a percentage of the total number of connections, good and bad.

The labels of the Client variable appear in these tables as Shelley, Curtin, and Cowan. Shelley was the SLIP connection, Curtin was Ethernet over the Curtin University backbone, and Cowan was Ethernet over the backbone at the Claremont Campus of Edith Cowan University.

As an example of interpreting the information in Tables 1-9: Table 1 shows that 17 successful connections were made from Shelley, the SLIP client; the median (%50) time to document done was 57 seconds from Shelley to Site 1, with an average of 69.41 seconds. The same table shows that 12 successful connections were made from Curtin, with a median time of 26 seconds, mean of 26.67 - note, however, that two (2) bad connections were recorded.

Table 1 indicates that connecting to Site 1 from Cowan was similar to connecting from Shelley in terms of time. Of the 25 connections made from Cowan, 23 (92%) were successful. Table 1 might be considered a maverick table in that the Site. Curtin, was the same as one of the clients. The times seen for the Curtin client in Table 1 might be regarded as Ethemet LAN (local area network) access times.

If one sets Table 1 aside and tries to discern patterns from the other tables using the %75 column to avoid problems of skewing, I suggest there to be some evidence to support these statements:

1. Cowan was the best client (quicker access). When this fact was mentioned to Curtin University network staff there was no surprise; amount of traffic was suggested as the reason, with Curtin said to have much more traffic than Cowan (Cowan's Claremont campus consists of only two main buildings; there would probably be only one Cowan Claremont Internet user for every 100 at Curtin).

2. The SLIP client, Shelley, generally did not lose out too badly. I expected to see SLIP figures way behind the Ethernet figures, but the tables, in my opinion. do not bear this out. The SLIP figures are not way behind the others.

3. The SLIP connection tended to have a higher percentage of connection failures than did the other clients.

4. Connecting to some sites was unreliable. All clients had problems connecting to Site 4 (Wisconsin). The Shelley and Curtin clients had trouble accessing Site 2, Massachusetts, while service into Site 3, Cambridge, often presented problems for all clients.

5. The best service was rendered by Site 8. The interquartile range figures for this site were very low indicating consistency in access. 1 want to believe that this is due to the simplicity of Site 8's homepage - it was based on a single file. Some readers might want to ask if there could not be other reasons for the low IQR figures found at Site 8, and there might be, too. The single file was a small file? But it wasn't - it was 62K in size, and was graphically rather complex, consisting of fifteen 256-colour thumbnails welded to a single GIF file. Site 8 was found in fewer Internet hops? But compare with Site 9, another http server at the same university. The IQR figures for Site 9 are much higher than Site 8's, and one would think that the number of hops would be about the same.

Bad connections

Table 1: Perth, Curtin Planets (Site 1)
	%25	%50	%75	IQR	n	mean	s.d.	bad	% bad
Shelley	22	57	108	86	17	69.41	55.63	0	0
Curtin	23	26	28	5	12	26.67	10.30	2	14
Cowan	23	65	95	72	23	63.65	41.93	2	8
Table 2: Massachusetts Planets (Site 2)
	%25	%50	%75	IQR	n	mean	s.d.	bad	% bad
Shelley	69	109	193	124	10	123.40	69.38	7	41
Curtin	61	106	193	132	9	119.00	69.11	4	31
Cowan	81	93	160	79	23	121.56	53.05	2	8
Table 3: Cambridge Planets (Site 3)
	%25	%50	%75	IQR	n	mean	s.d.	bad	% bad
Shelley	35	52	105	70	14	89.00	87.74	3	18
Curtin	43	61	99	56	10	75.90	42.77	3	23
Cowan	14	23	43	29	22	40.00	40.02	5	19
Table 4: Wisconsin DPI (Site 4)
	%25	%50	%75	IQR	n	mean	s.d.	bad	% bad
Shelley	37	139	225	189	12	138.75	102.12	4	25
Curtin	58	100	142	84	8	99.12	45.88	3	27
Cowan	29	31	40	11	8	33.88	10.41	2	20
Table 5: California InfoPages (Site 5)
	%25	%50	%75	IQR	n	mean	s.d.	bad	% bad
Shelley	12	18	49	38	12	41.67	54.19	3	20
Curtin	12	16	27	16	10	20.50	12.38	1	9
Cowan	9	15	34	25	10	23.60	20.32	0	0
Table 6: New Zealand U Otago (Site 6)
	%25	%50	%75	IQR	n	mean	s.d.	bad	% bad
Shelley	15	23	58	43	15	46.67	69.24	0	0
Curtin	15	27	81	66	9	46.78	49.88	0	0
Cowan	6	7	21	15	10	12.80	10.93	0	0
Table 7: Michigan Internet Public Library (Site 7)
	%25	%50	%75	IQR	n	mean	s.d.	bad	% bad
Shelley	14	20	45	31	11	33.82	25.41	4	27
Curtin	18	22	34	16	10	27.30	13.57	0	0
Cowan	5	14	31	26	10	35.70	62.46	0	0
Table 8: Perth, Murdoch U Images (Site 8)
	%25	%50	%75	IQR	n	mean	s.d.	bad	% bad
Shelley	42	45	53	11	14	48.14	7.95	1	7
Curtin	40	42	43	3	9	42.78	4.35	0	0
Cowan	5	9	10	5	10	8.20	3.39	0	0
Table 9: Perth, Murdoch U Vet Science (Site 9)
	%25	%50	%75	IQR	n	mean	s.d.	bad	% bad
Shelley	49	60	98	49	13	79.38	47.57	0	0
Curtin	29	33	42	14	9	37.44	13.53	0	0
Cowan	18	32	67	49	6	40.17	26.87	4	40

The great majority of "bad" SLIP connections were ones which started well, but had not completed after five minutes. Three times an "unable to locate host" message was noted from Shelley.

Of the two Ethernet based clients, connection failures from Curtin were similar to those from Shelley SLIP: time outs, not complete after five minutes. Over at Cowan, Christy Pinfold noted five "TCP errors"; three "connection refused by host" messages; and three time outs (not complete after five minutes). All of the Cowan time outs were related to Site 9, a server which was problem free for Shelley and Curtin clients.

Time of day

I looked at the potential effects of the time of day (client) variable by first of all blocking the variable into time intervals. Then I made a table which looked at the number of bad connections crossed with the time intervals, followed by several box and whisker plots which displayed the time intervals along the x-axis, with percentiles for the main dependent variable, seconds to document done, along the y-axis.

Table 10 displays the cross with "bad", the number of bad connections. For purposes of this cross tabulation, "bad" was broken into connections which failed to come through in less than five minutes ("time outs"), and connections which could not be completed for "other" reasons, including TCP errors, and could not find or refused by host errors.

Client Time Interval	Total Connections	Number Bad	Bad "Other"	Bad "Time outs"
05:30 - 08:00	49	2 (4%)	1 (2%)	1 (2%)
08:01 - 10:00	54	2 (4%)	1 (2%)	1 (2%)
10:01 - 12:00	78	10 (13%)	4 (5%)	6 (8%)
12:01 - 17:00	184	31 (17%)	12 (7%)	19 (10%)
17:01 - 21:00	10	0	0	0
Total	375	45 (12%)	18 (5%)	27 (7%)

Figures 1 through 3 are box and whiskers, showing the range in access times which all three clients combined experienced when logging in to the three Planets servers.

If it's been a while since you've seen such graphs, the thick line in the shaded part of the box indicates where the median is (%50 in the tables above); the bottom of the shaded box represents the 25th percentile, while the top of the box corresponds to the 75th percentile.

The boxes which correspond to 'Before 8 AM' and 'After 2000' are all based on data from the Shelley SLIP client.

Figure 1 suggests that the best time to access Site 1 was before 10 in the morning. Figure 2 mirrors my own view of using the Web from my office - best get work done early as performance suffers as the day moves along. Figure 3, however, doesn't support this statement.

It is interesting to note that the three figures suggest that a Perth based Web user wanting Planets information would not necessarily benefit from accessing the local site, Curtin University. Performance from the Cambridge server closely rivalled that found in Perth (compare Figures 1 and 3).

SLIP connect bps and seconds

One would hope there would be an inverse linear relationship between these two variables. Connect speeds ranged from a low of 7200 to a high of 24000, with a median of 19200, but there was no consistent relationship between speed and the number of seconds to download home pages. In fact, of the nine correlations, eight were positive, ranging from a value of .07 (Site 5), to a maximum of .40 (Site 3); the median of the positive correlations was .21. The single negative coefficient, -.48, corresponded to the site which took the longest for all three clients to access: Site 2.

Variance partitioning

Taken as an individual variable, Site, by itself, could account for 26% of the variance in seconds; Client, by itself, could explain only 3%; and Interval (time of day) could, alone, account for but 4% of the variance in the dependent variable. Increasing the number of independent variables to two, a model with Site and Interval together, with interaction, accounted for 38% of the variance in seconds; a model with Site and Client, plus interaction, explained less variance, 32%. A tri-variate model, Site, Interval, Client, plus all interactions, could explain 60%.

These variance partitioning results serve to confirm the data summarisations presented earlier. The amount of time required to download a Web page clearly depends on a number of factors, with the single most important factor being the Site itself. The second most important factor found in this study was Interval, interacting with Site.

Time to download depended first of all on the site being accessed, and then on the time of day the access was attempted. If we take into account site, time of day, client, and all possible interactions among these variables, we end up with a model which accounts for more than half of the time required to download pages.

A multimedia snailway?

I started this study with the idea of gathering factual data to back up a personal impression: the Internet, as we found it in Perth at the time of the study, was hardly in a position to present itself as a suitable means for conveying multimedia information.

If we could take one of the better sites in this study, Site 8, a site whose home page remained unchanged over the course of the study, effective throughput ranged from an average of 7,561 bytes/second (60,488 bps) for the Cowan client, to 1,288 bytes/second (10,303 bps) for the Shelley client (these figures were computed by dividing the size of the home page, in bytes, by the average number of seconds to download, as seen under the "mean" column of Table 8).

CD-ROM drives, in comparison, have throughputs which range from 150,000 bytes/second in their original format, to the 600,000 bytes/second found on standard mid-1995 multimedia PCs. In not too rough terms, modem CD-ROM drives have almost one hundred times the best throughput which this study was able to obtain over the Internet. In comparative terms, a 20-second, multimedia AVI file (video clip) occupying 1,930,036 bytes would take just over four minutes (255 seconds) to download using this study's best Internet access figures, compared to just over three seconds from a CD-ROM drive.

An 23-second multimedia MMM animation file (no sound) of 202,118 bytes would take, using this study's best figures, some 26 seconds to haul down from the Internet, compared to a third of a second from a CD-ROM. I find a clear message in these figures. If I had a class dealing with the solar system, would I have students access one of the Planets Web servers, or would I suggest they use the Planets CD-ROM instead?

Will Web access speeds improve? Friends at our Computing Centre assure me they will[1]. Lots of people are said to be working on the bandwidth problem. But there's obviously a long way to go, much work to do. It would be interesting to repeat this study in mid-1996. In the meantime, for Perth based multimedia users, CD-ROMs have an absolute advantage over the Internet.

Endnote

1. I am grateful for the assistance of Steve Maddocks, Curtin Campus Network Manager, in checking some of the technical calculations found in this paper.

Author: Dr Larry R Nelson Faculty of Education Curtin University of Technology GPO Box U 1987 Perth, Western Australia 6001 Please cite as: Nelson, L. R. (1996). The Internet as a multimedia snailway. In C. McBeath and R. Atkinson (Eds), The Learning Superhighway: New world? New worries? Proceedings of the Third International Interactive Multimedia Symposium, 291-297. Perth, Western Australia, 21-25 January. Promaco Conventions. http://www.aset.org.au/confs/iims/1996/lp/nelson.html