计算机硬盘随机寻找时间,为什么平均磁盘寻道时间是完整寻道时间的三分之一？(Why is average disk seek time one-third of the full seek time?)...

为什么平均磁盘寻道时间是完整寻道时间的三分之一？(Why is average disk seek time one-third of the full seek time?)

考虑到磁盘性能，我已经阅读过很多书和论文，平均搜索时间大约是完整搜索时间的三分之一，但没有人真正提供任何解释。 这是从哪里来的？

I have read in many books and papers, considering disk performance, that the average seek time is roughly one-third of the full seek time, but no one really offers any explanation about that. Where does this come from?

原文：https://stackoverflow.com/questions/9828736

更新时间：2020-01-09 20:34

最满意答案

平均值使用微积分进行数学计算。 我们使用非常基本的公式来计算平均值。

平均寻道时间=(所有可能寻道时间的总和)/(可能寻道时间的总数)

假定磁盘具有N个磁道，所以这些磁道的编号从1 ... N。在任何时间点磁头的位置可以是从0到N(包含)的任何值。 让我们说，磁头的初始位置在轨道'x'处，并且磁头的最终位置在轨道'y'处，以便x可以从0变化到N，并且y可以从0变化到N.

根据我们对平均寻道时间的定义，我们可以这样说，

平均寻道距离=(所有可能寻道距离之和)/(可能寻道距离的总数)

按照x和y的定义，Total no。 (x = 0，N)SIGMA(y = 0，N)| xy | = INTEGRAL(x = 0，N)INTEGRAL(y = 0，N)| xy | dy dx

为了解决这个问题，使用将表达式的模数分解为y = 0到x和y = x到N的技巧。然后求解x = 0到N.

这出来是(N ^ 3)/ 3。

平均搜索距离=(N ^ 3)/ 3 * N * N = N / 3

平均寻道时间=平均寻道距离/寻道率

如果从位置0到轨道N的寻道时间需要't'秒，则寻找速率= N / t

因此，avg寻道时间=(N / 3)/(N / t)= t / 3

参考：

The average is calculated mathematically using calculus. We use the very basic formula for calculation of average.

Average seek time = (Sum of all possible seek times)/(Total no. of possible seek times)

The disk is assumed to have N number of tracks, so that these are numbered from 1...N The position of the head at any point of time can be anything from 0 to N (inclusive). Let us say that the initial position of the disk head is at track 'x' and the final position of the disk head is at track 'y' , so that x can vary from 0 to N and also, y can vary from 0 to N.

On similar lines as we defined average seek time, we can say that,

Average seek distance = (Sum of all possible seek distances)/(total no. of possible seek distances)

By definition of x and y, Total no. of possible seek distances = N*N and Sum of all possible seek distances = SIGMA(x=0,N) SIGMA(y=0,N) |x-y| = INTEGRAL(x=0,N)INTEGRAL(y=0,N) |x-y| dy dx

To solve this, use the technique of splitting modulus of the expression for y = 0 to x and for y = x to N. Then solve for x = 0 to N.

This comes out to be (N^3)/3.

Avg seek distance = (N^3)/3*N*N = N/3

Average seek time = Avg seek distance / seek rate

If the seek time for the from position 0 to track N takes 't' seconds then seek rate = N/t

Therefore, avg seek time = (N/3)/(N/t) = t/3

Reference:

相关问答

当您向BufferedOutputStream写入100,000个字节时，您的程序将显式访问文件的每个字节并写入零。 在本地文件上使用RandomAccessFile.seek()时，您间接使用C系统调用fseek() 。 如何处理取决于操作系统。 在大多数现代操作系统中，支持稀疏文件 。 这意味着如果您要求空的100,000字节文件，则实际上不会使用100,000字节的磁盘空间。 当您写入字节100,001时，操作系统仍然不使用100,001字节的磁盘。 它为包含“真实”数据的块分配少量空间，并

...

所有寻求系统调用都会改变下一次读取文件的位置。 它不会移动驱动器头。 读取或写入数据时驱动器磁头会移动，而您无法直接控制下一步操作系统的操作。 读取大量不需要的数据会产生影响，因为所有读取的数据都需要OS缓冲区中的空间，并导致旧数据丢失。 因此，使用查找大文件将会导致文件系统缓存更少。 我所写的所有内容都假设你无法在内存中放入整个数据库。 如果可以的话，就这样做。 阅读所有内容并尝试在文件末尾添加新的和已更改的数据。 不要担心浪费的空间，只是偶尔做一些压缩。 如果你的数据库太大： 数据以块(或页面

...

经过很多反复试验，我想我终于明白了这一点。 首先你需要计算你的文件的采样率。 为此，获取AudioNode的最后渲染时间： var nodetime: AVAudioTime = self.playerNode.lastRenderTime

var playerTime: AVAudioTime = self.playerNode.playerTimeForNodeTime(nodetime)

var sampleRate = playerTime.sampleRate

然后，以秒为单位将采样

...

磁头可能会到位，但磁盘可能不在该位置的正确位置。 所以想象首先必须移动头部，然后等待主轴旋转。 当头部到达时，它可能就在那里，但是可能需要等待至少半圈才能达到正确的扇区。 所以总结它们两者都允许。 编辑： 所以想象它就像一个Merry Go Round。 你可以在2秒内跑到最快乐的地方(你是头脑)。 但是你可能需要等待5到10秒才能让你的特定马匹在你抵达后到达你身边(马是你想要进入的部门)。 The head may get into place, but the disk might not b

...

平均值使用微积分进行数学计算。 我们使用非常基本的公式来计算平均值。 平均寻道时间=(所有可能寻道时间的总和)/(可能寻道时间的总数) 假定磁盘具有N个磁道，所以这些磁道的编号从1 ... N。在任何时间点磁头的位置可以是从0到N(包含)的任何值。 让我们说，磁头的初始位置在轨道'x'处，并且磁头的最终位置在轨道'y'处，以便x可以从0变化到N，并且y可以从0变化到N. 根据我们对平均寻道时间的定义，我们可以这样说， 平均寻道距离=(所有可能寻道距离之和)/(可能寻道距离的总数) 按照x和y的定义

...

这在seekToTime:的文档中seekToTime: ： 寻求的时间可能与指定的效率时间不同。 对于样本的准确求求，请参阅seekToTime:toleranceBefore:toleranceAfter: . 因此，尝试使用seekToTime:toleranceBefore:toleranceAfter:相反，指定低容差或零容差。 在创建可能正在使用的任何AVURLAssets时，您可能还希望为AVURLAssetPreferPreciseDurationAndTimingKey指定tru

...

确保你有良好的联系 视频应该压缩为流媒体(产生巨大的差异) 使用bufferTime参数来获得理想的设置 用代码创建一个玩家，不要使用UI组件。 你会有更多的灵活性： http ： //blog.martinlegris.com/2008/06/03/tutorial-playing-flv-video-in-plain-as3-part-1/ 警告，更长的缓冲区将允许更平滑的播放，更短的将寻求更快，但权衡是它将更频繁地击中缓冲区...不理想 make sure you have a good c

...

但是视频的AVCodecContext-> time_base == 1001/60000 这让我很困惑，我不明白。 time_base是AVRational类型的，它是一个由分子和分母组成的有理数，而不是使用小数点。 我假设他们不只是使用double的原因是这样你不会失去任何精度。 AVRational在来源中定义为： typedef struct AVRational{

int num; ///< numerator

int den; ///< denominator

} AV

...

问题是，流程图只能寻求关键帧，以便能够寻找任何秒，你需要每秒钟都有关键帧。 很可能这意味着您需要在使用配置为每秒强制关键帧的ffmpeg上传视频时重新编码视频。 The issue is that flowplayer can seek to keyframes only so in order to be able to seek to any second you need to have keyframe for every second. Most probably that means

...

经过几次实验后，我找到了自己问题的答案。 经过非常频繁的文件concat操作(大约每分钟1k)后，数据节点在一天左右开始抱怨太多块，这导致我相信这确实会导致磁盘碎片化和块数增加。 我使用的解决方案是编写一个单独的作业，将这些文件连接(并压缩在我的情况下)为单个可拆分的归档文件(注意gzip不可拆分！)。 After a few experiments I found the answer to my own question. After very frequent file concat ope

...