《操作系统导论》第37章作业

在开始做作业的时候发现，会被提示缺少必要的库，我们需要在Linux下安装python名为tk的库。
需要两条命令：
sudo apt-get install python-pip
sudo apt-get install python-tk

37.1

计算以下几组请求的寻道、旋转和传输时间：-a 0,-a 6,-a 30,-a 7,30,8,最后-a 10,11,12,13。

解：

第一组：运行指令：./disk.py -a 0 -G
运行的结果如下：

按下s键，就可以看到磁盘旋转起来，同时其寻找的是0扇区，发现在同一个磁道，所以寻道时间为0：

根据readme文件，我们可以知道单个扇区传输所需时间：30个时间单位，相邻磁道之间有40个单位距离，默认寻道时间为1/单位时间。同时，每个扇区的传输是从中间开始的，也就是读取0扇区，需要从11和0中间开始。
所以，我们可以知道旋转时间为5.5x30=165.一个扇区所需的传输时间为30个时间单位，所以总共需要的时间为165+30=195个时间单位。

发现结果与我们预测的结果相同。

第二组：运行指令：./disk.py -a 6 -G
运行的结果如下：

按下s键可以得到如下的结果：

同理，这里我们可以知道一个扇区的时间为30个时间单位，现在寻道时间为0，旋转的扇区为11.5个，即11.5x30=345个时间单位。加上传输时间即可得到的结果为375个单位。

发现与预测的结果相同，可以知道预测是正确的。

第三组：运行指令：./disk.py -a 30 -G
可以得到如下的结果：

按下s键可以输出如下的结果：

我们可以知道寻道每个相邻磁道需要40个时间单位。
首先，这里寻道时间为80个时间单位。
如果不考虑寻道时，磁盘的旋转时间，则需要经过11.5个扇区的旋转时间，所以也就需要345个时间单位。但是现在寻道的时候也在旋转，所以旋转时间为345-80=265个时间单位。
传输时间固定为30个时间单位。
所以总共需要30+265+80=375个时间单位，计算机运行的结果：

第四组：运行指令：./disk.py -a 7，30，8 -G
可以看到如下的结果：

按下s键可以看到磁盘的最终结果为：

访问顺序为7->30->8。
首先，先需要传输扇区7的内容，在同一条磁道所以寻道时间为0，旋转时间只需要旋转半个扇区，则需要的旋转时间为15个时间单位，传输时间为30个时间单位。
接下来7->30扇区，首先，我们先寻道，两个磁道需要80个时间单位的，同时这里也是同样的考虑，如果不考虑寻道时候的旋转，那么我们需要旋转10个扇区，所以旋转的时间为300个时间单位，现在考虑寻道的时候的旋转所以我们需要旋转220个时间单位。传输时间为30个时间单位。
30->8扇区：寻道80，旋转的话，本来只要30(30的尾和8的头只差了一个扇区的度数)，但要再加一圈，所以是30+360-80=310，传输30。
所以最后需要时间为795个时间单位。

与分析的结果相同。

第五组：运行指令：./disk.py -a 10,11,12,13 -G
运行的结果如下：

从6到10、11：寻道0，旋转303+15=105，传输302=60。
从11到12、13： 注意：11到12不在一个磁道，寻道之后就得绕一圈。所以寻道40，旋转0+360-40=320，传输30*2=60。
所以需要的时间为585个时间单位。
按下s键可以得到如下的结果：

可以知道我们的分析是正确的。

37.2

执行上述相同请求,但将寻道速率更改为不同值:-S 2,-S 4,-S 8, -S 10,-S 40, -S 0.1 时间如何变化?

解：

改变寻道速率，对没有寻道的组来说没有时间变化的影响，如果出现了寻道则时间可能会发生变化。同时，寻道时间的改变，并不一定是让时间减少，可能会发生让磁盘多转一圈，可能所用时间会增长。
所以，时间的变化如下：

37.3

同样的请求,但改变旋转速率:-R 0.1,-R 0.5,-R 0.01。时间如何变化?

解：

寻道时间不影响。旋转时间有的线性增加，而有的会因为寻道相对快了而少绕圈。传输时间线性增加。同时，旋转时间的增加可能会导致寻道的时间相对减少，也就是可能会发生，如果旋转速度过快会出现，需要多旋转一圈，导致时间反而会更长。
所以，时间的变化如下：

37.4

你可能已经注意到,对于一些请求流,一些策略比 FIFO 更好。例如,对于请求流 -a 7,30,8 处理请求的顺序是什么?现在在相同的工作负载上运行最短寻道时间优先 (SSTF)调度程序(-p SSTF)。每个请求服务需要多长时间(寻道、旋转、传输)?

解：

首先，我们知道FIFO策略请求的顺序是按照先进先出的顺序来定的，也就是请求流 -a 7,30,8处理请求的顺序是7->30->8。对于运行最短寻道时间优先(SSTF)和电梯策略(SCAN)处理请求的顺序都应该是7->8->30。

FIFO策略，我们在第一题中已经知道时间为795个时间单位。
对于最短寻道时间优先(SSTF)策略来说：
6->7扇区：寻道时间为0，旋转时间为15个时间单位，传输时间为30个时间单位。
7->8扇区：寻道时间为0，旋转时间为0，传输时间为30个时间单位。
8->30扇区：寻道时间为80，不考虑寻道时的旋转，旋转时间为270，考虑寻道时的旋转则旋转时间为190个时间单位，传输时间为30个时间单位。
所以，所需要使用的时间为375个时间单位。
按下s键进行验证：
经过验证，可以知道总的时间确实为375个时间单位。

37.5

现在做同样的事情,但使用最短的访问时间优先(SATF)调度程序(-SATF)。 它是否对 -a 7,30,8 请求有影响？ 找到 SATF 明显优于 SSTF 的一组请求。出现显著差异的条件是什么?

解：

做同样的事情，使用最短的访问时间优先(SATF)的策略时，我们发现访问的顺序仍然为7->8->30，所以使用最短的访问时间优先(SATF)调度程序对-a 7,30,8的请求没有影响。
使用程序运行的结果为：

发现时间是相同的，所以我们的分析是正确的。
首先，我们找到一个SATF明显优于SSTF的一组请求的例子，来观察造成显著差异的条件是什么。

如：-a 6,13,5我们分别使用两种策略分别运行一下，可以得到如下的结果：
使用SATF策略的运行的结果如下：

使用SSTF策略的运行的结果如下：

发现，运行时间有明显的优化。
经过，这个例子我们可以知道，当在同一磁道旋转时间过长，大于磁头转移到别的磁道再转移回来的时间时，SATF磁盘调度策略将优于SSTF磁盘调度策略。

37.6

你可能已经注意到,该磁盘没有特别好地处理请求流 -a 10,11,12,13。这是为什么? 你可以引入一个磁道偏斜来解决这个问题(-o skew,其中 skew 是一个非负整数)?考虑到默认寻道速率,偏斜应该是多少,才能尽量减少这一组请求的总时间?对于不同的寻道速率(例如,-S 2,-S 4)呢?一般来说,考虑到寻道速率和扇区布局信息,你能否写出 一个公式来计算偏斜?

解：

该磁盘因为在传输完10和11扇区之后，这时候不能立即读取12扇区的内容。不能使用什么策略，我们的访问顺序都只能是10->11->13->12，都只能多旋转一圈来访问12扇区，这是磁盘扇区位置设计的弊端。

所以，我们需要进行磁道倾斜。
当倾斜量为0时：
也就是上述情况。
当倾斜量为1时：
运行指令：python2 disk.py -a 10,11,12,13 -o 1 -G
可以得到如下的结果：

发现，访问顺序是对的。但是访问时间却更长了，主要原因是由于这次不仅错过了12扇区，也错过了13扇区。
当倾斜量为2时：

传输完11之后，寻道到了中间磁道，刚好就到12扇区的开始位置。

当倾斜量再大的时候，只能增加到12扇区的旋转时间。

如果寻道时间加快，如 -S 2或者 -S 4 ，那么偏斜量为1反而是最优的，因为这时候寻道时间40/S小于30，所以刚好能碰到12开始的位置。

也就是，跨越相邻磁道的寻道时间约接近（小于）旋转过一个扇区的旋转时间，效果越好。因此，如果寻道速度为V，寻道距离为D，旋转角速度为W，每扇区区域跨越的角度为A，偏斜为O，那么:D / V < A*O / W ，所以偏斜量O > DW / VA，并取满足该条件下的最小的整数。