home *** CD-ROM | disk | FTP | other *** search
ΓòÉΓòÉΓòÉ 1. Abstract ΓòÉΓòÉΓòÉ Digital multimedia weds sound and images to computer data processing. Computer applications such as inventory, database and spreadsheet applications can be extended with sound, voice and video to create hypermedia documents. Commercial uses of sound and movies such as news reporting or video rental can be placed under computer control and available on demand. Many of these new applications fit into the conventional paradigm of "computer as personal information manager". But other digital multimedia applications shift the paradigm by using a computer as the very center of human communication and action. Teleconferencing, groupware, and collaborative computing, for example, use digital multimedia to improve human communication and to better integrate personal computers into social interaction. Distributed multimedia applications - those that use a network for delivery of digital multimedia - often require a multimedia file server that can stream multimedia file elements at the rate which these elements are delivered to client multimedia devices. Multimedia file servers can now be implemented on relatively inexpensive computers. The main impediment to the widespread use of multimedia servers, however, is the existing communications infrastructure which has evolved for data processing applications in the office and for analog voice and video delivery to the home. The existing stock of equipment must be replaced gradually and existing service must be provided alongside new multimedia services. There will be a limited investment in new infrastructure until new applications are developed which can use it, and the rapid development of multimedia applications will suffer so long as there is no infrastructure to support them. OS/2 LAN Server Ultimedia 1.0 breaks this cycle of dependency by supporting multimedia client/server applications today while new multimedia networks are being developed. LAN Server Ultimedia 1.0 delivers hypermedia, movies on demand, and stored multimedia documents to OS/2, Windows and DOS clients. Our solution permits the smooth introduction of multimedia applications on 16Mbps and 10Mbps LAN's, using 486 servers and 386 clients running applications such as ActionMedia II(TM), Multimedia Presentation Manager/2(TM) and Video for Windows(TM). Extensions have been made to the OS/2 LAN Server's High Performance File System to ensure that sound, voice and video files are stored and retrieved from disk in a way that supports the high-throughput and sequential nature of movies and sound. Extensions have also been made to OS/2 LAN Server's NetBIOS communications transport to allow bandwidth reservations on Token-Ring networks; while on 10Mbps Ethernet networks, LAN Server Ultimedia 1.0 will prevent more multimedia sessions from being established than the network can support. There is a Resource Reservation System embedded in LAN Server Ultimedia 1.0 that makes reservations on network, disk, and server computer resources to ensure that there is adequate capacity for high-quality "playback" of multimedia files. Also, utilities are provided to "calibrate" the resource requirements of multimedia files with server hardware, to ensure that the server does not attempt to establish more multimedia sessions than it can support. This reservation strategy not only provides guarantees for high-quality multimedia file access, but also permits the amount of resources that are dedicated to both multimedia and existing applications to be configured so that both may efficiently share the same server and network. LAN Server Ultimedia 1.0 can support up to forty video streams over four local area network devices attached to a single server computer, in addition to existing client/server applications. LAN Server Ultimedia 1.0 has a quality of service and resource reservation design suitable for future, Synchronous FDDI, B-ISDN ATM and 100Mbps Ethernet networks which have bandwidth reservation standardized in their implementations. LAN Server Ultimedia 1.0 is the solution for the personal computer tier in an evolving family of IBM multimedia servers which also include RISC System/6000 servers, AS/400 minicomputers, and ESA/LFS mainframes. ΓòÉΓòÉΓòÉ 2. Introduction to Digital Multimedia ΓòÉΓòÉΓòÉ By bringing together sound, voice, video, graphics and animation into both routine and new tasks, digital multimedia teleconferencing makes it possible for people to work together from remote locations almost as well as when they are in the same location. And digital multimedia servers make it possible to access information of any sort at any time. Digital multimedia applications harness the potential of high-speed communications and computing so that information of practically any sort can be accessed and shared from practically any location. ΓòÉΓòÉΓòÉ 2.1. Multimedia Technology and Applications ΓòÉΓòÉΓòÉ Sound, voice and video information today is largely analog rather than digital. The storage mechanism is usually magnetic tape that is accessed sequentially (you re-wind and hunt when trying to find recorded music or video). The distribution networks are copper telephone wires, cable, and the airwaves which are distinct from the data networks that service commercial businesses and industry. In the case of video rental, the distribution and storage mechanism is the same since you drive to the store and carry a tape cartridge home. Text files, spreadsheets, database information as well as the applications which use these data, cannot be easily integrated into analog sound, voice and video presentations. Digital information is usually stored in random-access computer memories or disk, and distributed over digital, packet-switching networks. There is a gulf between digital information which is used for business, industry and education and the analog information which is used for music, movies and television. The devices used to store, edit, and retrieve information are different between digital and analog information. But a merger between the two technologies is in the offing: New, fast computer processors, high-density computer memories, high-capacity disk devices, and high-bandwidth networks are becoming commercially available to support not only conventional data processing information but digital sound, voice and video information (with rates of millions of bytes per second) to the desk-top, lap-top, or home set-top computing device. Networking technologies are emerging that promise to integrate communications onto a single type of network, called Broadband Integrated Services Digital Network Asynchronous Transfer Mode networks (B-ISDN ATM). Digital technologies are finding their way into traditional media such as motion pictures and television where graphics, animation and digital editing are now used. Digitization of voice on private corporate networks has also become widespread. So as digital sound, voice and video find commercial application, high-bandwidth optical fiber and high-speed copper networking technologies are emerging that have the capacity to integrate sound, voice and video with traditional computer-based data such as text and graphics. Digital multimedia can harness these computer technologies to produce unprecedented growth in the variety of computer-based applications. When commonplace data processing applications such as inventory and spreadsheet applications are augmented with sound, voice and video, the result is known as hypermedia. Digital multimedia can be accessed randomly so there is no need to re-wind a video or sound tape to find a desired location. Computer-based multimedia can be arranged into "electronic books" so that text, animation, graphics, video, voice and sound passages that are logically related can be accessed as a unit using pointers or links into various multimedia files or memory locations. Hypermedia is a new way to store and retrieve video, audio, and other media as conveniently as we browse a book. Convenient access to various media has become essential since so much of contemporary life is recorded in movies and sound or in digital documents stored on personal computers and network file servers. Saving contemporary film, video and broadcast archives on multimedia file servers has become an undertaking of historic importance. And including digital multimedia documents in ordinary conversations with our co-workers has become an important part of daily life. Both applications require a digital multimedia server since multimedia teleconferencing is more than an electronic voice and video conversation, it can include a remote presentation of text, audio, graphics, video and animation. More often than not, it is more important to see a document or file than to see a face when talking to a co-worker in another part of the building or another part of the globe. It is just as possible to recall a movie or recording file on demand as it is to integrate digital multimedia into a hypermedia program or remote presentation. Media on Demand permits access to movies and other recorded multimedia to start, pause, resume or stop the presentation according to the wishes of an individual viewer or listener. Media on demand, hypermedia and remote presentation applications all use a multimedia server. Because of the large size of most multimedia files, It is far more cost effective to keep multimedia files on a central server having a large store of disk or memory that can be efficiently shared by many, rather than storing these files on a plethora of individual personal computers. Owing to the size of video and sound files, it is often impossible to transfer digital multimedia files without the aid of a very high-bandwidth computer network and very high-capacity disk storage and memory devices. ΓòÉΓòÉΓòÉ 2.2. Multimedia Rates, Compression and Files ΓòÉΓòÉΓòÉ The capacity of the disks, computer memory and network devices needed for a multimedia server is determined by the rates of digital multimedia files when they are played. Since by definition, digital multimedia encompasses a wide range of media, ranging from text to video, the rates vary considerably. Traditional computer-based media such as text and binary computer files used by computer programs have characteristically "bursty" transfer rates, meaning that a lot of data is transferred in a short period of time and then the rate goes to zero - until the next burst. The rate at which text must be delivered to a workstation screen is determined either by the rate at which it is read or the size of the page which must be displayed. Generally speaking, 1200 characters per second will suffice. And text is not a continuous stream since the time it takes for someone to read or scan a thousand characters is several orders of magnitude longer than the time it takes to transfer these data from a disk, either local to the computer or remotely stored on a server. Higher rates admittedly are needed when transferring files from, say, a server disk to a client disk. These rates may exceed millions of bytes per second, but this is usually sustained only for a matter of seconds. In both cases - textual transfers and binary file transfers - there is no need to keep the transfer within a given, minimum rate, such as 150 kilobytes per second (kBps), or to guarantee that maximum delay, such as 300 milliseconds. But movies and sound do have constraints on how much is sent and received over an interval of time. These constraints are incurred when multimedia files are "played back" from a disk device or server computer. During playback, the multimedia file elements must be delivered to the multimedia presentation devices, such as a video device or speaker, at roughly the rate that are transferred from a disk or server computer. If multimedia video or audio streams are sent too quickly, then the file elements will overflow the memory which has been allocated to hold them. And if the multimedia video or audio file elements are not sent quickly enough, there will be momentary, but noticeable pauses in the multimedia presentation. The pause may result in a crack, pop, or silence in a speaker or the video frame rate may drop to the point where full-motion video is no longer perceived by the viewer. For this reason, sound and movies are often referred to as continuous-time media since the time between successive transfers of file elements effects the quality, indeed the integrity, of the multimedia presentation. The key to multimedia playback is control of the transfer rate of multimedia files. Digital multimedia rates vary greatly among and within various media. As shown in "Table: Rates for audio files in bytes per second", audio files may vary from 176,400 bytes per second, for hi-fidelity stereo sound, to 11,025 bytes per second, which is more than adequate for good-quality voice. ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Rates for audio files in bytes per second Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé RECORDING Γöé SAMPLING RATE Γöé Γöé TYPE Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Γöé HIGH FIDELITY Γöé HIGH QUALITY Γöé LOW QUALITY Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Voice-mono Γöé 44,100 Γöé 22,050 Γöé 11,025 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Voice-stereo Γöé 88,200 Γöé 44,100 Γöé 22,050 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Music-mono Γöé 88,200 Γöé 44,100 Γöé 22,050 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Music-stereo Γöé 176,400 Γöé 88,200 Γöé 44,100 Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ "Table: Rates for audio files in bytes per second" distinguishes audio recordings by their quality or fidelity. High Fidelity streams are sampled at 44.1kHz; a sample is obtained from an analog audio stream 44,100 times per second. If the sample is only a single byte, then the rate of the stream is 44,100 bytes per second for monaural and 88,200 for stereo. If the sample is a higher resolution two bytes, then the rate is 88,200 bytes per second for monaural and 176,400 for stereo (the rate of a CD ROM). As shown in "Table: Rates for voice files in bytes per second", voice files can have a lower rate than audio since the range of sounds produced by the human voice in ordinary conversation is much less than the range which can be heard by the human ear. ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Table 2. Rates for voice files in bytes per second Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé RECORDING Γöé SAMPLING RATE Γöé Γöé TYPE Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Γöé 8KHZ Γöé 11.025KHZ Γöé 22.05KHZ Γöé 44.1KHZ Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé mono Γöé 8,000 Γöé 11,025 Γöé 22,050 Γöé 44,100 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé stereo Γöé 16,000 Γöé 22,050 Γöé 44,100 Γöé 88,200 Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ "Table: Rates for voice files in bytes per second", shows rates that correspond to SoundBlaster(TM) and SoundBlaster Pro(TM) voice files. "Table: Rates for audio files in bytes per second" gives the ranges found in IBM Multimedia Presentation Manager/2 and Microsoft Video for Windows waveform files. The voice and audio waveform files shown here are continuous bit rate (CBR) streams which means that the rate is constant. It is often possible to change a CBR stream into a variable bit rate (VBR) stream and reduce disk storage, computer processor and network bandwidth requirements. One technique used for voice in teleconferencing is silence suppression: In a two-way voice conversation, both channels rarely are active at the same time since only one speaker speaks at the same time. By using silence suppression, samples that do not carry sound are suppressed, and this may reduce the rate by at least 50%. A more common technique is to compress the sound or video stream prior to transmission and then decompress it after delivery to a multimedia device. Voice streams can be as low as 6,000 bytes per second (bps) or 4,000bps when compressed using, for example, a technique called ADPCM. Compression is more widely used for visual information since there are usually large amounts of spatial and temporal redundancy. Spatial redundancy may be "white space" in a page that is faxed or a blank wall in a video frame which represent a lot of information that does not change. This information can be specially encoded at the time of compression and then restored at the time of decompression. Temporal redundancy exists across multiple video frames where elements of successive frames do not change. Once unchanging elements are transmitted in one video frame, they can be reused in successive video frames. In the Intel DVI (Digital Video Interactive) encoding standard, a complete frame that is only spatially compressed is called a reference frame and a temporally compressed frame is called a delta frame. ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Table 3. DVI Mean, Standard Deviation, and Peak Burst in KB Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé FILE NAME Γöé FRAMES IN SAMPLE Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Γöé 1 Γöé 30 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé newhart.avs Γöé x bar = 153Γöé x bar = 153Γöé Γöé Γöé s = 21 Γöé s = 6 Γöé Γöé Γöé p hat = 385Γöé p hat = 171Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé publish.avs Γöé x bar = 133Γöé x bar = 136Γöé Γöé Γöé s = 59 Γöé s = 20 Γöé Γöé Γöé p hat = 571Γöé p hat = 194Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé auction.avs Γöé x bar = 176Γöé x bar = 176Γöé Γöé Γöé s = 170 Γöé s = 33 Γöé Γöé Γöé p hat = 799Γöé p hat = 288Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé topgun.avs Γöé x bar = 297Γöé x bar = 298Γöé Γöé Γöé s = 45 Γöé s = 21 Γöé Γöé Γöé p hat = 467Γöé p hat = 378Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ The success of the video compression is evident in the fact that the compressed video recording is often one hundred times smaller than when it is decompressed. Uncompressed video at thirty frames per second (fps) can exceed 15,000kBps, but compressed video streams running at 150kBps are common. There is often considerable variance, however, both within and among compressed video files as shown in "Table: DVI Mean, Standard Deviation, and Peak Burst in KB". The ActionMedia II file named newhart.avs has an average rate of 153kBps (or 156,672 bytes per second), and the file topgun.avs which used the same compression technology has an average rate of almost 300kBps, or twice the newhart.avs file. The peak rate of the newhart.avs file is more than twice its average rate, and this variability in rate is evident in all of the files. When there are moments that have lots of motion and change in the video, less compression is achieved which results in a temporarily high rate. Also shown in "Table: DVI Mean, Standard Deviation, and Peak Burst in KB" are the same statistics which are computed over thirty frames, roughly one second of video play, instead of just among each individual frame. As can be seen from the second column, the peak rate and variance drops when larger samples are used, and this is due to the fact that the movement or change that occurs in movies is temporary and alternates with quiescient scenes that achieve a higher rate of compression. The rate at which the recording is played and the length of time of the recording determine the size of the file that holds the recording. For example, one hour of compressed video that has an average rate of 150kBps will be approximately 552,960,000 bytes in length, approximate one half of a gigabyte of disk space. Thus, a one gigabyte (billion byte) disk drive which sells for at least 1,000 U.S. dollars will hold less than two hours of video. An hour of hi-fidelity audio will require about 635,040,000 bytes. One hour of uncompressed, monaural, 8kHz voice will require 28,800,000 bytes of storage. Over 30 hours of recorded voice can be stored on a one gigabyte disk drive. In addition to sound or movie information, a multimedia file will contain control information which varies according to the format. AVS and AVI video files contain information about frame rate, encoding and the average rate of the video recording contained in the file. Audio waveform file, the WAV file type, contain information on the sampling rate, sample size, and the number of channels (one for monaural or two for stereo). Some files, such as SoundBlaster voice files, the VOC file type, are compound files meaning that there may be multiple recordings contained in a single file which are organized into "chunks". Interpreting the control information in a multimedia file is a task performed by the multimedia application or multimedia system. OS/2 and Windows are two operating systems which have been extended for multimedia to relieve applications of much of the burden of multimedia file access. ΓòÉΓòÉΓòÉ 2.3. Multimedia Operating System Extensions ΓòÉΓòÉΓòÉ OS/2 Multimedia Presentation Manager/2 and Microsoft Video for Windows both provide a common set of application programming interfaces (API's) for multimedia devices, as well as synchronization and streaming subsystems. Multimedia synchronization and streaming "Figure: Multimedia synchronization and streaming" shows a simplified multimedia system in which file elements are read by a file stream handler into one or more buffers. The elements are copied from the buffers to the multimedia devices such as CODEC's (encoders/decoders for sound, voice and video) after they are synchronized and streamed. Streaming restores the temporal relationship among file elements before delivery to a multimedia device. Synchronization restores the temporal relationship among multiple streams. Following bursty disk accesses, temporal relationships must be restored prior to delivery of stream elements to multimedia devices so the sound, voice, or video elements are delivered without disruption. Stream handlers, syncronization/streaming manager and multimedia devices offer a generic Media Control Interface (MCI) for various digital and analog multimedia devices and streams. The multimedia API's are similar in OS/2 and Windows. There is a major difference, however, between the multimedia support provided in the two operating systems. This difference stems from the singletasking nature of Windows (or DOS) and the concurrent multi-tasking provided in OS/2. Sound, voice, video, animation and other media used by multimedia applications are often separate streams that must be processed at the same time. singletasking operating systems such as Windows and DOS were not designed for processing multiple tasks at the same time, and are unsuited for processing more than a single media stream at one time. It is difficult or impractical to use Windows and DOS for complicated multimedia authoring tasks such as editing and mixing multiple streams, such as sound, voice and video. Multitasking operating systems such as OS/2, AIX(TM), Unix(TM) and Windows NT(TM) are better suited for multimedia applications. And multitasking operating systems are especially useful for distributed multimedia applications as is explained below. ΓòÉΓòÉΓòÉ 2.4. Distributed Multimedia ΓòÉΓòÉΓòÉ "Figure: Distributed multimedia playback" is a simple depiction of distributed playback where the multimedia file is stored on a file server that is remote from the workstation on which the file is played. The streaming subsystem is located in the client workstation. There may be a streaming subsystem in the server as well, but whenever packet networks are used, client streaming is necessary. The client playout buffers shown in the figure perform additional functions beyond those shown in "Figure: Multimedia synchronization and streaming"since they remove variations in delay from the network and file server in addition to those from the disk subsystem. In general, the buffer needs to be large enough to sustain a playback during the maximum time it takes to move a block of data between server disk and multimedia device. It is crucial that the network, server and disk subsystems deliver media elements at the rate at which they are displayed otherwise discontinuities occur in which a media element does not correctly follow another media element within the required amount of time. Distributed multimedia playback Multitasking operating systems such as OS/2 offer better multimedia client/server and teleconferencing services. Singletasking operating systems force multimedia applications to wait while I/O completes. When an application issues a file system READ operation on a singletasking operating system, the application must wait until the file system elements are copied from disk to computer memory. This delay can cause degraded audio and video even for short clips played from a disk that is directly connected to the personal computer. The problem can get worse when the file is stored on a remote file server and network delays add to the length of time that a Windows application must wait for elements to be transferred from server disk to client memory. This situation is worsened by DOS and Windows memory limitations - the precious low memory multimedia buffers needed for disk and network I/O are difficult to obtain. For many applications, the result is that small requests must be made to the file system even when playing a high-rate multimedia file from disk since there the largest buffer available for the transfer is 2 or 8 kilobytes rather than a recommended 32 to 63.5 kilobytes. This overhead becomes a burden even to fast 386 computers. Singletasking Windows applications are plagued by buffers that are too small, file system requests that are too small, and applications that block until disk transfers complete. Multitasking computers can use one thread to transfer file elements from the file system, and other threads for decoding, synchronizing, streaming, or copying multimedia elements to a CODEC. The ability to freely use computer memory for multimedia permits larger buffers to be used for multimedia streams. The large buffers help absorb the variation in delay that occurs when multimedia is streamed across packet networks. Asynchronous I/O permits multimedia processing to occur while file system requests are being satisfied by a remote file server. ΓòÉΓòÉΓòÉ 2.4.1. Multimedia Quality of Service ΓòÉΓòÉΓòÉ In addition to buffering and multitasking, a multimedia application needs the client/server system to sustain the rates of multimedia streams. The system of delivery and management that includes server computers, disks, client computers and networks is often called a network operating system, or NOS. In order for the NOS to sustain the rates of multimedia streams, to meet the delivery deadlines for multimedia, the NOS must have sufficient resources available. If too much traffic is going to the disk, or if the computer bus is congested, or if the server has insufficient memory, or if the network is overloaded, then multimedia transfers will be late, and this may result in audio and video disruption. Multimedia quality of service (QoS) is a statement about the resources which a multimedia stream requires so that the NOS can ensure that needed resources are allocated to the multimedia stream. QoS specifications appear in practically every communications standard from the Open Systems Interconnect model to the ISDN family of standards. The QoS parameters generally include average throughput, measured in bytes per second over some time interval, and maximum delay. B-ISDN ATM has a highly-evolved (and still evolving) QoS specification that includes delay variation and additional statistical parameters to help the NOS determine how many streams can be permitted to access a particular resource without jeopardizing the quality of service of any stream. ΓòÉΓòÉΓòÉ 2.4.2. Multimedia Stream Controls ΓòÉΓòÉΓòÉ A multimedia stream must get admitted to use system resources such as a disk, server computer, system bus, computer memory, or network links. This implies that some requests will be refused. What refusal means depends on the particular system and application. In a desktop news application, for example, refusal could mean a temporary delay measured in seconds until some other user finishes watching a news clip and releases his or her resources for another to use them. In a movies on demand application, refusal on one resource could mean that another resource is used such as a mirrored disk or an alternative network path. A stream is admitted based upon its quality of service requirements. The system determines, for example, that admitting a stream with a certain rate can be supported and will not cause some other stream to lose its quality of service. This is called an admission control, and it is enough of a control to provide QoS guarantees when the admission control algorithm used in the NOS works properly, and the QoS adequately describes the stream. In the case that the QoS does not describe the stream accurately, it might happen that the actual rate of a stream may exceed the QoS rate that the NOS is expecting. In this situation, the quality of service of all streams is in jeopardy. If the NOS, for example admitted two 150 kilobyte per second streams to a device that can run no faster than 300 kilobytes per second, it will cause a problem if one of the streams runs at 200 or 250 kilobytes per second. One or both of the streams may experience degraded audio and video. Moreover, the cause of the problem will not be apparent: Both streams are affected so it is not clear which stream caused the problem. In a network operating system, furthermore, the problem could occur on any number of devices including the client computer, network links, network bridges, network routers, server computer or disk. Trouble-shooting QoS problems can be complex, and will require new systems management services that can recognize the end-to-end resource reservation requirements of multimedia streams. The systems management functions must be able to track streams through multiple layers of the systems architecture. In present-day systems management, the system view is often one of independent layers. Multimedia systems management will encompass all of present-day systems management facilities and will also support the management of streams and their quality of service attributes. ΓòÉΓòÉΓòÉ 2.4.3. Scaling ΓòÉΓòÉΓòÉ A stream can often run at alternative levels of QoS: It's possible that an audio stream can run at monaural or stereo, and it's possible that a video stream can run at different frame rates or at different levels of resolution. The ability of single stream to have a variety of bandwidth requirements is called scaling. This term has a number of different meanings. In the p*64 teleconferencing standards, there is a protocol between teleconferencing CODEC's to negotiate the compression used for the audio and video. At session initialization time, the protocol is used to match the capabilities of the source CODEC to the capabilities of a destination CODEC. It may be that both source, destination, and network can support 384kBps video, for example, or that one component can only support 64kBps. Thus, the encoding and rate of the stream is matched to that which all devices can accept. But once the encoding and rate are determined, they are not dynamically changed for the duration of the session (renegotiation using the protocol is needed to change the stream rate in p*64). This session-level scaling is similar to that found in video software decode products such as Microsoft's Indeo(TM). The software that controls the decoding will scale the Indeo frame rate depending upon whether the decompression is performed in hardware or software. It is also possible to scale a stream dynamically based upon the current capabilities of the network: Dynamic scaling will vary the rate of the stream during the session causing the frame rate to drop, stereo sound to become monaural, high-fidelity to become low fidelity, or for some other degradation in service that will reduce the overall bandwidth requirements of the stream without causing the stream to degrade beyond some minimal level. There are a few problems, however, with dynamic scaling. First, congestion on the network may be very brief and by the time the multimedia server responds to it, the congestion may have subsided. Oscillating congestion has been observed in the Internet by researchers at MIT, and this suggests the possibility that the server's scaling may end up oscillating as the server attempts to respond to temporary congestion, which subsides at about the same time that the server scales back the flow; when the server scales up, then oscillating congestion may occur again and cause the server to respond. In each case, the server's response could result in scaling back the flow after the congestion condition subsides. On most LAN's, moreover, there is no fairness mechanism: The station with the most to send gets the most bandwidth. For this reason, scaling on Ethernet LAN's in response to congestion may have the result of simply giving other traffic more bandwidth and the multimedia stream less. A second problem with dynamic scaling is a human factors issue: People accustomed to television, radio, telephone and CD players are not accustomed to the quality suddenly changing during the playback. We may expect that dynamic alteration in the quality of playback will prove unacceptable to people even in the short-run. Moreover, it will be more difficult to troubleshoot problems experienced by multimedia streams that are dynamically changing when it is hard to determine when the system is working properly. The third problem with dynamic scaling is a more general distributed multimedia problem: Multimedia playback and teleconferencing will increase the utilization of present-day LAN's above and beyond what these LAN's were configured to support. Network administrators configure LAN's to have very low utilization so the system response will be good at times of peak load. Use of dynamic scaling to run multimedia streams over existing backbone networks will adversely affect existing applications by increasing the utilization of the backbone networks thus causing more congestion and increased delays. In order to run multimedia streams across a campus or enterprise network, the backbone network must be upgraded. For reasons of economics and to minimize disruption, network backbones need to be upgraded gradually. And the solution that permits the existing infrastructure to be reused to the greatest degree will have the greatest probability of acceptance. ΓòÉΓòÉΓòÉ 2.4.4. LAN's, Virtual LAN's, IsoLAN's and B-ISDN ATM ΓòÉΓòÉΓòÉ There are a number of strategies for upgrading existing networks for high-bandwidth, multimedia applications. Many solutions use a device called a hub which serves as an interface to high-speed local area or wide area network backbone. The hub performs conventional bridging and routing functions in addition to providing high-bandwidth services. Some hubs, for example, perform a switching function to support direct Ethernet attachment to a single workstation so the workstation may get guaranteed service of up to 10Mbps. Hubs are being developed to use 100Mbps FDDI or ATM on the backbone and Token Ring or Ethernet to the end-stations. Using the hub as the interface to the high-speed network backbone protects the customer's investment in Ethernet, Token Ring, and other network adapters while providing new services. Virtual LAN hubs and bridges can provide point-to-point services through an enterprise or public wide area network. The virtual LAN creates a LAN out of workstations that are physically attached to different LAN's or directly attached to the wide area network. Virtual LAN products, such as IBM LAN Distance, can use T1, ISDN, and T3 links to support wide area service to LAN-attached workstations. Increasingly, virtual LAN and hub products are supporting the quality of service and resource reservation features needed for multimedia services. We can expect that we will see more devices and products capable of accepting and using a QoS specification for multimedia so that service guarantees can be provided across the campus, enterprise and even public networks. Integrated Services Digital Networks (ISDN's) have QoS specifications as part of their standard. Q.931 specifies the Basic Rate Interface (BRI) of 64 kilobits per second, and Primary Rate Interface (PRI) of up to 1.5 megabits per second. Q.933 is the frame relay standard that is suitable for wide area packet services up to PRI speeds. And Q.93b is the Broadband ISDN (B-ISDN) specification for Asynchronous Transfer Mode (ATM) networks. Q.93b has the most complete proposal to date for quality of service. The current ATM proposal is from an industry-based organization called the ATM Forum though the standards body that approves all of the ISDN standards is the CCITT. The ATM Forum has draft standards proposals for B-ISDN ATM implementations, and ATM networks are now becoming commercially-available. In the long-run, ATM is the most promising solution for digital multimedia delivery throughout a campus, an enterprise, or public networks. There are interim solutions that are also being proposed for multimedia networking, such as Isochronous LAN's or IsoLAN's. Isochronous literally means equal time. An isochronous network has a master clock that can be used for multimedia devices for synchronization and streaming. Isochronous networks, such as ISDN, and local area networks such as FDDI-II and IsoEthernet, can guarantee effectively zero delay variation for multimedia. IsoLAN's are hybrid circuit-switching/packet-switching networks which use variations of the ISDN Q.931 standard for multimedia, but also provide packet services as well. FDDI-II has a packet channel and circuit channels. The packet channel can be used for conventional data communications; circuit channels are suitable for multimedia flows that do not require fault detection and recovery. The Motion Picture Experts Group standard, MPEG, and the CCITT (International Consultative Committee on Telegraph and Telephone) teleconferencing standard, p*64, are well-suited for circuits. DVI, Ultimotion and Indeo are not. A circuit is unlike a Token Ring or Ethernet link in that bits are sent and not communications frames. The use of frames permit a checksum to be included to detect when errors occur in transmission and when retransmission is to be requested. Given the high-bandwidth available through FDDI-II and IsoEthernet, it is not economical to provide framing on any collection of 64 kilobit per second channels that can be dynamically assigned to a stream. Thus, use of IsoLAN's for multimedia servers is restricted to more highly-evolved multimedia encodings such as MPEG, where the decoder itself detects and recovers from errors. There are a variety of emerging technologies that may provide both near-term and long-term multimedia networking solutions. Many new types of multimedia networks are becoming commercially-available, and some will undoubtedly gain wide acceptance over the next few years. It's important that a multimedia client/server solution provide a bridge between existing and future networks in order to encourage distributed multimedia application development. OS/2 LAN Server Ultimedia 1.0 provides features to provide quality of service guarantees for multimedia over both existing and new networks. This support includes a resource reservation infrastructure that can be implemented on Token-Ring adapters today as well as B-ISDN ATM networks tomorrow. The network, disk, systems management and other features provided in LAN Server Ultimedia 1.0 are described below. ΓòÉΓòÉΓòÉ 3. LAN Server Ultimedia 1.0 ΓòÉΓòÉΓòÉ Most networks today are not multimedia networks. The use of multimedia hubs, routers and bridges is rare. Multimedia client/server applications, moreover, are just becoming available. LAN Server Ultimedia 1.0 offers support for multimedia client/server applications, and helps standalone applications use files stored on a server over existing Token-Ring and Ethernets. "Figure: LAN Server Ultimedia Configuration" uses the server computer as a network backbone, so there may be no need for a fully-developed multimedia network as a precondition for introducing multimedia client/server applications. The number of multimedia streams is limited to the number of local area networks that are attached to the server. LAN Server Ultimedia has been tested to support up to forty video streams with quality of service. Forty is the maximum number of 1.2Mbps streams that can be run over four 16Mbps LAN's that are attached to the server. Fewer streams can be delivered over 10Mbps and 4Mpbs LAN's. LAN Server Ultimedia Configuration During LAN Server Ultimedia 1.0 testing, client computers running the ActionMedia II video product were instrumented to ensure that they were getting quality multimedia delivery: A counter was installed in client computers to count the number of times that each multimedia stream had a discontinuity during the presentation. A discontinuity is the result of one or more missed deadlines in the transfer of multimedia file elements from the server to the client. Discontinuities cause disruption to the audio and video presentation. Our clients run for hours with few, if any, discontinuities. During the tests, routine file server operations were performed while multimedia streams were running. These operations included file transfers, small record reads, and server commands such as directory requests. On the Token-Ring, the delivery of multimedia streams occurred while other servers were transferring data on the Token-Ring LAN. In both cases, LAN Server Ultimedia's priority services were tested to ensure that this product was a server that could serve all sorts of file serving functions while playing sound, voice, and video as well. ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Table 4. Zero Priority 16 Mbps Token Ring Server Discontinuity Γöé Γöé Counts over 5 Minutes Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé MM CLIENT Γöé UNRESERVED DATA FRAME SIZE Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Γöé 2 KB Γöé 4 KB Γöé 8 KB Γöé 16 KB Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 1 Γöé 1,169 Γöé 3,333 Γöé 5,679 Γöé 6,586 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 2 Γöé 1,397 Γöé 3,308 Γöé 5,074 Γöé 6,727 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 3 Γöé 1,373 Γöé 3,480 Γöé 5,096 Γöé 6,742 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 4 Γöé 1,052 Γöé 2,969 Γöé 4,863 Γöé 6,458 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 5 Γöé 1,288 Γöé 2,935 Γöé 4,820 Γöé 6,555 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 6 Γöé 1,278 Γöé 3,268 Γöé 4,946 Γöé 6,546 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 7 Γöé 927 Γöé 3,373 Γöé 5,094 Γöé 6,777 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 8 Γöé 1,063 Γöé 3,026 Γöé 4,914 Γöé 6,468 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 9 Γöé 1,002 Γöé 2,834 Γöé 4,823 Γöé 6,417 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 10 Γöé 1,263 Γöé 2,684 Γöé 4,704 Γöé 6,399 Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ "Table: Zero Priority 16 Mbps Token Ring Server Discontinuity Counts over 5 Minutes" shows what happens when multimedia streams share a LAN with ordinary traffic. In this table, the effects of streaming multimedia to ten clients without bandwidth guarantees is evident. The counts in the table are discontinuities that result in a loss of audio or video as a result of missed delivery deadlines in the client computers. Thousands of discontinuities occur when data frames were transmitted on the Token-Ring concurrently with the multimedia streams. As shown in "Table: Zero Priority 16 Mbps Token Ring Server Discontinuity Counts over 5 Minutes", the effects are worsened as the size of the data frames are increased: Unreserved file transfers interfere with multimedia streams, and larger frame sizes of the unreserved traffic make matters worse because the proportion of ring bandwidth claimed by the multimedia server is reduced. Priority service can improve this situation by increasing the amount of bandwidth that is available to the multimedia server. ΓöîΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÉ Γöé Table 5. High Priority Token Ring 16 Mbps Server Discontinuity Γöé Γöé Counts over 40 Minutes Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé MM CLIENT Γöé UNRESERVED DATA FRAME SIZE Γöé Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö¼ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé Γöé 2 KB Γöé 4 KB Γöé 8 KB Γöé 16 KB Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 1 Γöé 0 Γöé 0 Γöé 0 Γöé 0 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 2 Γöé 0 Γöé 0 Γöé 0 Γöé 0 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 3 Γöé 0 Γöé 0 Γöé 0 Γöé 0 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 4 Γöé 0 Γöé 0 Γöé 0 Γöé 0 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 5 Γöé 0 Γöé 0 Γöé 0 Γöé 0 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 6 Γöé 0 Γöé 0 Γöé 0 Γöé 0 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 7 Γöé 0 Γöé 0 Γöé 0 Γöé 0 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 8 Γöé 0 Γöé 0 Γöé 0 Γöé 0 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 9 Γöé 0 Γöé 0 Γöé 0 Γöé 0 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö╝ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé 10 Γöé 0 Γöé 0 Γöé 0 Γöé 0 Γöé Γö£ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓö┤ΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöñ Γöé NOTE: Change to IEEE 802.2 protocol used (see Communications Γöé Γöé Transport System Extensions)) Γöé ΓööΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÇΓöÿ "Table: High Priority Token Ring 16 Mbps Server Discontinuity Counts over 40 Minutes" shows how priority service can provide guaranteed service to multimedia clients. The discontinuity counts are all zero in the table, indicating that service guarantees ensured the best possible delivery regardless of the amount of data traffic that was introduced onto the ring while up to ten video streams were being delivered. "Table: High Priority Token Ring 16 Mbps Server Discontinuity Counts over 40 Minutes" also shows that varying the frame sizes of the unreserved data frames had no appreciable effect on multimedia stream delivery. OS/2 LAN Server Ultimedia is designed to provide the highest-quality multimedia delivery on Token-Rings even when the ring is used for conventional applications. Ethernets should be dedicated to the multimedia streams. In all cases, priority service is implemented in the server computer and the server disk subsystem to ensure quality of service for multimedia streams in addition to ordinary file access operations such as file tranfers, small record reads and file system commands such as directory requests. Each of the OS/2 LAN Server Ultimedia features are discussed below. ΓòÉΓòÉΓòÉ 3.1. File System Extensions ΓòÉΓòÉΓòÉ Quality of Service Extended Attributes Program The LAN Server Ultimedia product provides more than a multimedia file server because it extends the IBM OS/2 LAN Server, one of the best performing file servers in the industry. OS/2 LAN Server has been demonstrated running forty video streams for years, and OS/2 LAN Server Ultimedia now demonstrates that this multimedia-serving function can be provided while routine file-serving requests are also handled by the server. OS/2 LAN Server Ultimedia is designed to be a file server that can meet any and all file access needs including multimedia file streaming, small record reads, and file system commands - all happening at the same time. Quality of Service (QoS), has been designed into LAN Server Ultimedia's file system. In order to ensure the QoS of multimedia file playback, resources are reserved at the time that the file is opened. These resources are released at the time that the file is closed. A QoS resource specification is associated with each multimedia file using OS/2 file system Extended Attributes (EA's) which are name/value pairs that can be defined on any file. Our name/value pairs are QoS attributes and their associated values: LAN Server Ultimedia 1.0 has two QoS values, Read Throughput and Read Size. These values can be computed automatically for AVS, AVI, VOC and WAV files, and stored as file system QoS EA's. "Figure: Quality of Service Extended Attributes Program" shows the graphical interface to the QOSEA program which can be used to compute and to update the QoS EA's for a single file or an entire directory of files. File system reservation is configured by file type extension, such as AVI or VOC, and it is triggered when the file is opened. The client application which opens the file may be unaware that reservation is occurring. All of the configuration and reservation takes place on the server computer. In many cases, there is no need to change the software configuration on the client at all. Fast 386 and 486 computers usually have adequate resources to playback multimedia files so there is no need to put a resource reservation system on client computers. Because servers and networks are shared by many users, it is necessary to ensure that applications which require quality of service guarantees can get them. Otherwise, there is no assurance that quality sound, voice or video service can be provided by the system. In the file system, there must be assurances that transfers from disk to memory and memory to network can be made within a given deadline. LAN Server Ultimedia's High Performance File System (HPFS) reserves dedicated memory for multimedia files that are opened with a reservation. Large READ operations to disk are performed for multimedia files to reduce the time it takes to transfer multimedia file elements. HPFS uses the multipriority feature of OS/2 file systems to ensure that multimedia transfers get priority over ordinary file transfers that do not have a file system reservation. This priority feature is the key to LAN Server Ultimedia's ability to support sound, voice, video, and other real-time services in addition to existing file server applications that do not require quality of service. LAN Server Ultimedia's HPFS provides special disk formatting and access services so that the amount of time that it takes to transfer multimedia file elements is always within a known deadline: HPFS multimedia disks are formatted to have large contiguous extent sizes that minimize disk seek operations. Utilities and maintenance programs are provided for multimedia disks. HPFS disk and file access technology offers not only performance guarantees, but an improvement in the number of multimedia sessions which can be supported on today's disk drives and controllers. HPFS can support up to forty 1.2Mbps video sessions from four 2GB disks and two 20MBps SCSI2 disk controllers (Small Computer Systems Interface 2 is a high-performance extension to the widely-used SCSI standard). ΓòÉΓòÉΓòÉ 3.2. Communications Transport System Extensions ΓòÉΓòÉΓòÉ In "Figure: LAN Server Ultimedia Configuration", there are up to four slots in the server computer that can be used for LAN attachment. The networking challenge is to deliver up to forty 1.2Mbps video streams over four LAN adapters. When 10Mbps Ethernet is used, no more than eight 1.2Mbps streams can be supported on each Ethernet LAN; no more than thirty two 1.2Mbps streams can be supported over four Ethernet LAN's. Up to ten 1.2Mbps streams can be supported over a 16Mbps Token-Ring, putting the ring utilization at approximately 80%. Token-Ring adapter manufacturers generally recommend that Token-Ring utilization not exceed 80% for a sustained period of time, since some bandwidth is needed for messages exchanged between network adapters. LAN Server Ultimedia 1.0 implements resource reservation on the Token-Ring by using priority service for the multimedia sessions. In order to maximize the reservable bandwidth for the single, high priority server, a change was implemented in the IEEE 802.2 protocol. Simple use of priority on the Token-Ring is not enough to guarantee more than 50% of the bandwidth for a single multimedia server. This limitation results from the fact that most Token-Ring adapters release the token after each frame is transmitted rather than transmitting as many frames as possible up to the expiration of the token holding timer (THT), as defined in the IEEE 802.5 Token-Ring standard. LAN Server Ultimedia 1.0 is designed to run with a variety of Token-Ring adapters, and to permit up to 80% of ring bandwidth to be reserved for multimedia, when the Token-Ring adapter that is used can support such rates. Reserved Bandwidth Acknowledgement "Figure: Reserved Bandwidth Acknowledgement" shows the effect of using a Reserved Bandwidth Acknowledgement (RBA) procedure to improve the amount of bandwidth that can be reserved by a server on the Token-Ring. The RBA is a small, low priority frame that is transmitted by the LAN Server Ultimedia client when a high-priority frame is received from the multimedia server. The RBA has the effect of increasing the amount of bandwidth available on the ring for high-priority traffic from the server. As shown in "Figure: Reserved Bandwidth Acknowledgement", the RBA procedure that is featured in OS/2 LAN Server Ultimedia clients provides bandwidth guarantees for multimedia streams even when additional traffic is introduced onto the ring with arbitrarily large frame sizes. The bandwidth reservation features are provided by LAN Server Ultimedia's NetBIOS communications transport which has been extended to use priority queueing and to take advantage of priority service on the Token-Ring. Our design is well-suited to future Synchronous FDDI, 100Mbps Ethernet priority channels, and B-ISDN ATM QoS virtual channels. ΓòÉΓòÉΓòÉ 3.3. Resource Reservation System ΓòÉΓòÉΓòÉ The Resource Reservation System of OS/2 LAN Server Ultimedia controls use of server and network resources to ensure the quality of service of multimedia streams. Server and network resources are structured as shown in "Table: OS/2 Reservation System Model" using an object framework. CLASS NAME PARENTS Reservation SOMObject User Reservation Session Reservation Resource Reservation Disk Resource File Resource Machine Resource Network Resource Table 6. OS/2 Reservation System Model "Table: OS/2 Reservation System Model" shows four resources at the bottom of the table. These are disk, network, machine and file resources. These resources are used in reserved sessions, which are accessed by users of the OS/2 Resource Reservations System, namely, HPFS and NetBIOS. In order for a file to be opened for multimedia playback, the disk, network, and server computer resources that are needed to guarantee smooth playback must have adequate capacity for the reservation. This implies that some requests may not be granted and this situation is inevitable: The OS/2 LAN Server can provide file access to up to one thousand concurrent users, but no more than forty 1.2Mbps video streams can be supported on the same server configuration. The capacity of our multimedia servers can be expected to rise in the future, but any system that provides QoS for multimedia streams will reach a limit beyond which admission of more streams will degrade the quality of some or all of the streams. It may be possible to degrade gracefully, but at some point, system capacity will be reached and there is no alternative but to refuse access to some. Configuration is the solution to ensuring that there are adequate resources available for multimedia streams: If fifty concurrent streams are to be supported, then more than one forty stream server is needed. Some means is needed in the multimedia server, however, to determine when the system has reached its capacity. Poor multimedia playback can result from a number of causes with lack of server capacity being one of them. A key function provided by a multimedia server is to track resource capacity and use so that resource problems can be reported and diagnosed. The RRS.LOG file is used by OS/2 LAN Server Ultimedia 1.0 to report system configuration and resource reservation information to the network administrator. 10-11-1993 16:25:00 RRS added subsystem NETBEUI_5B04. 10-11-1993 16:25:00 RRS configured a 33 MHz 486 MCA server. Reservable capacity: 4055040 Currently in use: 0 10-11-1993 16:25:01 RRS configured 4 Mbps 802.5 network adapter #0. Reservable capacity: 400000 Currently in use: 0 10-11-1993 16:25:01 RRS configured 794.75 kBps SCSI disk #1. Reservable capacity: 406911 Currently in use: 0 10-11-1993 16:25:01 RRS configured AVI files for automatic reservation. QoS is <175000 64050>. 10-11-1993 16:25:01 RRS configured AVS files for automatic reservation. QoS is <150000 64060>. < 0 0 0 0 1 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0>. 10-11-1993 16:25:40 RRS added subsystem HPFS386_5B4A. 10-11-1993 16:41:18 RRS added session CLIENT1_5B90 on Disk #1. Throughput: 150881 Read size : 65024 10-11-1993 16:41:18 RRS modified session CLIENT1_5B90 on Network Adapter #0. Throughput: 150881 Read size : 64024 10-11-1993 16:41:44 RRS deleted session CLIENT1_5B90. OS/2 Resource Reservation System Log File "Figure: OS/2 Resource Reservation System Log File" shows the log file report on a multimedia server configuration, capacity and current use. The first line of the log file reports that the NetBIOS subsystem, NETBEUI_5B04, had registered with the Resource Reservation System, or RRS. The next entry reports that the server is a 33 MHz 486 computer with a microchannel (MCA) bus. The following two log entries report that a Token-Ring adapter and SCSI disk are configured. The server computer, network adapter, and SCSI disk all have a field named Reservable Capacity which in each case is a number of bytes per second that the particular device can support. Since these log file entries occur at system start-up, the Currently in use field values are all zero. When multimedia files are opened, these values are increased by the amount of the reservation. The sixth and seventh entries in "Figure: OS/2 Resource Reservation System Log File"report that two file types have been configured for automatic reservation, AVS and AVI files. In each case, a default read throughput and read size is given: AVI files default to 175,000 bytes per second and have a default read size of 65,040 bytes (the size of application reads to the file system default to the recommended value of 65,040). AVS file have a default reservation of 150,000 bytes per second and a default read size of 65,040 bytes. The last three entries in "Figure: OS/2 Resource Reservation System Log File" show what happens when a file is opened: A reservation of 150,881 bytes per second is made on Disk #1, and a similar reservation is made on Network Adapter #0. After a matter of seconds, the reservation ended when session CLIENT1_5B90 closed the multimedia file. The actual reservation for this session did not use the defaults, we know this because 150,881 does not match the configured defaults for the AVS or AVI files as reported in the previous log entries. This value was automatically computed using the QOSEA utility described above. The Reservable Capacity values shown in "Figure: OS/2 Resource Reservation System Log File" were all derived automatically by the Resource Reservation System. OS/2 LAN Server Ultimedia runs a special program to check how the disks are configured and how fast they are - this process is called calibration. Similar values are obtained for network adapters. It is possible for the network administrator to alter the configuration values used by the Resource Reservation System in the system initialization file shown in "Figure: OS/2 Resource Reservation Initialization File". [FILE] readtput = 175000 fileext = AVI readburst = 64000 writeburst = 0 writetput = 0 [MACHINE] CPUTYPE = i486 CPUSPEED = 50 Bustype = MCA reserved = 80 [FILE] READTPUT = 150000 FILEEXT = AVS [NETWORK] ADAPTER = 0 Reserved = 80 OS/2 Resource Reservation Initialization File The network administrator declares the type of computer that is being used in the [MACHINE] section. In both the [MACHINE] and [NETWORK] sections, there is a parameter keyword named Reserved which is used to tune the Resource Reservation System. Setting reserved to 80 permits up to 80% of the resource capacity to be used for multimedia, for example. In this way, the amount of resources that are set aside for multimedia streams can be restricted. It may be, for example, that the network administrator will not want to use 100% of network bandwidth for high-priority multimedia streams. Or the network administrator may want to set aside, say, no more than 80% of disk bandwidth for multimedia streams and leave 20% for ordinary file transfers. The RRS initialization file is also the place where files are configured for automatic reservation with their file type and default reservation parameters declared. ΓòÉΓòÉΓòÉ 4. The Multimedia Servers of the Future ΓòÉΓòÉΓòÉ Multimedia Servers for Campus and Enterprise The simplest multimedia server implementation is shown in "Figure: LAN Server Ultimedia Configuration" where the multimedia streams do not traverse multimedia hubs, routers or bridges; the clients are directly attached to the multimedia server by Ethernet or Token Ring links. There are few commercially-available hubs that perform a multimedia bridging and routing function, so this limitation is a practical necessity: The multimedia LAN server is the network backbone. The Multimedia LAN Server configuration is suitable for a small community of users in a workplace, classroom, kiosk or museum. The Multimedia LAN Server is a network-constrained configuration: The maximum capacity is determined by the bandwidth available through the four or five LAN attachment slots that are provided on most high-end PC servers (additional slots are needed for the disk controllers). Approximately ten 1.2 Mbps multimedia streams can be supported through a Token Ring card and seven or eight can be supported on Ethernet cards. More streams can of course be supported when the rate of each stream is less than 1.2Mbps, and fewer streams of rates that exceed 1.2Mbps can be reserved. Our experience with OS/2 LAN Server Ultimedia suggests that considerably more than forty 1.2Mbps streams can be supported from a 486 PC server when the processor speed is at least 50MHz and a 40MBps system bus is used. It is possible that seventy to eighty 1.2Mbps video streams can be supported on such a server configuration, if the network capacity is be extended by using 100Mpbs or faster links from the server to a hub that performs multimedia routing and bridging functions to Ethernet and Token Ring clients. This is the configuration shown in "Figure: Multimedia Servers for Campus and Enterprise" (a): The clients remain attached to Ethernet and Token Ring LAN's, but a multimedia hub that is capable of performing resource reservation for multimedia streams is used by the server for switching or bridging 100Mbps traffic onto the slower, 10Mbps and 16Mbps LAN's. The Multimedia Campus Server is constrained by the speed of the system bus since transfers must occur twice - from disk to memory and from memory to network. To get more than forty 1.2Mbps video streams, or streams of comparable rates, from the disk subsystem, a RAID (Redundant Array of Inexpensive Disks) is used to provide both higher speed and more efficient storage. The use of 1GB and 2GB disk drives are satisfactory for small video clips, but movies on demand will require higher-capacity disk configurations since a typical movie may use almost two gigabytes of disk storage. As disk arrays that contain as much as 60GB of disk storage are connected to PC servers, the relative cost of the server is diminished relative to the cost of the disk storage. To maximize the utility of the investment in disk arrays, it is necessary to maximize the number of concurrent streams which can use them. Moreover, larger volumes of stored multimedia will have larger communities of user wanting access. Blocking, refusing or delaying access to multimedia servers is an annoyance which is foreign to people accustomed to CD players, telephones, and televisions. Server clusters can greatly expand the availability and accessibility of digital multimedia files. The configuration shown in "Figure: Multimedia Servers for Campus and Enterprise" (b) uses a B-ISDN ATM backbone to connect a file server cluster (RISC or Intel-based) or a multimedia file serving mainframe (or fast minicomputer) to Ethernet and Token Ring clients. B-ISDN quality of service (QoS) virtual channels (VC's) are used for the reserved multimedia streams, but unreserved streams for ordinary file transfers, small record reads, and file server commands must also be supported. The B-ISDN ATM QoS VC's provide bounded throughput, delay and delay variation for multimedia streams, and the infrastructure developed in "Figure: LAN Server Ultimedia Configuration" and "Figure: Multimedia Servers for Campus and Enterprise" (a) for requesting and using these services are applicable to this highly-developed multimedia network. OS/2 LAN Server Ultimedia which has been tested and developed for today's Multimedia LAN server environment shown in "Figure: LAN Server Ultimedia Configuration"uses a Q.933 Frame Relay QoS specification, at the network layer, which should be downwardly compatible with the B-ISDN ATM Q.93b QoS specification. Moreover, the multimedia hub shown in "Figure: Multimedia Servers for Campus and Enterprise"should be upgradable from a FDDI backbone to an ATM backbone to protect the customer's investment in these devices. And the Ethernet and Token Ring multimedia clients from the Multimedia LAN Server and Multimedia Campus Server configurations should work transparently with the Multimedia Enterprise Server as well. ΓòÉΓòÉΓòÉ 5. Conclusion ΓòÉΓòÉΓòÉ IBM's OS/2 LAN Server Ultimedia provides a multimedia LAN Server that can deliver up to forty video streams to LAN-attached workstations. The client workstations can run popular multimedia file formats such as ActionMedia II AVS files, SoundBlaster VOC files, Microsoft Video for Windows and IBM's Multimedia Presentation Manager/2 files. The key feature of OS/2 LAN Server Ultimedia is quality of service (QoS) resource reservation to provide the highest-quality delivery of multimedia file elements from a high-performance server to LAN-attached client workstations. Quality of service support begins with individual files, and LAN Server Ultimedia provides utility programs that compute the resource reservation needed for each individual file that is played. LAN Server Ultimedia has configuration utilities to determine the capacity of the server disk subsystem for multimedia files and to determine the speed of LAN adapters installed on the server. Files that are "played" from an OS/2 LAN Server Ultimedia server have reservations made automatically, at the time the file is opened, on the server's disk, file system and network subsystems. The quality of multimedia delivery of OS/2 LAN Server Ultimedia has been tested under a variety of server and network loads. On the Token-Ring, priority is used to ensure that adequate bandwidth is available for the playback of each multimedia file having a reservation. Ethernet networks should be dedicated to the multimedia flows from the server. In all cases, server quality of service is protected using priority control on disks, server computer hardware and server network adapters. OS/2 LAN Server Ultimedia 1.0 is a multimedia client/server product that can run today's multimedia applications over today's networks. The design of OS/2 LAN Server Ultimedia, moreover, is one that will provide the QoS resource reservation infrastructure needed for future environments that include high-speed FDDI, 100Mbps Ethernet with priority channels and B-ISDN ATM local area networks. -------------------------------------------------------------------------------- OS/2 LAN Server, Multimedia Presentation Manager/2, OS/2, AIX, OS/2 LAN Server Ultimedia, and ActionMedia II are trademarks of IBM Corporation. Windows, Windows NT, Video for Windows, and Indeo are trademarks of Microsoft Corporation. SoundBlaster and SoundBlaster Pro are trademarks of Creative Labs Incorporated. Unix is a trademark of Unix System Laboratories. 
(.txt)