One of the new features of the textbook for the course is a detailed discussion of multimedia operating systems, in particular, issues involved in the design of an operating system whose primary job is serving videos. As I was working on this lesson, it occurred to me that I was just paraphrasing the book for this material. As a result, this on-line lesson is abreviated. Do not assume that just because a video topic is not covered here, it is not important. Read this chapter closely.
Video on demand requires huge servers. The system has to be able to access, say, 1000 disks, and distribute signals to the distribution network at high speed in real time.
The NTSC (National Television Standards Commission) standard specifies 30 frames per second, or one frame every 33.3 msec. If each frame is 640 by 480 bytes, a raw image is 307,200 bytes per frame. At 30 frames per second, the server has to send out 9,216,000 bytes per second or 55,296,000 bytes per minute for each movie. This means that multimedia files are enormous. A two hour uncompressed 640x480 movie requires almost 200GB of disk space. But 640x480 format is being replaced by High Definition Television (HDTV). An uncompressed two hour HDTV movie requires 570GB. This means that a video server with 1000 movies needs 570 TB of disk.
The only way for an operating system to be able to do this is to reserve bandwidth, CPU, memory, etc. ahead of time. So the server has an admission control algorithm; it cannot accept a new request unless it can be reasonably confident that it will be able to satisfy it.
Uncompressed movies are far too big to transmit. Thus the system needs a compression (encoding) algorithm and a decompression (decoding) algorithm. The former can be slow and/or expensive, because it is only done once, but the latter has to be fast. Unlike a regular file compression algorithm, an image compression algorithm can be lossy. This means that some data can be lost.
The standard compression algorithm for images is JPEG. This is explained in detail in your text, and so I will not cover it here. The standard video compression algorithm is MPEG, which is also covered in detail in your text. Make sure that you understand how these work.
Multimedia Process Scheduling
An operating system whose primary job is serving videos would differ from a traditional operating system in three ways.
But you need a timing mechanism to make sure that each process runs at the correct frequency. Run a clock with 30 ticks per second. At each tick, all threads are run sequentially in the same order, when a thread is done, it issues a suspend system call that releases the CPU. This algorithm works perfectly as long as the number of threads is small enough.
But there is a problem. The frame sizes for MPEG differ in size, and processes come and go. So this leads us into a discussion of general real timeprocess scheduling.
Real Time Process Scheduling
From a scheduling point of view, the definition of real time means that at least some of the processe have strict deadlines that must be met. Late equals wrong. Real time sheduling can be either periodic in which deadlines happen at regular intervals, or aperiodic, in which deadlines happen unpredictably. Video is the classic example of periodic real time scheduling. There are three parameters.
It is possible that there is no scheduling algorithm which can satisfy this requirement. This formula tests this.
In this formula m is the number of processes, 3 in this case, Pi is the period of Process i, and Ci is the amount of CPU time needed per cycle.
Sustituting our data into this formula
10/30 + 15/40 + 5/50 = .333 + .375 + .100 = .808
Since this is less than 1, the problem is potentially solvable.
Your text discusses two algorithms to address this problem. Both of these assume that we know this information in advance (a reasonable assumption, at least in the case of video) and that there is no overhead associated with context switching (not reasonable, but it makes things much easier).
Rate Monotonic Scheduling (RMS) With RMS, each process has a priority based on its frequency; the higher the frequency, the higher the priority. Then the system just has to run the process with the highest priority, with a higher priority process preempting a lower priority process if necessary. However, we need the caveat that a cycle for each process only begins at the time of the prior deadline; otherwise we would just always run the process with the highest frequency.
Earliest Deadline First Scheduling (EDF) As the name implies, just run the process with the earliest deadline. No preemption is necessary.
Here is a diagram from your text showing how these two algorithms work with the above data.
Simulations show that overall, EDF is a better algorithm; your text shows an example where RMS fails while EDF does not.
Placing multimedia files on disk
Multimedia files require different placement strategies than ordinary files. This is because disk access is very much more predictable. Your text talks at great length about this issue, and very well, so I do not feel as though I need to repeat this material here.
Computers have been connected together since the 1970's, but in the 1990's, the Internet created a revolution in how computers were used. Now essentially all computers are connected to a network of some sort, and the notion of a computer as a free-standing box on your desk is obsolete. Since most of what this course has covered so far has treated a computer as a free-standing box, this means that a lot of what we have discussed so far is rapidly becoming obsolete. To an increasing extent, computing itself, and the implementation of an operating system is distributed; i.e., spread across several computers. The logical image of a file system is a set of files on a hard drive on one computer, but many (most) file systems are distributed now. Many large applications such as databases are distributed, with the data residing on one computer and the users connecting to it remotely. Some fundamental operating system functions can be done remotely; we can talk about remote procedure calls in which a process on one computer executes a procedure call which is executed on another computer.
Before we can discuss how these are implemented, we need some basic networking terminology.
There are two types of network technology
There are two broad classes of networks based on their scale.
Networks have two components, transmission lines and switching elements. The switching elements are computers that connect the lines and route packets. These include routers, gateways, bridges and other kinds of switches.
In general, LANs are broadcast and WANs are point-to-point, but there are exceptions.
Protocol Stacks
The concept of a protocol stack underlies much of the study of networking. A protocol stack is a set of protocols that work together to transmit information from one computer to another. The protocols are layered, and each layer has the illusion that it is communicating with the equivalent layer on the other computer, but in fact it is communicating with the layers above it and below it in the stack.
An analogy might be President Bush talking to Pervez Musharraf, the President of Pakistan. President Bush speaks English (sort of), and President Musharraf speaks Urdu (He might speak English as well, but let's pretend that he doesn't). Bush says something in English, looking at President Musharraf, but in fact he is speaking to a translator. The translator translates what he says into Urdu. President Musharraf replies in Urdu, looking at President Bush, but in fact he is speaking to a translator.
The archetype protocol stack is the ISO (International Standards Organization) OSI (Open Systems Interconnection) Reference Model. This is a seven layer protocol stack on which all other protocol stacks are based, but, to my knowledge, no "real world" communication systems actually use this model in its entirety. Most Internet applications use a four level stack for example. I am going to break with a long tradition and discuss protocol stacks using the four level Internet stack rather than the seven level ISO-OSI stack. Here is a diagram of the Internet Protocol Stack.
This diagram shows two computers, labeled Host A and Host B (computers on networks are often called hosts), and an Intermediate Router. In practice there may be many intermediate switching element, but only one is shown. An application on Host A wants to communicate with a peer application on Host B. The two applications must speak the same protocol. A typical example would be a web brower which wishes to request a document from a web server in a distant city. The protocol that web browsers and web servers use to communicate is http which stands for HyperText Transmission Protocol.
The Application Layer (the web browser) on Host A has the illusion that it is communicating directly with the server on Host B (please pardon the anthropomorphism), but in reality it sends its message to the Transport Layer software on the same computer. In the diagram, the dotted arrow represents the illusion, the solid arrow represents reality.
The Transport Layer is responsible for making sure that complete messages are delivered end to end. This may sound like a trivial problem but it is not, because messages are often broken up into chunks as they are sent over the Internet, and it is possible for these chunks to get lost. Also, they may not arrive in the same order that they are sent.
The Transport Layer Protocol that is generally used on the Internet is TCP, the Transmission Control Protocol. This will be described in more detail below. For the moment, you need to know that the TCP layer on the sending computer establishes a connection with the TCP layer on the receiving computer, and they talk TCP to make sure that the message is received in its entirety and free of errors.
TCP may break a large message into smaller segments. The Segment is the unit of transmission.
The two TCP layers have the illusion that they are talking to each other, but in reality, they communicate with the Network Layer. The only network layer protocol used on the Internet is the Internet Protocol (IP).
The Network Layer is responsible for routing messages from one place to another. On a broadcast network, there is no network layer because all messages are sent to all computers, but on a point-to-point network, the Network Layer has to figure out how to get a message to its end point. Often there are several choices. Here is a simple diagram of a point-to-point network, with Host A and Host B identified. The other circles are switching elements. Each of these is running a Network Layer; if this was the Internet, all would be running IP. Many switching elements have several choices of how to forward a message, and the Network Layer decides which pathway to take.
Note in the Protocol stack diagram above, there is an Intermediate Router. The top two layers, the Application Layer and the Transport Layer, run only on the two end computers but the lower two layers, the network layer and the Physical Layer, run on each intermediate node as well. Recall that although there is only one Intermediate Router shown, there may be many such switching elements between the two hosts.
The unit of transmission on the Internet is the packet. IP may take a large segment and break it up into smaller packets.
The bottom layer is the Physical Layer. This is responsible for actually translating the software message into a physical representation and putting them on the wire (or through the air in a wireless network). This is an enormously complex undertaking, but is primarily in the realm of computer engineering rather than computer science, so for this course, we can just assume that there is a phyical layer without going into too much detail.
The unit of transmission on the physical layer is the frame.
There are numerous different physical layer protocols, and a message which takes a number of hops on the internet to get from one host to another will be translated into a number of different physical representations. A typical physical layer protocol is IEEE 802.3, commonly known as Ethernet.
Each layer of the protocol stack on the sender side does its work by attaching a header ( and sometimes trailing information as well) to the message which is passed down from the next higher layer in the stack. The Transport Layer receives a message from the application; it attaches a TCP header onto the front and passes this down to the network layer. The network layer appends an IP header onto the front of this and passes it on to the physical layer. The physical layer (ethernet for example) attaches a header (and a checksum trailer) to this message and sends it to the next switching element.
In theory, the message received at each layer is identical to that sent by the corresponding peer at the other end.
The physical layer of the receiver reads the header information, strips the header (and trailer) off and passes the remainder to the network layer. The network layer reads the IP header (ignoring the rest of the message). If this is the final destination of the message, the network layer strips off the IP header and passes the remainder of the message up the stack to the TCP layer. Otherwise, the network layer determines where to send the message for its next hop and passes the message back down the physical layer for its next journey.
The Transport layer at on the receiving host reads the TCP header, strips it off, and passes the message up to the appropriate application process.
Now that you know what a protocol stack is, we can discuss the actual protocols.
IEEE 802.3 (Ethernet)
Ethernet is one of a number of LAN technologies, but it is probably the most widely used, and the algorithms involved are fascinating, so I will use this as an example of physical layer protocol.
Ethernet, like most LAN protocols, is a broadcast protocol, which means that all of the hosts on the network receieve all packets, but only the designated receiver passes it on up to the appropriate application. It is often diagrammed like this.
Here we see a local area network with seven hosts, all connected to a cable. Each host has an ethernet card, and each ethernet card has a unique identifying number. This is a 48 bit code, and is unique on the planet. The ethernet card listens to the network and if it sees a message with its code, it passes it up, otherwise it ignores it. So if Host B wants to send a message to Host F, it puts the ethernet address of host F in the ethernet header and puts the message on the wire.
The ethernet frame contains the following fields.
There has to be a minimum frame size to prevent a station from completing the transmission before the first bit has reached the far end of the cable.
There is a time lag between when a host starts putting a message onto the cable and when it reaches the two ends, and as a result of this, it is possible that two hosts may start transmitting at the same time. The result is that both messages get corrupted. The two hosts that are tranmitting are able to detect this, and they immediately stop transmitting. They use a strategy called binary exponential backoff to solve the collision problem. Each of the two hosts (in fact there could be more than two, but we will assume that only two hosts are trying to transmit at once) generates a random bit, either zero or one. If the bit is zero, the host starts transmitting again immediately. If the bit is one, the host waits for a period of time to allow a frame to get from one end of the cable to the other before starting to transmit. There is a fifty fifty chance that they will generate different random numbers, in which case both messages get tranmitted successfully. However, there is also a fifty-fifty chance that they will both generate the same random bit, and thus have another collision. If this occurs, each now generates a random number in the range 0 .. 3, and waits that number of time slices before transmitting. Now there is a 75 percent chance that both messages will be successfully transmitted, but a 25 percent chance that there will be yet another collision. In that case, they generate a random number between 0 and 7, and wait that many time slices before retransmitting. Now there is a seven in eight chance that both messages will be transmitted, and only one chance in eight that there will be yet another collision. This process continues until both messages get successfully transmitted.
The Internet Protocol (IP)
The Internet Protocol, IP, is connectionless and unreliable. A connection oriented network is one where a connection is established between the sender and the receiver before any data is sent, while a connectionless network is one in which the sender justs transmits the packet. The usual analogy here is between the phone system and the post office. The phone system is connection-oriented. Before any data gets sent (i.e. before the two speakers say anything), a connection between the two telephones is established, and all of the information takes the same path. The post office transmission system is connectionless. The sender just drops a letter into the mailbox and hopes that it gets there, and that is the way that IP works.
The fact that the Internet Protocol is unreliable says nothing about the probability of losing information; this term means that delivery is not guaranteed. If a packet gets lost, neither the sender nor the receiver will necessarily know.
Every host on the Internet has a unique IP address. This is a 32 bit number, which is often written in dotted decimal format. For example, the computer on my desk at work has the IP address 128.113.96.159. The Internet consists of numerous end user computers and lots of intermediate switching computers, called IP routers. Most IP routers have connections to many other IP routers. When an IP router receives a packet, it examines the destination IP address in the IP header, and based on information in its router tables, determines which of several possible paths to send it on. IP packets usually take many hops to get from source to destination.
There is a utility called traceroute which reports on
the route that packets take to get from source to destination. When I
entered the command
traceroute www.yahoo.com
I got the following information
traceroute to www.yahoo.akadns.net (64.58.76.225), 30 hops max, 40 byte packets 1 vccfr4-96.nss.rpi.edu (128.113.96.254) 8.243 ms 2.294 ms 2.810 ms 2 vccfr6.nss.rpi.edu (128.113.39.85) 21.801 ms 8.820 ms 2.389 ms 3 at-gsr1-alb-0-3-rpi-OC3.appliedtheory.net (169.130.253.65) 3.016 ms 4.582 ms 9.473 ms 4 at-gsr1-nyc-3-0-OC12.appliedtheory.net (169.130.3.29) 6.963 ms 21.560 ms 17.785 ms 5 12.125.51.209 (12.125.51.209) 7.024 ms 15.251 ms 6.989 ms 6 acr2-so-2-1-0.NewYork.cw.net (206.24.193.129) 34.552 ms 18.876 ms 8.189 ms 7 acr1-loopback.Boston.cw.net (208.172.50.61) 15.309 ms 15.731 ms 22.024 ms 8 ibr02-p5-0.wlhm01.exodus.net (208.172.51.202) 14.333 ms 13.581 ms 23.352 ms 9 bbr01-g1-0.wlhm01.exodus.net (64.14.70.51) 14.341 ms 13.405 ms 14.724 ms 10 bbr01-p1-0.wlhm03.exodus.net (206.79.9.105) 20.403 ms 19.651 ms 17.633 ms 11 bbr02-g2-0.wlhm03.exodus.net (66.37.192.4) 12.875 ms 14.502 ms 12.888 ms 12 bbr01-p2-0.jrcy01.exodus.net (209.1.169.65) 27.500 ms 28.996 ms 23.531 ms 13 bbr02-g3-0.jrcy01.exodus.net (216.32.223.82) 26.236 ms 27.383 ms 23.938 ms 14 bbr01-p6-0.whkn01.exodus.net (216.32.132.14) 31.267 ms * 31.086 ms 15 bbr02-g5-0.whkn01.exodus.net (216.35.65.84) 34.160 ms 40.859 ms 36.631 ms 16 bbr01-p0-0.stng01.exodus.net (216.32.132.193) 33.345 ms * 22.012 ms 17 dcr01-g8-0.stng01.exodus.net (216.33.96.145) 19.509 ms 19.453 ms 19.968 ms 18 csr21-ve241.stng01.exodus.net (216.33.98.18) 21.081 ms 20.236 ms 20.685 ms 19 216.35.210.122 (216.35.210.122) 21.314 ms 24.301 ms 21.958 ms 20 w4.dcx.yahoo.com (64.58.76.225) 19.425 ms 21.083 ms 20.635 ms
This shows that a packet sent from my computer to yahoo takes 20 hops; it has to go through 19 intermediate switching entities (IP routers). Each line shows the name of the computer, the IP address, and three time estimates to get that far. The details of how packets get routed through the internet is far outside the scope of this course. However, you can see that the first two hops are within RPI, and the next two are within appliedtheory.net, which is Rensselaer's Internet Service Provider. The rest are on various Internet backbone networks. These somehow figure out how to get the packets to yahoo.
The current version of IP is version 4, which has been in use for nearly 20 years (this says a lot about its robustness). However, there are some fields and features which are either not used at all or rarely used. Here is the contents of the IP header.
Each intermediate router checks the destination address, looks up the destination in its routing table, and passes it on. The IP header is not changed by the routers with the exception of the TTL field.
The Internet is a network of networks. Routing is done on a network basis. A part of the 32 bit IP address refers to the network and a part refers to the host within the network. For example, Rensselaer has a class B network which means that the first 16 bits of the IP address refer to the Network and the last 16 bits refer to hosts within that network. You may have noticed that the IP address of all computers on RCS start with 128.113. This also means that Rensselaer can have up to 64K computers on its network (actually a few less than that because some addresses are used for broadcast, but we don't need to be too picky here).
The fact that routing is done on a network basis is important because on any large network such as Rensselaer, hosts are added and removed regularly. When the systems administrators add a new computer, they have to assign it a unique IP address starting with 128.113, but they do not need to notify anyone outside of Rensselaer. As soon as it is up, and the local name servers are made aware of it, computers anywhere in the world can connect to it, because all of the intermediate routers simply have to know how to get the packets to the Rensselaer network; they do not need to know anything about the hosts on a particular network. Clearly the gateway computer which links the Internet to the Rensselaer network needs to know about all of the computers on the campus.
The Transmission Control Protocol (TCP)
In contrast to IP, TCP is reliable and connection-oriented. The term reliable means that it confirms that a message is received as sent. TCP is connection oriented because before any data is sent, the sender establishes a connection with the receiver. It may seem paradoxical to be able to run a reliable, connection oriented protocol over a connectionless, unreliable network. Here is how it works.
It provides reliability by doing the following:
There are no record markers, the data is passed on to the application as a stream of bytes. If the sender writes 10 bytes followed by 20 bytes followed by 50 bytes, there is no way that the receiver can tell what size the individual writes were.
There is only one TCP layer on a particular machine, but there can be many applications which receive or send Internet data. Each application on a particular machine has a unique port number, which is an integer in the range of 1 .. 64K. This serves as the identifier so that when a segment is received, the TCP layer knows which application is expecting it.
The TCP header contains the source and destination port numbers, a sequence number indicating where in the message this segment belongs, the TCP checksum, and various flags that we don't care about.
When a sender wants to send a message to a distant computer, the TCP layer on the sending computer first establishes a connection with the TCP layer of the receiver. This is done with a three way handshake; the sender sends a message, saying, in essence, "I want to establish a connection"; the receiver sends an acknowledgement back, saying, in essence, "A connection has been established"; the sender then sends a message back to the receiver saying, in essence, "I got your acknowledgement". (Other information is exchanged as well, but we don't much care about that now). Once the connection is established, both the sender and the receiver can send messages back and forth.
When the two hosts wish to break the connection, there is a four way handshake, with each end of the connection sending a terminate connection message and the other end acknowledging it.
Another Transport Layer Protocol which is widely used on the Internet is the User Datagram Protocol (UDP). This is a connectionless, unreliable protocol which simply passes packets from the IP layer up to the application layer, with no attempt to acknowledge them. The advantage of UDP is that it is much faster and more efficient than TCP. To send a single short message using TCP, a total of at least eight packets have to be sent over the Internet, the three way handshake, the data itself, and the four way handshake to terminate the connection. The disadvantage of UDP is that it is unreliable, but recall that the term unreliable in this context does not mean that a high percentage of packets are lost; it simply means that the protocol does not guarantee delivery. The message which is sent using UDP is called a datagram. UDP uses ports in the same way that TCP does; the receiving application listens for UDP datagrams on a particular port, with the port numbers in the range 1 .. 64K.
Application Layer Protocols
There are a large number of application layer protocols in use on the Internet. We have already discussed http, the Hypertext Transport Protocol, that web browsers use to communicate with web servers. Other examples include ftp the file transfer protocol, telnet, which allows a user to log into a remote host, ssh, the secure shell, that most of you use to log in to our Solaris system (this differs from telnet in that all communication is encrypted), and SMTP, the simple mail transfer protocol. The details of these protocols are far beyond the scope of this course.
Data Representation
One problem that network applications have to deal with is that different architectures represent data differently. For example, there are two different methods that a computer can use to represent a 32 bit integer. These are called big-endian and little-endian (these terms are borrowed from Gulliver's Travels).
On a big-endian computer, if a 4 byte int is stored at address A, the most significant byte is at byte A and the least significant byte is at byte A+3. On a little endian computer the low order byte is at byte A and the highest order byte is at byte A+3. Big endian computers include the IBM 370, Motorola 68000, and SPARC. Little endian computers include the DEC Vax series and, significantly, Intel processors such as the Pentium.
By convention, the Internet and all of its protocols are big endian. This means that when a process running on a Pentium wants to send data over the network, it has to convert all of its integers (and short ints) from its native language (little endian) to big endian, and when it receives data from the internet which contains integer values, it has to convert them from big endian to little endian.
There are other issues as well around data representation. This has led to the development of a standard for data representation called Abstract Syntax Notation One (ASN.1) , which is a general method of representing data, independent of hardware. Applications which need to worry about this convert all of their data to ASN.1 before transmitting it and convert all data which they read off of the Internet from ASN.1 to their own native representation.