XML CO527 Anonymous Questions and Answers

This page lists the various questions and answers. To submit a question, use the anonymous questions page. You may find the keyword index and/or top-level index useful for locating past questions and answers.

We have taken the liberty of making some minor typographical corrections to some of the questions as originally put. Although most of the questions here will have been submitted anonymously, this page also serves to answer some questions of general interest to those on the course.

Question 81:

Submission reference: IN2949

What do errors such as "highlevel_didread(): read queue 0 got unexpected block 1025" mean?

Answer 81:

See Question 30 (2013), and please check existing questions before posting new ones :-).

Question 82:

Submission reference: IN2950

Is my interpretation of C-Scan correct?

1. Start at top head
2. Process all requests in that head, in all the tracks and sectors.
3. Move down to next head.
4. When head 0 is reached, goto 1.

Thanks.

Answer 82:

No, I'm afraid! If you swap head and track in your description what you have is SCAN in effect. Head numbers are mostly irrelevant: the disk has multiple read/write heads (as per diagram) so can service multiple requests from the same track/sector at different heads simultaneously.

Keywords: assess5-1314

Question 83:

Submission reference: IN2951

If the SCAN algorithm starts from the outside and works inwards, and the read/write head starts at track 0 in the middle, doesn't initially moving the head to the start position for SCAN slow the whole process down?

Answer 83:

Not sure why you think track 0 is in the middle..! Are there negative track numbers on one side and positive on the other? Track 0 is either the outermost or innermost on the disk (doesn't matter which).

Keywords: assess5-1314

Question 84:

Submission reference: IN2952

My SSTF implementation scores 704 for requests.txt, but 8291 for requests-big.txt. There are no logical errors, and it seems to process all the requests. Is there anything that could be causing such a bad score for requests-big.txt when the score for requests.txt is reasonable?

Answer 84:

Although it's not broken, something clearly isn't right. You should be getting a score of around 3000-3200 for SSTF, give or take. Look at the raw stats though, i.e. average and the deviation, as this might help a bit. Also run with visualisation on and check that the read/write heads are doing what you might expect (i.e. shortest seek between reads). As to likely causes, there could be many, some of which are eluded to in other anonymous question answers.

Keywords: assess5-1314

Referrers: Question 94 (2013)

Question 85:

Submission reference: IN2953

In the LIFO implementation why does it start reading the 3rd line of requests before all of the 2nd line of requests are finished? For example: read request for block 2457603, then the next read request is for read request for block 1048500. But there are still blocks in the second queue to read such as 2434000?

Answer 85:

The requests are not read linearly: each line of block numbers is a set of requests that starts at a specific time. So blocks from the 3rd line will start being requested a little while after blocks from the 2nd and 1st lines are requested (start times being 30, 40, 50, etc.). Each request queue will try and keep a fixed number of block requests pending (4 at the moment). Thus the disk scheduler code will see the first 4 blocks of each request before seeing more blocks from the same request queue. How this works isn't important though: your disk scheduler just gets requests for particular blocks and has to deal with these.

Keywords: assess5-1314

Question 86:

Submission reference: IN2954

How do you find out where the current head position is?

Answer 86:

You can't: you have to keep track of this yourself. In many cases, it will be the track associated with the block seen by readcomplete, but not always (e.g. if the disk had been idle).

Keywords: assess5-1314

Question 87:

Submission reference: IN2955

In SCAN/C-SCAN do you sort the requests in what track they're in, or by the number of the request?

Answer 87:

What do you mean by "number of the request"? But see Question 80 (2013) — the track is what you should be primarily interested in, as moving between tracks is what takes (comparatively) a lot of time.

Keywords: assess5-1314

Question 88:

Submission reference: IN2956

For a C-SCAN implementation should we be concentrating on reading blocks that are on the same track as the block being currently serviced?

Answer 88:

That should probably apply to most things, including SSTF, SCAN and C-SCAN; i.e. (for SSTF) if there are requests on the same (current/last) track, these must be closer than all others (zero track seek time), so should get serviced in preference.

Keywords: assess5-1314

Question 89:

Submission reference: IN2957

This is very basic, but how do you read a block to tell what value it is? I'm totally lost.

Answer 89:

Your question doesn't make sense I'm afraid. A block's "value" is irrelevant (and for the most part unknown). But to read a block you call "DiskSim.disk_readblock(...)" — at some point later on, your "readcomplete()" method will be called to indicate that this block has been read, which it can then give back to the high-level code by calling "DiskSim.highlevel_didread(...)".

Keywords: assess5-1314

Referrers: Question 90 (2013)

Question 90:

Submission reference: IN2958

This is a very basic question regarding assessment 5, but I'm stumped. How do you read a block to find out what value it holds?

Answer 90:

See Question 89 (2013).

Question 91:

Submission reference: IN2959

I'm trying to run this in Eclipse by choice, but nothing happens when I go to DiskSim.java -> "run as" -> "Java application". Is there a reason why this wouldn't work?

Answer 91:

Not that I'm aware of — but as I've said elsewhere, Eclipse is too heavyweight and not the right tool for the job. Using Eclipse to edit is fine, but I'd stick with compiling and running from the command-line (if you're forced to use Windows). Sensible suggestion: compile and run on raptor, edit on Windows (you'll need raptor's filestore mounted, of course, which off-campus means abusing SSH tunnels or using the VPN).

Keywords: assess5-1314

Question 92:

Submission reference: IN2961

my SSTF implementation gives around 3200 for requests-big.txt but around 2800 for requests.txt. Is this fine?

Answer 92:

The value for requests-big.txt looks sensible, the for requests.txt seems quite high (I'd have expected something around 720).

Keywords: assess5-1314

Question 93:

Submission reference: IN2962

Under what conditions does DiskSim stop and output the stats? I have requests still in my list at the end of the simulation with everything ready for the next readcomplete() call but the program stops and I have pending queues.

Answer 93:

See Question 72 (2013).

Question 94:

Submission reference: IN2963

I'm having the same problem as Question 84 (2013). I have no idea why this is happening and nothing seems to make any difference — my code looks likes it should work. Is there any reason that it may work well for small inputs but not large ones? Is there any guidance you can give to help me fix this problem?

Answer 94:

Usually because something is broken, either subtly or seriously. The way to diagnose this is to create a request file, perhaps with two queues starting at the same time, where the track numbers in each are strictly increasing. The formula to construct block numbers is given in the slides. But simply:

0 8 0 64 128 192 256 320 384 448 512
0 8 1 65 129 193 257 321 385 449 513

If you run with verbose on, you should see the requests processed in the block order: 0, 1, 64, 65, 128, 129, etc. I.e. shortest seek time first. With FIFO, this would be more like: 0, 64, 128, 256, 1, 65, 129, ... (haven't actually tried this, so may be different). As mentioned elsewhere, shortest seek time first is not nearest block number first.

Keywords: assess5-1314

Question 95:

Submission reference: IN2964

Hi, I was wondering if you could explain the conversion from FIFO to SSTF in a little more detail. I am struggling to understand slide 28 of your helpful slides that you have included. More specifically, is there anyway you could explain the 3 points in a little more depth please? Thanks.

Answer 95:

I'm afraid that if I go into any more detail here, I'm effectively doing it for you! Thus, you won't really learn anything useful from the assessment. Obviously you need to understand what the code there is doing, but given that you've been programming for 2 or more [academic] years, this ought not to be a problem..

Keywords: assess5-1314

Question 96:

Submission reference: IN2965

For assessment 5, what exactly does the visualisation mean? It moves too quickly and there's too much info for me to process any of it.

Answer 96:

It shows the read/write head's position on the disk in tracks (i.e. track 0 at one end horizontally). The head will flash 'R' when it reads, which won't necessarily stay on the screen long. You can slow it down if needed by hacking the appropriate bit of code in DiskSim.java (around line 1020) by just changing the wait for delay to delay * 100 or something. But the point of the visulisation is that you can see if your algorithm is doing the right thing, e.g. for SSTF, it should move slowly across the disk doing lots of reads as it goes. For C-SCAN, the head should sweep forwards and backwards processing requests as it goes. SCAN is similar.

Keywords: assess5-1314

Question 97:

Submission reference: IN2966

Is "time for request in queue" just how long it took to start reading a block from when it was requested? Because in my SSTF implementation the average is 22848. Does this mean starvation is occurring?

Answer 97:

Yes, and possibly. But the standard deviation will tell you more about starvation than the average.

Keywords: assess5-1314

Question 98:

Submission reference: IN2967

I'm getting this weird issue, what could be causing it? This is what I'm getting;

    highlevel_didread(): read queue 4 got unexpected block 2457200
    [snip]

Answer 98:

See Question 30 (2013).

Question 99:

Submission reference: IN2968

Regarding the requests file you will be using to test each implementation, will it contain enough requests to simulate -dynamic to a high amount of accuracy while still being consistent over each implementation so that it is fair?

Answer 99:

I won't be testing implementations on just one request file. The dynamic mode is pathological: disk overload basically, so it may be representative of one of the tests. Ideally your implementation should perform well under whatever conditions (such would be expected in any normal OS) but it's reasonable to settle for something which is "pretty good" in all cases (i.e. SSTF does pretty well except for high-load, where it ends up starving requests, and can starve in other cases too).

Keywords: assess5-1314

Referrers: Question 108 (2013)

Question 100:

Submission reference: IN2969

Are we allowed to use the block-to-track methods in DiskSim?

Answer 100:

Yes! Else I would not have explicitly said about it in the assessment description :-).

Keywords: assess5-1314