2.1k views

Consider a disk with the $100$ tracks numbered from $0$ to $99$ rotating at $3000$ rpm. The number of sectors per track is $100$ and the time to move the head between two successive tracks is $0.2$ millisecond.

1. Consider a set of disk requests to read data from tracks $32, 7, 45, 5$ and $10$. Assuming that the elevator algorithm is used to schedule disk requests, and the head is initially at track $25$ moving up (towards larger track numbers), what is the total seek time for servicing the requests?
2. Consider an initial set of $100$ arbitrary disk requests and assume that no new disk requests arrive while servicing these requests. If the head is initially at track $0$ and the elevator algorithm is used to schedule disk requests, what is the worse case time to complete all the requests?
edited | 2.1k views

We are using SCAN - Elevator algorithms.

We will need to go from $25\rightarrow 99 \rightarrow 5$. (As we will move up all the way to $99$,servicing all request, then come back to $5$.)

So, total seeks $= 74+94= 168$

Total time $= 168 \times 0.2 = 33.60000$

We need to consider rotational latency too $\rightarrow$

$3000$ rpm

I.e. $50$ rps

$1 \ r = 1000 /50 \ msec = 20 \ msec$

So, rotational latency $= 20/2 = 10 \ msec$ per access.

In worst case we need to go from tracks $0-99.$ I.e. $99$ seeks

Total time $= 99 \times 0.2 + 10 \times 100 = 1019.8 \ msec = 1.019 \ sec$

edited
0

or it could be like this 0,1,1,1,1.....1(now here seek time will be 1 since there is one track movmnt, but inter-track roatioanl time will be same as above),

@reena here only one track movement?

I am not getting, what u mean in this example??

could u elaborate it a bit?

0

what is the worse case time to complete all the requests?

Hi Guys,

I think instead of average rotational latency we should take time taken in full rotation. What is your opinion ?

0
If we are taking rotational latency because of "we do not know which sector is to be selected in those 100 random track request", then also in part - a) if request completion time asked instead of "seek time" then we have to consider the same avg. rotational latency in addition?
0
@bruv depends on question
0
One thing to notice here

request should go from 25 ->99 ->10

isnot it?

why upto 5 track request is taking?

Is there calculation mistake or am I missing somewhere?

Plz chk
0

@srestha ji,

Is there calculation mistake

No

am I missing somewhere?

Yes

0
@srestha

25 ->99 ->5 .Means staring from 25 goto 99 and service all request and come back to 5 ans service all request on the way.
0
In the worst case, can the requests come in the form - 0, 99, 0, 99 .... so on. In that case for every two requests 99 seek would be needed. Correct me If I am wrong here...
+1
Why 99 seeks ?

In worst case

Request can be from tracks

0, 99, 1, 98,...

Plz clarify.
+1
because it is elevator algortihm dude..it wont follow the order of requests...it goes in a flow...till end and come back
a)

5,7,10,32,45

end track: 99

current:25

total seeks=(99-25)+(99-5)=74+94=168

total seek time = 0.2 * 168 ms

b)

from 0 to 99

worst case time = 0.2 * 99 ms
0
You missed rotational latency
B.

Question is about how much time required to satisfied 100  requests...

1 request time is = Tseek +TrotLatency + data transfer time

Datatransfer time = 0(as not given any info)

99 seeks and 100 rotations required in worst case...

So 99 * seek time + 100*rotational latency...

1
2