When we ran the context switch overhead tests for part 4 of the first paper assignment, there were a few time spikes scattered throughout the trials. I think they were mostly near the beginning of the trials, although sometimes the spikes did appear in other places. I would just like to know if anyone else has seen these spikes and if so, what they think could be the cause. Right now, it looks like these spikes are due to preemption or something similar that is cutting in on processor time, but there are other troubling possibilities.
One possible issue lies with the manner in which I implemented the repeated trials. Each testing program uses a function containing a for loop, and inside this loop is a call to a different function which performs a single trial. Inside the trial performing function, all variables, including the beginning and end time structs, are re-declared. At first I thought it would be wise to perform each trial in a fresh context using the implementation described above. However, I am now concerned as to whether this could be effecting the time measurements. In particular, I am worried about the possibility that some of the methods for performing a context switch might perform differently the first time, in which case these measurements, which treat every trial like the first trial, would be no good.
How close, in general, should the trial loop be to the actual trial implementation? Is it okay to remove it to a different function as I have done, or would it be smarter to perform the tests with a loop closely surrounding the trial implementation, all in the same context? Would it be safe to assume that each context used for a context switch trial is relatively the same, or would it be safer to keep producing new contexts to obtain a more varied population sample?
It is really hard to understand exactly what you've done, so we need to talk more about the details before I can help you out.
ReplyDelete