Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Lab4 prob
0 views
Skip to first unread message
Sidd
May 8, 2005, 3:02:09 PM5/8/05
to
Hey guys. Ok, our prog works for 3 of the 4 news test cases. But for
teste03.txt something weird happens. Our test03_contents matches the one
given, but in our test03_rc, we have:
PID=100,...,BLK=5
PID=200,...,BLK=6
.
.
.
ie, BLK is in continuous order 5, 6, 7, 8, .. (skipping of course for the
inode blocks) instead of 21,5,22,23,6, ... in the provided solution. This
doesn't happen in any of the other tests, just this one. Any idea what's
going wrong?
teste03.txt something weird happens. Our test03_contents matches the one
given, but in our test03_rc, we have:
PID=100,...,BLK=5
PID=200,...,BLK=6
.
.
.
ie, BLK is in continuous order 5, 6, 7, 8, .. (skipping of course for the
inode blocks) instead of 21,5,22,23,6, ... in the provided solution. This
doesn't happen in any of the other tests, just this one. Any idea what's
going wrong?
Eric Tschetter
May 8, 2005, 3:14:42 PM5/8/05
to
Is your scheduler implemented differently than the reference scheduler? If
so, look through some of the more recent posts, there was a whole long
thread about scheduler differences and what you need to/don't need to worry
about.
--Eric
Sidd
May 8, 2005, 10:05:16 PM5/8/05
to
Well I did look at a few posts but they didn't help too much. Every time I
change my scheduler a bit, the block numbers change. And we weren't supposed
to implement RR with quantum 3 exactly as they did right? I mean I do use RR
with quantum 3 but it's the details that could make the difference. The post
titled "teste03.txt scheduler" does match out problem but the only reply
from the TA is that "The new DiskDumper does not depend on the position of
the data blocks of the files and it was used to grade those tests with many
processes." Well it's our rc that has a problem not diskdumper per se. And
in rc block number does matter otherwise we wouldn't have lost any points.
change my scheduler a bit, the block numbers change. And we weren't supposed
to implement RR with quantum 3 exactly as they did right? I mean I do use RR
with quantum 3 but it's the details that could make the difference. The post
titled "teste03.txt scheduler" does match out problem but the only reply
from the TA is that "The new DiskDumper does not depend on the position of
the data blocks of the files and it was used to grade those tests with many
processes." Well it's our rc that has a problem not diskdumper per se. And
in rc block number does matter otherwise we wouldn't have lost any points.
Any advice/help is greatly appreciated!
"Eric Tschetter" <er...@mail.utexas.edu> wrote in message
news:d5lof6$s4b$1...@news.cs.utexas.edu...
Eric Tschetter
May 9, 2005, 1:38:56 AM5/9/05
to
> Well I did look at a few posts but they didn't help too much. Every time I
> change my scheduler a bit, the block numbers change. And we weren't
> supposed to implement RR with quantum 3 exactly as they did right? I mean
> I do use RR with quantum 3 but it's the details that could make the
> difference. The post titled "teste03.txt scheduler" does match out problem
> but the only reply from the TA is that "The new DiskDumper does not depend
> on the position of the data blocks of the files and it was used to grade
> those tests with many processes." Well it's our rc that has a problem not
> diskdumper per se. And in rc block number does matter otherwise we
> wouldn't have lost any points.
>
> Any advice/help is greatly appreciated!
> change my scheduler a bit, the block numbers change. And we weren't
> supposed to implement RR with quantum 3 exactly as they did right? I mean
> I do use RR with quantum 3 but it's the details that could make the
> difference. The post titled "teste03.txt scheduler" does match out problem
> but the only reply from the TA is that "The new DiskDumper does not depend
> on the position of the data blocks of the files and it was used to grade
> those tests with many processes." Well it's our rc that has a problem not
> diskdumper per se. And in rc block number does matter otherwise we
> wouldn't have lost any points.
>
> Any advice/help is greatly appreciated!
I'm sure/hope you've read the continuation on the thread you mentioned, but
if the DiskDumper contents match, then the RC file's block numbers don't
have to match (though I believe they are the only thing that doesn't have to
match)...
--Eric
Emmett Witchel
May 9, 2005, 3:28:49 AM5/9/05
to
The new ReadCheck.java (see lab 4 redux page) does not print block numbers. The rc file you generate with that code should match the (new) rc file on the web page.
http://www.cs.utexas.edu/users/witchel/372/labs/lab4/redux/
0 new messages