//****************************************************************************//
//********************** Disk and I/O - July 12th, 2018 *********************//
//**************************************************************************//

- 9 people today...I'm continually amazed at how this class empties out
- Also, only 2 more weeks left in the semester (HOWHOWHOWHOW)!

- "So, right now, we've gone from a basic datapath, to optimizing it with the pipeline, to optimizing memory with paging and caches, to multithreading - taking advantage of multiple processors. Now, we're getting into the home stretch: talking a bit about I/O and Stable Storage (chapter 10), and then, next week, finishing by talking about file systems and basic networking"
- Just like with paging/caching, there are different policies for how we get things off of hard disks/long-term storage - we'll get into that in a moment
    - These chapters, though, are more about the big concepts than specific algorithms
---------------------------------------------------------------

- (These aren't my best notes; my attention was a bit split between lecture and my homework)

- "Device controllers" stand as an interface between the I/O device and the computer, and usually have their own data register/ status registers for each device
    - The DATA REGISTER holds the most recent data the device is trying to send us (e.g. the ASCII code of the keyboard)
    - The STATUS REGISTER 

- (something about memory-mapped I/O vs programmed I/O vs DMA)
- Now, in 2110, you were encouraged to use "direct memory access" for the GameBoy project

- Often, the big problem with I/O is getting information from the devices into main memory and vice-versa; very often, we handle this by creating additional buses just for the I/O (address lines, data lines, interrupt lines, interrupt acknowledge lines, etc.)
    - Occasionally, we'll even have a separate I/O processor just to handle all the calculations the devices need

- Usually, the computer doesn't know how to handle a random device when you first try to use it, so you need to install a DEVICE DRIVER that lets the device talk to the OS using a common standard (check this?)

- Then, in section 10.8, we get into one of the most important I/O devices: the hard drive!
    - In the old days, you could describe this as a record player where the head doesn't actually touch the disk
        - Nowadays, that analogy breaks down because a) no one remembers what a record player is b) SSDs don't actually work like this
        - "In many classes, they ask you to find stuff like the rotation delay, sync delay, etc. to access or write to the disk; in this class, we won't, since there's a TON of different approaches for laying out data even on a traditional rotating hard disk"
            - Keep in mind, though, that the rotation speed and the speed of the head moving back and forth is what fundamentally limits our access speed
    - When the hard drive is spinning, there's different data on different "tracks" of the disk (e.g. inner part of the disk holds a different piece of data than the outer parts); how do we get this information off the disk, and which tracks should get priority?
        - Well, similar to page faulting, we have different policies to determine this:
            - FIRST-COME FIRST-SERVED (FCFS) is okay for small loads, not the best for large amounts (since if we get a request from the inner disk track, then the outer disk track, then another inner, then another outer...we skip over a LOT of data by doing this)
            - SHORTEST SEEK TIME FIRST is where we go to the request which is closest to the head's current location
            - SCAN is where we go from one end of the disk to the other and pick up any requested data along the way
                - This is sometimes called the "elevator algorithm," since it goes all the way to the inner part of the disk, then all the way to the outer part, then back to the inner...it just goes from one end to the other, picking up data along the way 
            - C-SCAN is similar, but instead of reading data both ways, we start at the outer part of the disk, pick up data as we go to the inner, then go STRAIGHT back to the outer (without reading anything) and repeat
                - Basically, this is the Tower of Terror version of SCAN
            - LOOK is the same as SCAN but reverses direction if no more requests in the scan direction (e.g. elevator doesn't bother going to the roof if there's no requests); leads to better average performance than SCAN
            - C-LOOK is similar to a combination of C-SCAN/LOOK; we go to the inmost current request gradually, reading along the way, then snap back to the outermost request (NOT the absolute outermost part of the disk) and repeat
    - "So, ON AN EXAM, you should be comfortable showing the order of reads given a policy, disk layout, and queue of requests"

- So, for the simulator, you can change the memory policy, the CPU process switch policy, the disk policy, and number of pages/frames available...how would you find the optimal combination of policies? That's not a trivial problem!
    - We can run a bunch of benchmarks, but if there's a lot of possible combinations, that might take a good amount of time
    - If you want a few extra credit points, run 4 benchmarks (not bench_test or bench_alpha), give your presentation for the best combination of variables for EACH benchmark, and defend your choices in 2-3 sentences. Just put your parameters and the benchmark(s) in a private Piazza post
        - Has to be in by Monday night; look on T-Square for an announcement