Stress testing?

Iulian Neamtiu

2005-03-11 04:32:57 UTC

Well, for the projects in this class, we try to keep the focus more on
functionality and less on performance, hence we won't do too much stress testing.
The way we test is described in the grading criteria; we usually run
the test programs once, and only start them twice (or more) if they happen
to crash Bochs, hence we have to restart the emulator.

Be aware, however, that we reserve the right to deduct points if a test
program can be run successfully only once. In theory, we should be able to
run programs as many times as we like, unless they consume some limited
resource (disk space, for instance). We shouldn't restart the Bochs
emulator between succesive program invocations.

In practice, if you can run a test program say 3 times and you get
consistent, correct results, you're in good shape.

We'll probably have stress testing in the last two projects,
but that will be mentioned explicitly in the grading criteria.

Iulian

Post by Timothy Finley
I was wondering how much I should worry about stress testing my project
(I'm not using the p2 solution). I know that I don't clean up memory as
well as the p2 solution is doing after taking a glance though the p2 soln.
How robust do our projects have to be? I did a bit of stress testing and
saw that I would run out of memory after 20-30 processes. After a few
small clean ups I could run at least 100-200 procs (I just stopped though
I never got a mem overflow so I'm not sure what the limit is).
I guess this relates to how exactly you are going to follow the grading
guidelines. (Which we don't know very well since we still haven't got
project 1 back yet). I really am not trying to harp on the TAs but just
trying to find out the extent to which our projects will be tested (eg are
you going to be running workload and other tests a few times, several
times, or maybe 30-40 times).
Tim