|
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.
Submission reference: IN5028
What grade could I expect with these results on your automated-tester?
Test 1: okay: ... (worse than SSTF, by more than 2 percent, same or better than FIFO)
Test 2: okay: ... (better than SSTF, by more than 2 percent)
Test 3: okay: ... (worse than SSTF, by more than 2 percent, same or better than FIFO)
Test 4: okay: ... (a bit better than SSTF, within 2 percent)
Test 5: okay: ... (a bit better than SSTF, within 2 percent)
Test 1: 50 +/- 10; 2: 70 +/- 10; 3: 50 +/- 10; 4: 70 +/- 10; 5: 70 +/- 10.
This is very approximate, and not guaranteed (despite the error). Overall that works out to 62% +/- 10%. (so anything between 52% and 72%, possibly more) — the upper-bound is unknown until everyone has submitted their solutions, so for something like test 2 you might actually get 90%. But tests 1 and 3 don't look so great (not going to get more than 60% for these probably).
Submission reference: IN5023
Assuming the following:
Queue = 95, 180, 34, 119, 11, 123, 62, 64
Start = 50
For the C-Look implementation; there is a type of "jump" that doesn't count the head movement.
So, it first goes to 34, 11, then it just "jumps" to 180, then goes down again. I am unsure how to implement this "jump" as it doesn't seem to count towards the time. I thought of maybe since the disk is round, it just overlaps, but I'm not sure how to implement that one.
You don't say whether the numbers you're referring to are tracks or blocks. That makes a difference. Moving between tracks takes time (depending on the number of tracks). Thus, when looking at scheduling algorithms, track numbers are what you would want to consider first. From that perspective, the "Queue" you have, and some of the text, makes sense — in that some requests are processed from track 34, then track 11, then (since nothing smaller exists in the queue) back to the top at track 180. Code that behaves like this will take the appropriate amount of time in the simulator (unless I made a horrid bug somewhere, but I think it's good!). If the numbers are block numbers, then the logic of the ordering is wrong: the way that blocks on the disk map onto tracks, sectors and heads is essentially unknown (obviously not in this case, since you can look at the code for yourself). The scheduling algorithm itself shouldn't actually care about block numbers, beyond using the various DiskSim functions to get the track, sector or head of where the block physically resides. But when thinking about blocks, rather than tracks, then there is overlap: in that underneath the physical read-write heads of the disk (see diagram in the slides) there will be multiple blocks, all with different block numbers.
Keywords: assess4-1516
Referrers: Question 53 (2015)
Submission reference: IN5034
Having worked SSTF into the FIFO code successfully, I wanted to take a try at implementing it for LIFO. Problem is, I don't see an easy way to make DiskSim use the LIFO class instead. DiskSim seems to call on the same method names inside LIFO as in DSched so I tried renaming LIFO to DSched but to no avail.
Is there an easier way to do this? Thanks.
Not really.. Renaming files is about the best you can do in this case: in theory you could have some abstract class for DSched then specialise it through inheritance/overriding, but that's over-engineering and would make the submission / automated-testing more complex than it needs to be. The "DSched-lifo.java" file included would need to be renamed to "DSched.java" to have it compile sensibly (as the class name is the same, i.e. "DSched").
Keywords: assess4-1516
Submission reference: IN5032
I was just wondering if we can change the blockread method, to change how the queue is read.
That's fine (changing the blockread method), but this is called for new requests entering the queue, rather than reading requests out of it (which typically happens in readcomplete as a result of finishing the previous read).
Keywords: assess4-1516
Submission reference: IN5029
I feel like I've got the the point where I'm making very little progress / no progress where more often than not I am just going in circles. For the purpose of the submission should I remove all redundant code for tidiness e.g. my C-Scan attempt(s) or should I leave it in there in case for you to look at?
Feel free to leave it in there, but make it an obviously commented-out block with some explanation of why it's there. If I do look at the code, some marks might be available depending on how close to a working implementation the commented-out code is.
Keywords: assess4-1516
Submission reference: IN5025
For the fourth assessment, what kind of grade could I expect to receive with the following results:
'requests.txt' -> score: 684, 0 pending queues 'big-requests.txt' -> score 771, 31 pending queues
For some reason the bigger text file wont read all queues, even though the same code is running and working for the smaller text file. I cant seem to figure this out.
The fact there are pending queues in the larger test means that something is quite broken :-(. Look hard at your code for the case when the request queue is full (i.e. has MAXREQUESTS things in it). Many problems of this kind stem from trying to use the circular-queue (FIFO) code, and the issue of iterating from the tail to the head (or vice-versa); better to start with the simpler LIFO code. In the FIFO code, 'head' == 'tail' in two scenarios: the queue is empty and the queue is full. If you need to be able to tell the difference, you need another variable (e.g. counting how many things are in the queue, which is what the LIFO code does with its readstack_size variable).
To get an idea of how it fares under assessment, feed it to the automated checker thing (link on Moodle).
Keywords: assess4-1516
Submission reference: IN5024
Can we remove the comments from DSched, or would you rather they stay there?
You should leave comments as you deem appropriate. Feel free to remove the folds however (comments involving the triple-braces). Generally any method should have some leading comment (or JavaDoc if you prefer) to say, generally, what it does, what its parameters are and what it returns. Anything subtle or structural should probably also have some comment in the code. Good commenting is good practice generally, but that doesn't mean you have to be excessive nor comment the obvious.
Keywords: assess4-1516
Submission reference: IN5027
My attempt at C-SCAN is horribly slow compared to my SSTF racking up a score of 2950 for a regular request and 13300 for the bigger request. I've gone over my implementation and to me it seems logical.
[snip code]
For the benefit of other readers (and the poster) this looks like a piece of code that tries to build on the FIFO implementation, that has within it the circular queue (using the "head" and "tail" indices). The way you're iterating over this is probably broken, in the sense that the "while()" loop searching through the requests will not operate in the right way. See the answer to Question 28 (2011) for some more information. Solution is to skip the whole head/tail FIFO version, and start from the LIFO version (which is much simpler, but performs horribly) — or retrofit those changes onto your code.
Keywords: assess4-1516
Submission reference: IN5026
I am getting these results back from the auto-tester you put together:
Test 1: okay: ... (worse than SSTF, by more than 2 percent, same or better than FIFO) Test 2: okay: ... (better than SSTF, by more than 2 percent) Test 3: okay: ... (worse than SSTF, by more than 2 percent, same or better than FIFO) Test 4: failed with leftovers Test 5: failed with leftovers
What kind of a grade could I expect back if this particular DSched solution was submitted? Thanks!
For tests 1 and 3, say 50% (+/- 10%), for test 2 say 70% (+/- 10%), but 0 for tests 4 and 5. This would give a final mark of 34% (+/- 6%), very approximately. In this category, it's probably one I'd look at the code to see if it was a reasonable attempt (and give it up to 50% potentially). The fact two of five tests fail means the maximum possible would be 60%.
Keywords: assess4-1516
Submission reference: IN5022
Do tests 4 and 5 in the automated checker use a large data input file like requests-big.txt? My code is failing these tests ("failed at run-time"), and I thought it might be that, but I fixed that bug (when I run the code on my machine with requests-big.txt it works fine, if a bit in-efficient). I was wondering if I'd only fixed the code for a file size that is still quite small compared to the ones in tests 4 and 5?
I'm not going to reveal too many details about the individual tests, but they are larger than the first three. As strongly suggested in the assessment description, invent your own datasets and try those! (don't rely just on the example I provided you with).
Keywords: assess4-1516
Submission reference: IN5021
Let's say there's track 100 on head 1, and track 200 on head 2.
If you submitted track 100 to be read, then you would submit track 200 (located in head 2) would this add to the time a lot more than if track 200 was on the same head as track 100?
There seems to be some terminology confusion here! Heads are the electronic read/write gubbins on the end of the actuator arm that moves laterally across the disk. Thus, for any given track [0 .. N-1] there are heads [0 .. H-1] (assuming H is the number of heads and N is the number of tracks). Thus you have physical locations such as track 1 head 1, track 1 head 2, track 2 head 1, track 2 head 2, etc. (putting sectors aside, which are the locations around the disk). Different tracks are not on different heads. Look at the slides I made for a rough idea of how tracks (aka cylinders), heads and sectors are related.
Keywords: disk-scheduling , assess4-1516
Submission reference: IN5017
Exception in thread "main" java.lang.NoClassDefFoundError: DiskSim (wrong name: dist/DiskSim)
I am getting this error what does it mean?
Probably means that you're trying to run the code from the wrong directory. You need to run it from the same directory that all those files are in, not the parent directory (which I guess is where you're trying to run it from based on that error).
Keywords: assess4-1516
Submission reference: IN5016
I am getting an error saying that DSched is being used? What should I do?
You'll have to be a bit more specific than that I'm afraid. Being used what, where, how, in what context, specific error message, etc.? Probably easiest to pop along to my office and I'll have a quick look.
Submission reference: IN5015
Hi Fred, in the disk scheduler are are allowed to remove the requests which have been read from the read-queue, or should these stay there even after being read which would mean the largest size of our read-queue would get smaller each time a set of requests are made?
Also, am I correct that we are aiming for the smallest possible score? What would be considered a good score to get (70% +), I am currently getting around 1300?
Not sure I understand the first bit entirely: yes, once a request has been serviced, you remove it from the queue — that's what the existing LIFO and FIFO code do (okay, they don't scrub out the entry in the array/queue, but effectively do as it'll be overwritten with fresh requests coming in). But if you didn't do that, the request queue would just get larger and larger, not smaller!
For score comparison, feed it to the automated checker. You'd be aiming for "better than SSTF" or similar wording in all tests for a good score (where good is at least 65%+ probably). But in value terms, yes, you're trying to minimise the score value — as it represents time, the smaller the better.
Keywords: assess4-1516 , disk-scheduling
Submission reference: IN5014
Hi, someone told me that we cannot use for loops but I thought we could since it isn't an add-on to Java, like ArrayLists etc. are. Are they wrong or am I? Thanks.
You wouldn't get too far without 'for' loops! (I guess you could do it all with 'while' or recursion though). But plain-old "for (init; cond; iter) { ... }" loops are absolutely fine. What I did not want people to use are 'foreach' loops (nor the high-level 'Iterator' related things that go alongside them).
Keywords: assess4-1516
Submission reference: IN5013
I am getting an error with the online test https://www.cs.kent.ac.uk/studash/co527.php.
Warning: Identity file /web/cs/docs/studash/co527_keys/co527-doughnut-id not accessible: Permission denied. Permission denied (publickey,password).
I uploaded my DSched.java file
Sorry about that; my fault. I thought I'd fixed it, but evidently not. Definitely fixed now however.
Submission reference: IN5011
For the Disk Scheduling assessment, I notice that DiskSim.MAXREQUESTS is capped at 256. Are we allowed to create a read-queue array with a length of more than this?
Say for example: readqueue = new ReadReq[2000];
Is this allowed or do we need to keep that default at readqueue = new ReadReq[DiskSim.MAXREQUESTS];
You can make it larger, but it's fairly pointless: if you look at the other bits of code, though perhaps non-obvious, you'll see that no more than MAXREQUESTS requests are ever dispatched concurrently.
Keywords: assess4-1516
Submission reference: IN5010
Hi, are we allowed to implement our own data structure and not stick with the array, i.e. a linked-list or a hash table?
That's fine, but you must not use any of the Java API stuff. E.g. if you want a linked-list, do it yourself, not with the "LinkedList<Blah>" generics stuff. Similar with a hash-table, though I can't see any advantage of that in this case (and it'd be painful to implement in Java regardless).
Keywords: disk-scheduling , assess4-1516
Submission reference: IN5009
For the disk scheduling assessment, I'm struggling to work how how to specify the request file on raptor to test my algorithm.
I have tried: "java DiskSim -f requests-big.txt", however this does not work.
Could you please help?
You'll have to be a bit more descriptive: does not work in what specific way? Feel free to pop along to my [Fred's] office and I'll have a quick look. (silly question maybe, did you run "make" to actually compile the Java sources first?).
Keywords: assess4-1516
Submission reference: IN5002
Question for C-Look algorithm.
[snip]
Keywords: assess4-1516
|
Maintained by Fred Barnes, last modified Wed May 25 15:07:19 2016 |
