＜操作系统导论＞第三十七章

前言

先赞后看，养成习惯
故意没有给图片加水印，方便来不及写作业的同学（狗头保命）

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

第一组： ./disk.py -a 0 -G

（这里运行disks.py会提示出错，缺少tk库，输入命令sudo apt-get install python-tk安装好库文件就可以正常使用了。如果还不行，就再安装一个sudo apt-get install python-pip就好啦。这个py程序按s开始模拟，p暂停，q退出）

Ps:转一圈的总时间为360个单位时间，一个扇区占30个单位时间。

由于起始位置和要找的位置0在同一个磁道上，所以寻道时间为0;
旋转到0所在的扇区（11和0中间）需要165个单位时间;
传输时间为30
总时间是195
验证：


结果和我们想的一样。

第二组： ./disk.py -a 6 -G

想要找到6首先要到6所在的扇区（在5和6中间），和起始在同一磁道，所以寻道时间为0,要转一大圈差15单位时间到达6所在的磁道，所以旋转时间是345;传输时间是30。
总时间是375.
验证：

第三组： ./disk -a 30 -G

这一次涉及到了磁道的切换。README文件中提到相邻道切换需要40单位时间，这里跨越两个磁道，故寻道时间为80.
传输时间还是30.
把30对应到起始磁道上对应6,旋转到6扇区第二组中计算过需要345,由于寻道和旋转是同时进行的，就能省出80个单位时间，那么旋转时间为375-80=265
总时间：265+80+30=375
验证：

第四组：./disk.py -a 7，30，8 -G（注意逗号是英文逗号）



到7 寻道时间：0 旋转时间：15 读取时间：30 总：45
再到30 寻道时间：80 旋转时间：220 读取时间：30 总：330
再到8 寻道时间：80 旋转时间：310 读取时间：30 总：420
总时间：45+330+420=795

前两个和之前的一样就不多解释，30到8的时候，此时磁头在30和31中间，对应到8所在的磁道就是6和7中间，只用旋转30个单位时间就能到8的扇区，但是寻道时间需要80,也就是说旋转到8所在磁道的时候已经错过了8的扇区，所以要多转一圈，就是30+360=390,旋转时间同样是在这个基础上减去寻道时间的80等于310
验证：


第五组：./disk.py -a 10,11,12,13 -G

转到10 寻道时间：0 旋转时间：105 传输时间：30 总：135
转到11 寻道时间：0 旋转时间：0 传输时间：30 总：30
转到12 寻道时间：40 旋转时间：320 传输时间：30 总：390
转到13 寻道时间：0 旋转时间：0 传输时间：30 总：30
总时间：135+30+390+30=585
这里的原理上面都提到过，就不过多解释了;
验证：

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

一．改变了寻道速率，对于没有寻道的数据（题目一的前两组）来说是没有影响的。
二．对于寻道时间导致多转了一圈的情况，如果寻道时间减小到小于它对应的目标磁道对应位置旋转过去的时间就能少转一圈
三．旋转时间的计算是对应到目标磁道位置旋转过去的时间减去寻道时间，如果寻道时间变小了，那旋转时间就会变大。
下面以题目一后三组数据举例。（用-c指令能直接展示结果，省去了圆盘转转转的时间，方便了很多）。

-S 2
./disk.py -S 2 -a xxx -c（XXX为那几个数字）

-S 4
./disk.py -S 4 -a XXX -c

-S 8
./disk.py -S 8 -a XXX -c

-S 10
./disk.py -S 10 -a XXX -c

-S 40
./disk.py -S 40 -a XXX -c

-S 0.1
./disk.py -S 0.1 -a XXX -c

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

旋转速率改变，寻道时间不受影响，旋转时间和传输时间都会改变，以题目一第四组举例：
./disk.py -R X -a 7,30,8 -c (X为题目中数据）
R=1

R=0.1

R=0.5

R=0.01

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

FIFO算法：
7->30->8
./disk.py -p FIFO -a 7,30,8 -c

SSTF算法
7->8->30
./disk.py -p SSTF -a 7,30,8 -c

根据结果来看，明显SSTF算法优于FIFO算法

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

SSTF 算法：
7->8->30
./disk.py -p SSTF -a 7,30,8 -c

SATF算法：
./disk.py -p SATF -a 7,30,8 -c
7->8->30

对于这组数据来说，这两种算法的结果时一样的，但不是所有的数据这两种算法都会得到一样的结果。下面举例分析：

假设有一组数据9,14,5。分别用SSTF和SATF算法算时间：
SSTF
./disk.py -p SSTF -a 9,14,5 -c

9->5->14

SATF
./disk.py -p SATF -a 9,14,5 -c

9->14->5

很明显SATF要优于SSTF因为虽然9->5的寻道时间短，但是要转一大圈，还不如先到下一个道上取个数据再转回来。

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

什么是偏移？偏移形象地说就是把那个磁道扭一下，偏移为x就扭地错开x个数据。

对于这组数据，耗时的地方就在于11到12那一步，因为切换磁道需要40单位时间，所以将偏移两设为2最合适。因为从一个数据走到下一个数据需要30个单位时间，寻道要40，可以先假想他们在同一个磁道，要保证在走到目标扇区之前完成磁道的转换.。11到12距离为0,寻道要40,偏移设为2就相当于他们距离是60,60大于40,可行。
验证：
没有偏移： ./disk.py -a 10,11,12,13 -c

偏移为1： ./disk.py -o 1 -a 10,11,12,13 -c

偏移为2： ./disk.py -o 2 -a 10,11,12,13 -c

这里可以看到偏移为2时耗时明显降低，与假设一致。

假设磁头寻道速率为x，磁道偏斜为y(x>0,y>0)，则对于该处理流，需满足：
x/40<y*30+15

记得留个赞👍再走呦 ：）