WEBVTT 00:00:00.539 --> 00:00:06.120 Computer systems bring together many technologies and harness them to provide fast execution 00:00:06.120 --> 00:00:07.319 of programs. 00:00:07.319 --> 00:00:12.830 Some of these technologies are relatively new, others have been with us for decades. 00:00:12.830 --> 00:00:17.400 Each of the system components comes with a detailed specification of their functionality 00:00:17.400 --> 00:00:18.970 and interface. 00:00:18.970 --> 00:00:24.050 The expectation is that system designers can engineer the system based on the component 00:00:24.050 --> 00:00:30.450 specifications without having to know the details of the implementations of each component. 00:00:30.450 --> 00:00:35.140 This is good since many of the underlying technologies change, often in ways that allow 00:00:35.140 --> 00:00:41.090 the components to become smaller, faster, cheaper, more energy efficient, and so on. 00:00:41.090 --> 00:00:46.329 Assuming the new components still implement same interfaces, they can be integrated into 00:00:46.329 --> 00:00:48.829 the system with very little effort. 00:00:48.829 --> 00:00:55.920 The moral of this story is that the important part of the system architecture is the interfaces. 00:00:55.920 --> 00:01:01.670 Our goal is to design interface specifications that can survive many generations of technological 00:01:01.670 --> 00:01:03.180 change. 00:01:03.180 --> 00:01:07.970 One approach to long-term survival is to base the specification on a useful abstraction 00:01:07.970 --> 00:01:12.990 that hides most, if not all, of the low-level implementation details. 00:01:12.990 --> 00:01:17.890 Operating systems provide many interfaces that have remained stable for many years. 00:01:17.890 --> 00:01:24.408 For example, network interfaces that reliably deliver streams of bytes to named hosts, hiding 00:01:24.408 --> 00:01:29.120 the details of packets, sockets, error detection and recovery, etc. 00:01:29.120 --> 00:01:34.229 Or windowing and graphics systems that render complex images, shielding the application 00:01:34.229 --> 00:01:37.920 from details about the underlying graphics engine. 00:01:37.920 --> 00:01:43.310 Or journaled file systems that behind-the-scenes defend against corruption in the secondary 00:01:43.310 --> 00:01:44.908 storage arrays. 00:01:44.908 --> 00:01:50.130 Basically, we're long since past the point where we can afford to start from scratch 00:01:50.130 --> 00:01:55.259 each time the integrated circuit gurus are able to double the number of transistors on 00:01:55.259 --> 00:01:58.250 a chip, or the communication wizards figure out how 00:01:58.250 --> 00:02:04.520 to go from 1GHz networks to 10GHz networks, or the memory mavens are able to increase 00:02:04.520 --> 00:02:07.950 the size of main memory by a factor of 4. 00:02:07.950 --> 00:02:13.730 The interfaces that insulate us from technological change are critical to ensure that improved 00:02:13.730 --> 00:02:17.120 technology isn't a constant source of disruption. 00:02:17.120 --> 00:02:23.219 There are some famous examples of where an apparently convenient choice of interface 00:02:23.219 --> 00:02:26.950 has had embarrassing long-term consequences. 00:02:26.950 --> 00:02:33.200 For example, back in the days of stand-alone computing, different ISAs made different choices 00:02:33.200 --> 00:02:37.579 on how to store multi-byte numeric values in main memory. 00:02:37.579 --> 00:02:43.849 IBM architectures store the most-significant byte in the lowest address (so called "big 00:02:43.849 --> 00:02:49.480 endian"), while Intel's x86 architectures store the least-significant byte first (so 00:02:49.480 --> 00:02:51.629 called "little endian"). 00:02:51.629 --> 00:02:56.420 But this leads to all sorts of complications in a networked world where numeric data is 00:02:56.420 --> 00:02:59.370 often transferred from system to system. 00:02:59.370 --> 00:03:06.659 This is a prime example of a locally-optimal choice having an unfortunate global impact. 00:03:06.659 --> 00:03:12.430 As the phrase goes: "a moment of convenience, a lifetime of regret." 00:03:12.430 --> 00:03:18.769 Another example is the system-level communication strategy chosen for the first IBM PC, the 00:03:18.769 --> 00:03:23.079 original personal computer based Intel CPU chips. 00:03:23.079 --> 00:03:28.760 IBM built their expansion bus for adding I/O peripherals, memory cards, etc., by simply 00:03:28.760 --> 00:03:34.540 using the interface signals provided by then-current x86 CPU. 00:03:34.540 --> 00:03:39.159 So the width of the data bus, the number of address pins, the data-transfer protocol, 00:03:39.159 --> 00:03:44.819 etc. where are exactly as designed for interfacing to that particular CPU. 00:03:44.819 --> 00:03:51.249 A logical choice since it got the job done while keeping costs as low a possible. 00:03:51.249 --> 00:03:57.689 But that choice quickly proved unfortunate as newer, higher-performance CPUs were introduced, 00:03:57.689 --> 00:04:04.560 capable of addressing more memory or providing 32-bit instead of 16-bit external data paths. 00:04:04.560 --> 00:04:09.689 So system architects were forced into offering customers the Hobson's choice of crippling 00:04:09.689 --> 00:04:13.319 system throughput for the sake of backward compatibility, 00:04:13.319 --> 00:04:17.760 or discarding the networking card they bought last year since it was now incompatible with 00:04:17.760 --> 00:04:20.220 this year's system. 00:04:20.220 --> 00:04:22.190 But there are success stories too. 00:04:22.190 --> 00:04:29.260 The System/360 interfaces chosen by IBM in the early 1960s carried over to the System/370 00:04:29.260 --> 00:04:36.950 in the 70's and 80's and to the Enterprise System Architecture/390 of the 90's. 00:04:36.950 --> 00:04:41.240 Customers had the expectation that software written for the earlier machines would continue 00:04:41.240 --> 00:04:46.360 to work on the newer systems and IBM was able to fulfill that expectation. 00:04:46.360 --> 00:04:52.670 Maybe the most notable long-term interface success is the design the TCP and IP network 00:04:52.670 --> 00:04:59.480 protocols in the early 70's, which formed the basis for most packet-based network communication. 00:04:59.480 --> 00:05:06.790 A recent refresh expanded the network addresses from 32 to 128 bits, but that was largely 00:05:06.790 --> 00:05:09.600 invisible to applications using the network. 00:05:09.600 --> 00:05:15.570 It was a remarkably prescient set of engineering choices that stood the test of time for over 00:05:15.570 --> 00:05:21.250 four decades of exponential growth in network connectivity. 00:05:21.250 --> 00:05:26.000 Today's lecture topic is figuring out the appropriate interface choices for interconnecting 00:05:26.000 --> 00:05:28.060 system components. 00:05:28.060 --> 00:05:32.860 In the earliest systems these connections were very ad hoc in the sense that the protocols 00:05:32.860 --> 00:05:38.700 and physical implementation were chosen independently for each connection that had to be made. 00:05:38.700 --> 00:05:44.320 The cable connecting the CPU box to the memory box (yes, in those days, they lived in separate 00:05:44.320 --> 00:05:50.300 19" racks!) was different than the cable connecting the CPU to the disk. 00:05:50.300 --> 00:05:54.700 Improving circuit technologies allowed system components to shrink from cabinet-size to 00:05:54.700 --> 00:05:58.570 board-size and system engineers designed a modular packaging 00:05:58.570 --> 00:06:03.710 scheme that allowed users to mix-and-match board types that plugged into a communication 00:06:03.710 --> 00:06:05.390 backplane. 00:06:05.390 --> 00:06:09.330 The protocols and signals on the backplane reflected the different choices made by each 00:06:09.330 --> 00:06:16.670 vendor - IBM boards didn't plug into Digital Equipment backplanes, and vice versa. 00:06:16.670 --> 00:06:21.130 This evolved into some standardized communication backplanes that allowed users to do their 00:06:21.130 --> 00:06:27.120 own system integration, choosing different vendors for their CPU, memory, networking, 00:06:27.120 --> 00:06:28.120 etc. 00:06:28.120 --> 00:06:32.630 Healthy competition quickly brought prices down and drove innovation. 00:06:32.630 --> 00:06:38.840 However this promising development was overtaken by rapidly improving performance, which required 00:06:38.840 --> 00:06:46.030 communication bandwidths that simply could not be supported across a multi-board backplane. 00:06:46.030 --> 00:06:50.400 These demands for higher performance and the ability to integrate many different communication 00:06:50.400 --> 00:06:55.180 channels into a single chip, lead to a proliferation of different channels. 00:06:55.180 --> 00:07:01.270 In many ways, the system architecture was reminiscent of the original systems - ad-hoc 00:07:01.270 --> 00:07:07.040 purpose-built communication channels specialized to a specific task. 00:07:07.040 --> 00:07:12.530 As we'll see, engineering considerations have led to the widespread adoption of general-purpose 00:07:12.530 --> 00:07:15.670 unidirectional point-to-point communication channels. 00:07:15.670 --> 00:07:19.630 There are still several types of channels depending on the required performance, the 00:07:19.630 --> 00:07:23.570 distance travelled, etc., but asynchronous point-to-point channels have 00:07:23.570 --> 00:07:28.780 mostly replaced the synchronous multi-signal channels of earlier systems. 00:07:28.780 --> 00:07:34.640 Most system-level communications involve signaling over wires, so next we'll look into some the 00:07:34.640 --> 00:07:39.150 engineering issues we've had to deal with as communication speeds have increased from 00:07:39.150 --> 00:07:41.030 kHz to GHz.