IIMS 96 contents
[ IIMS 96 contents ]

The Internet as a multimedia snailway

Larry R Nelson
Curtin University of Technology
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)

The URLs for the nine selected sites were as follows.

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

I used an IBM ThinkPad 750 for my work, coupling it to a Xircom Ethernet PCMCIA card in my office at Curtin University, and to a Netcomm V.34 modem at home. The UART in the ThinkPad 750 is not the optimal one for use with a V.34 modem, it's an 8250, not a 16550. (Any UART not up to the 16550's capabilities is said to be unable to use a V.34 modem to advantage as it can't match the modem's throughput.) The ThinkPad 750 runs on an Intel 486SU33 chip. My SLIP connection was made to a Curtin University modem bank. I used Peter Tattum's Trumpet Winsock Version 1.0, Rev.B.10, to set up TCP/IP for both SLIP and Ethernet. Christy Pinfold used a Mac Centris 660AV to Ethemet out of her university office in Perth.

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

As we logged into these various sites and collected our data, we tried to keep a weather eye out for file changes. Most Web sites update their pages frequently; unfortunately not everyone date stamps their files, or their pages, making it difficult to detect changes in some cases. Unknown changes to file sizes has to be considered as an uncontrolled contaminating variable in this study. We do know that Sites 6, 8, and 9 remained constant during our logins, but we're not positive of the others.

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

Tables 1 through 9 provide simple descriptive statistics for the dependent variable, number of seconds to document done, stratified by two of the independent variables, Site and Client.

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

As mentioned, the "bad" column in Tables 1-9 relates to connections which could not be completed. In the case of Shelley, the SLIP connection, to Site 2, all of the seven bad connections related to excessive time; all seven would-be connections exceeded the five-minute time limit which we imposed. A more in depth look at these seven baddies reveals that three of them were completed in less than eight minutes, three had hung after eight minutes, and one was actually still coming in after 32 minutes, at which time I had to be somewhere else.

Table 1: Perth, Curtin Planets (Site 1)
%25%50%75IQRnmeans.d.bad% bad
Shelley 2257108861769.4155.6300
Curtin 23262851226.6710.30214
Cowan 236595722363.6541.9328

Table 2: Massachusetts Planets (Site 2)
%25%50%75IQRnmeans.d.bad% bad
Shelley 6910919312410123.4069.38741
Curtin 611061931329119.0069.11431
Cowan 81931607923121.5653.0528

Table 3: Cambridge Planets (Site 3)
%25%50%75IQRnmeans.d.bad% bad
Shelley 3552105701489.0087.74318
Curtin 436199561075.9042.77323
Cowan 142343292240.0040.02519

Table 4: Wisconsin DPI (Site 4)
%25%50%75IQRnmeans.d.bad% bad
Shelley 3713922518912138.75102.12425
Curtin 5810014284899.1245.88327
Cowan 29314011833.8810.41220

Table 5: California InfoPages (Site 5)
%25%50%75IQRnmeans.d.bad% bad
Shelley 121849381241.6754.19320
Curtin 121627161020.5012.3819
Cowan 91534251023.6020.3200

Table 6: New Zealand U Otago (Site 6)
%25%50%75IQRnmeans.d.bad% bad
Shelley 152358431546.6769.2400
Curtin 15278166946.7849.8800
Cowan 6721151012.8010.9300

Table 7: Michigan Internet Public Library (Site 7)
%25%50%75IQRnmeans.d.bad% bad
Shelley 142045311133.8225.41427
Curtin 182234161027.3013.5700
Cowan 51431261035.7062.4600

Table 8: Perth, Murdoch U Images (Site 8)
%25%50%75IQRnmeans.d.bad% bad
Shelley 424553111448.147.9517
Curtin 4042433942.784.3500
Cowan 59105108.203.3900

Table 9: Perth, Murdoch U Vet Science (Site 9)
%25%50%75IQRnmeans.d.bad% bad
Shelley 496098491379.3847.5700
Curtin 29334214937.4413.5300
Cowan 18326749640.1726.87440

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

Time of day (client) was looked at in some detail in an attempt to confirm what most Internet users believe: service depends on the time of day - log on before or after standard office hours for best service.

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.

Table 10: Bad connections by time of day (client)

Client Time IntervalTotal ConnectionsNumber BadBad "Other"Bad "Time outs"

05:30 - 08:00492 (4%)1 (2%)1 (2%)
08:01 - 10:00542 (4%)1 (2%)1 (2%)
10:01 - 12:007810 (13%)4 (5%)6 (8%)
12:01 - 17:0018431 (17%)12 (7%)19 (10%)
17:01 - 21:0010000
Total37545 (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.

Figures 1 - 3

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

Correlation coefficients were computed, by Site, to index the relationship between SLIP connect speed (bps) and time to document done (seconds). Scatterplots were visually inspected to detect any non-linear trends.

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

Hierarchical analysis of variance modelling procedures were used to discern the relative abilities of the independent variables to explain the variance of the dependent variable, seconds.

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?

At the end of the day, this study found that accessing Web sites from three Perth based clients in mid-1995 was characterised by considerable variability. From 10 in the morning to 5 in the evening just over 15% of our connections failed for one reason or another. Access to the home page of the three Planets sites generally took at least a minute to complete, often more than a minute and a half. A surprise was that the performance rendered by a dialup SLIP connection did not lag far behind Ethernet connections.

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


[ IIMS 96 contents ] [ IIMS Main ] [ ASET home ]
This URL: http://www.aset.org.au/confs/iims/1996/lp/nelson.html
© 1996 Promaco Conventions. Reproduced by permission. Last revision: 15 Jan 2004. Editor: Roger Atkinson
Previous URL 18 Feb 2001 to 30 Sep 2002: http://cleo.murdoch.edu.au/gen/aset/confs/iims/96/lp/nelson.html