NOTE: These notes are by Allan Gottlieb, and are reproduced here, with superficial modifications, with his permission. "I" in this text generally refers to Prof. Gottlieb, except in regards to administrative matters.


================ Start Lecture #17 (Apr. 16) ================

5.5: Clocks

Also called timers.

5.5.1: Clock Hardware

5.5.2: Clock Software

  1. TOD: Bump a counter each tick (clock interupt). If counter is only 32 bits must worry about overflow so keep two counters: low order and high order.

  2. Time quantum for RR: Decrement a counter at each tick. The quantum expires when counter is zero. Load this counter when the scheduler runs a process.

  3. Accounting: At each tick, bump a counter in the process table entry for the currently running process.

  4. Alarm system call and system alarms:
  5. Profiling

Terminals

Old-style (1980's) terminal: Keyboard and monitor.

Computer received a sequence of characters from the keyboard and sent sequence of characters to the monitor. Keyboard and monitor have separate drivers.

Keyboard

Sequence of ordinary characters plus control characters.
One process is the foreground process, receives keyboard characters.

Raw mode vs. cooked mode. In raw mode, characters are delivered to the process one at a time (e.g. screen editor). In cooked mode, data is delivered one line at a time; i.e. the process blocks until "Return" is hit, and characters like "BackSpace" perform an editing function.

Reasonably similar to reading from a text file. Main difference is that there is no case in which the system waits for a block-sized buffer to be filled, as with disk reads.

Collection of dull issues:

Monitor

24x80 character display
Boolean pixels. (Monochromatic, one level of "on" intensity.)
Sequence of ordinary characters plus control characters sent to monitor, displayed in sequence left-to-right, top-to-bottom. Cursor at position for next character. Fixed character sets. Device controller responsible for translating into CRT image. Control characters did things like Essentially identical to writing to text file, except that there is no buffering and no need to maintain a file structure.

More dull issues:

Graphics terminal

A terminal consists of a keyboard, a mouse (or mouse-equivalent, such as a touch-pad), and a display. At a low level these are separate I/O devices, with separate controllers. At a higher level, it's arguably better to think of the terminal as a single I/O device. The user interface is essentially a device driver for the terminal as a whole. There are not device drivers of any importance for the separate parts.

Keyboard

Keyboard controller reports each pressing of a key and each release of a key as an "event" to OS; everything else is done in OS software. Maximal flexibility.

Mouse

Reports distance moved in units of 0.1 mm in each direction (X,Y) + push click + release click. Software keeps track of position by dead reckoning. This is not very accurate -- e.g. you can't use a mouse for tracing a picture, you need a device like a want that reports actual coordinate. But it doesn't matter, because the user is judging the position, not by the position of the mouse, but by position of mouse icon (or surrogate) in display. What matters is that the position of icon accurately reflects the software's idea of the position of the mouse, and that OK, because of monitor feedback.

Monitor

A monitor has M x N (e.g. 1024 x 768) pixels, each of which has three displays (Red, Green, Blue) of intensity 0 ... 255 (8 bits) Thus, a complete screen image is about 3 MByte, depending on resolution. Each pixel refreshed 50 or 22 times per second. Monitors are characterized by: Image compression (e.g. JPEG) exploits loss tolerance and the prevalence of large patches of constant or near constant color. Video compression (e.g. MPEG) additionally exploits (5); you represent the change from one frame to the next.

CPU writes to video RAM; Video controller scans video RAM continuously. Video RAM is addressable like ordinary RAM.

Colors:

User interface

The user interface is in effect a (very complicated) device driver for the terminal as a whole. Some features: To some degree, each window is a virtual output device. E.g. "Standard output" in a C or a Java program writes to one window, and the "device independence" of such programs -- i.e. the equivalence of writing to a window with writing to a file --- applies to this virtual device. (This is more important in UNIX systems, where most windows simulate a character-based monitor, than in WINDOWS or Macintosh systems.) However, this is purely a software construction, not an actual I/O interface.

Networks

From the point of view of each individual node, network communication is just another I/O device.
Processes generate messages to be sent out. Device driver packages them appropriately and sends them out on the network.
Message arrive from the network. Device driver interprets the packaging, reassembles the original message, and figures out what to do with them: The more interesting standpoint is looking at the distributed system as a whole. There are varying degrees of integration:

Local Area Network (LAN) vs. Wide Area Network (WAN)

LAN (e.g. Ethernet) WAN (Internet)