Quote:> Has there anybody done any performance measurements for context switching
> on SunOS? I am interested in any suggestions/pointers to publications/
> reports. I need to know the version of the SunOS tested, the hardware
> platform used, etc. I need the sound figures to do overhead analysis.
> Any help will be very much appreciated.
I published timings of the context switch in a USENIX conference. It's on ftp at
ftp-site: ftp.cs.fsu.edu
internet#: 128.186.121.27
directory: /pub/PART
file: pthreads_usenix93.ps.Z
This was done with dual loop timing of a context switch of two processes sending
each other a signal and waiting for the signal alternately. Take the elapsed time
minus the signal overhead (which I also measured) and you have the context switch
time.
Quote:> It may be possible to work out the overhead of context switching (and interrupt-
> like handling for invoking a system call) from the number of instructions
> used and the average timing of each instruction. So, how many instructions
> are used for each context switch/system call handling?
This is not a good measure. Consider the impact of caches, just to mention one
problem.
Quote:> BTW, I am also interested in the performance of fork(), socket(), send()/
> sendto(), recv()/recvfrom(). I used gettimeofday() to measure the response
> time for these system calls. But I doubt the accuracy of measurements
> though timing given by gettimeofday() in SunOS is down to the microseconds level.
I looked at the gettimeofday() accuracy recently. I found that Sun must use
a 10ms interrupt time for coarse grain time and a fine grain timer which counts
the microsecs since the last time interrupt. gettimeofday() returns the sum of
these two. This is very accurate as far as I can tell, with three problems:
(a) Activities of other processes (and preferably the ethernet, mouse, etc.)
have to be shut out. This is almost impossible over a long time. But it
may be true for a short time.
(b) The startup time of code may take longer (at least due to cache misses).
(c) The timer interrupt comes in every 10ms and steals a varying amount of time.
I suggest that you run the code you intend to time in a loop and record the
time it takes for each iteration (in an array). The actual time should be the
minimum of the recorded time, i.e. when no interrupts etc. occured.
This should be even more accurate than dual loop timing since dual loop timing
will measure at least the startup time and the timer interrupt. Statistically,
this might not be a big problem (and it hasn't been one for me in the past)
since the startup occurs only once and the timer interrupt frequency is long
enough relative to the interrupt handling time.
That's all I can suggest.
Frank
by