(10 points) Consider a 33MHz, 32-bit PCI bus. PCI performs all transfers in "burst mode:" that is, once a device has become a bus master and and used one bus cycle to transfer an address, it it is able to make an arbitrary number of data transfers (there is actually a timer function preventing a device from going "rogue" and never releasing the bus) at the rate of one data transfer per bus cycle.
Plot bus throughput (in megabits/second) as a function of transfer size, for 32 bit, 64 bit, 96 bit, and 128 bit transfers.
Based solely on the bus width and speed, PCI would be able to transfer 32 bits/cycle × 33 million cycles/sec = 1056 Mbit/sec. However, each transfer requires an address cycle followed by an appropriate number of data cycles. The result looks like this:
| Transfer Size | Data Cycles | Efficiency | Effective Throughput |
|---|---|---|---|
| 32 | 1 | 1/2 | 528 |
| 64 | 2 | 2/3 | 704 |
| 96 | 3 | 3/4 | 792 |
| 128 | 4 | 4/5 | 844.8 |
Plotting this gives the following result:
As an aside, I was disappointed when I looked at a couple of the assignments to see the number of people who don't seem to understand what "plot Y as a function of X" means. However, I'd forgotten that it would be difficult for someone to turn in their assignment electronically and have a plot, so I told the TA to accept anything that had the right numbers for both electronic and paper submissions.
(20 points) The following 13 bit numbers consist of eight bits of data, four bits of error correcting code, and one parity bit in the order M8 M7 M6 M5 C8 M4 M3 M2 C4 M1 C2 C1 P.
Two of them are correct, two have one-bit errors, and one has a two-bit error. Tell which is which, and correct the two with one-bit errors.
Just so you can see it in action, I'm including the parity and check bits in the calculations so I get the syndrom directly (as Richard mentioned in class Wednesday)
1000111100100P = 1 ^ 0 ^ 0 ^ 0 ^ 1 ^ 1 ^ 1 ^ 1 ^ 0 ^ 0 ^ 1 ^ 0 ^ 0 = 0C1 = 0 ^ 0 ^ 1 ^ 1 ^ 0 ^ 0 = 0C2 = 0 ^ 0 ^ 1 ^ 1 ^ 0 ^ 1 = 1C4 = 1 ^ 1 ^ 1 ^ 1 ^ 0 = 0C8 = 1 ^ 0 ^ 0 ^ 0 ^ 1 = 0The parity is OK but the syndrom is nonzero, so there is a two-bit error
10110101100101011110110010P = 1 ^ 0 ^ 1 ^ 1 ^ 1 ^ 1 ^ 0 ^ 1 ^ 1 ^ 0 ^ 0 ^ 1 ^ 0 = 0C1 = 0 ^ 1 ^ 1 ^ 1 ^ 0 ^ 1 = 0C2 = 0 ^ 1 ^ 1 ^ 0 ^ 0 ^ 0 = 0C4 = 1 ^ 1 ^ 0 ^ 1 ^ 1 = 0C8 = 1 ^ 0 ^ 1 ^ 1 ^ 1 = 0The parity is OK and the syndrom is 0000, so this one is OK.
1010101111101P = 1 ^ 0 ^ 1 ^ 0 ^ 1 ^ 0 ^ 1 ^ 1 ^ 1 ^ 1 ^ 1 ^ 0 ^ 1 = 1C1 = 0 ^ 0 ^ 0 ^ 1 ^ 1 ^ 0 = 0C2 = 0 ^ 1 ^ 0 ^ 1 ^ 1 ^ 1 = 0C4 = 1 ^ 0 ^ 1 ^ 1 ^ 1 = 0C8 = 1 ^ 0 ^ 1 ^ 0 ^ 1 = 1The parity is bad and the syndrom is 1000 so bit 8 is wrong. The correct value would be
10100011111010110001101010P = 0 ^ 1 ^ 1 ^ 0 ^ 0 ^ 0 ^ 1 ^ 1 ^ 0 ^ 1 ^ 0 ^ 1 ^ 0 = 0C1 = 1 ^ 0 ^ 0 ^ 1 ^ 1 ^ 1 = 0C2 = 1 ^ 1 ^ 0 ^ 1 ^ 1 ^ 0 = 0C4 = 0 ^ 0 ^ 1 ^ 1 ^ 0 = 0C8 = 0 ^ 1 ^ 1 ^ 0 ^ 0 = 0The parity is OK and the syndrom is 0, so this one is OK.
P = 1 ^ 0 ^ 1 ^ 1 ^ 0 ^ 1 ^ 0 ^ 1 ^ 1 ^ 0 ^ 0 ^ 1 ^ 0 = 1
C1 = 0 ^ 1 ^ 1 ^ 1 ^ 0 ^ 1 = 0
C2 = 0 ^ 1 ^ 1 ^ 0 ^ 0 ^ 0 = 0
C4 = 1 ^ 1 ^ 0 ^ 1 ^ 1 = 0
C8 = 1 ^ 0 ^ 1 ^ 1 ^ 0 = 1
The parity is wrong and the syndrom is 1000, so bit 8 is
wrong. The correct number would be 1011110110010
(20 points) The following bit strings are 32-bit strings, which have had a four-bit cyclic redundancy check computed using the five-bit polynomial from the web page (11001). In both cases, the last four bits of the string are the CRC. One of them is correct, and one is not. Which is which?
01011011010000100010010000010100 1001
This matches the given frame check sequence, so the data is OK.01011011010000100010010000010100 11001 ----- 111111010000100010010000010100 11001 ----- 1101010000100010010000010100 11001 ----- 1110000100010010000010100 11001 ----- 10100100010010000010100 11001 ----- 1101100010010000010100 11001 ----- 1000010010000010100 11001 ----- 100110010000010100 11001 ----- 10100010000010100 11001 ----- 1101010000010100 11001 ----- 1110000010100 11001 ----- 10100010100 11001 ----- 1101010100 11001 ----- 1110100 11001 ----- 10000 11001 ----- 100101010001100000110110101001010110 0111
This time the calculated FCS doesn't match the one give, so there is an error.01010001100000110110101001010110 11001 ----- 110101100000110110101001010110 11001 ----- 111100000110110101001010110 11001 ----- 1110000110110101001010110 11001 ----- 10100110110101001010110 11001 ----- 1101110110101001010110 11001 ----- 1010110101001010110 11001 ----- 11001 11001 ----- 0101001010110 11001 ----- 11011010110 11001 ----- 10010110 11001 ----- 1011110 11001 ----- 111010 11001 ----- 1010
(20 points) The text talks about hard drive specifications on pages 646-650. For this problem, we're assuming a controller overhead of 0.
Here's a link to the specifications for the Western Digital WD1200BB disk drive: http://www.wdc.com/en/products/products.asp?DriveID=12
Based on these specifications:
Show that the stated average latency is consistent with the stated rotational speed.
Oops -- I didn't realize that this is in the book - right down to the correct numbers for this disk! If the disk is turning at 7200 RPM = 120 RPS, the time for one disk rotation is 1/120 = .0083 seconds, which is 8.3 msec. The average rotational latency should be half this, or roughly 4.2 msec. This is the figure given in the specs.
Suppose you wish to transfer 1,000,000 bytes of data from a disk drive to your computer's memory (disk drive manufacturers use "Mega" to mean 1,000,000, not 220). Considering only the characteristics of the disk drive itself (so you aren't concerned with the characteristics of the disk buffer, the data transfer mode, or your PC's bus or memory), under what assumptions will this transfer take place as quickly as possible? Since you aren't given the number of bytes per track, you can assume that all the data is on a single track. Also, the specs only give the transfer rate from the buffer to the disk: assume you can get the same rate transferring from the disk to the buffer (which certainly seems reasonable to me... but isn't in fact true for all drives). How long does the transfer take under these assumptions?
In the best possible assumptions, the head is already on the right track, over the right sector, so the only time required is the transfer time. At 602 Mbit/sec, transferring 1,000,000 bytes = 8,000,000 bits takes 8,000,000/602,000,000 = .013 seconds, or 13 msec.
-
Now, suppose you want to perform the same transfer, except you want to make the assumptions that will lead to the worst possible performance (well, let's be a little bit fair: assume that data is laid out in 512 byte sectors). What are the assumptions to get worst-possible performance? How long does the tranfer take under these assumptions?
Since the 1,000,000 bytes are on 512 byte sectors, we'll need to perform 1,954 transfers (the last sector isn't full). Taking the worst possible assumptions, we assume ever transfer needs a full-stroke seek (21 msec) and then wait for an entire disk rotation (8.3 msec). So every transfer will take 29.3 msec; 1954 transfers gives a total time of 57.32 seconds. You also need to transfer the actual data, which will add an insignificant 13 msec to this time, so the total is 57.45 seconds.
One last go at it: assume the data is laid out randomly on the disk (but in 512 byte sectors). Now how long does the transfer take?
We have a similar analysis as for worst case, but we only need an average-case seek (8.9 msec) and an average-case rotational latence (4.2 msec), so 1954 transfers will take 25.60 seconds; adding in the data transfer gives 25.73 seconds. Notice I used the 4.2 msec average rotational latency from the specs rather than (1/120)/2 in calculating this.
The moral of the story is that fragmentation kills performance!