NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/unix/programm/3868

Internet Message Format | 1992-07-23 | 5.1 KB

Xref: sparky comp.unix.programmer:3868 comp.unix.internals:1595
Path: sparky!uunet!gatech!mailer.cc.fsu.edu!sun13!pi!mueller
From: [e-mail] (Frank Mueller)
Newsgroups: comp.unix.programmer,comp.unix.internals
Subject: ANSWERS How to measure context switches
Message-ID: <[e-mail]>
Date: 23 Jul 92 16:54:53 GMT
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Followup-To: comp.unix.programmer
Organization: Florida State University Computer Science
Lines: 129

Not too long ago I posted the following question, summarized below are
some responses and I comment on my part about my experience with the
different solutions. Thanks for those of you who responded.

Original posting:
> Hi there!
>
> I'm trying to measure the context switch overhead of UNIX processes (SunOS 4.1).
>
> I did something like this:
>
> fork off a child,
> lower the parent's priority (-> nice lavel)
> child installs a signal handler
> child suspends on sigpause
> parent reads clock (before)
> parent sends signal to child
> child resumes
> child executes signal handler which contains a call to read the clock (after)
>
> The approximate time for the context switch is (after-before). But I am also
> timing some operations which are not part of the context switch:
> (a) the parent's sending of the signal
> (b) the overhead of installing a signal handler for the child (_sigtramp etc.)
>
> Does anyone know a more accurate way to measure the context switch time
> between UNIX processes?
>
> -------------------------------------------------------------------------
Answer:
>
> hello,
>     I don't know how to accurately do the timings outside the kernel
> I'm afraid. However I don't see how your method can work given the
> accuracy of the clock in Unix. In Unix accuracy is usually only as fine
> grained as the system HZ rate, i.e. about 10-20 milliseconds, which is
> far longer than context switch time. You are also measuring (above) the
> time for the clock system call. You really need to get into the kernel..
> I'd be interested if anyone thinks up something sneaky.
>
> warwick
>
> ps. Is this thread package going to be public domain? Do you know of
> any that are? Thanks.
>
My comment:

This is very true, the ``accuracy'' of the UNIX timer doesn't allow
for measurements at such a low level. My original post left out a few
(but spicy) details about my approach: I use the dual-loop timing
method: My first measurement executes an empty counter loop for n
times and measures the time1 spent in this loop. The clock is read
before and after the loop. The second loop contains something like the
code described above but I have two tasks signalling each other,
thereby causing two context switches per iteration. Time2 is the time
spent in this second loop. Therefore, the average context switch time
is

(time2 - time1) / number of iterations.

As you can see, the overhead of reading the clock can be neglected.
But the overhead of signalling for sender and receiver is also
included.

Here are the results for approach1:
10000 process context switches
4134.49 milliseconds elapsed time
413.45 microseconds per operation

> -------------------------------------------------------------------------
Answer:
>
> Frank,
>
> > Does anyone know a more accurate way to measure the context switch time
> > between UNIX processes?
>
> I have done a similar exp. earlier and used IPC semaphore to cause context
> switches between two processes.  If you can run two processes that keeps
> releasing and acquiring a semaphore in an idle system and measure the
> number of switches / sec. (sar -p will give that) you can get a better
> estimate of context switch overhead.
>
> Inform me if you get any better suggestion.
>
> Subbu
>
> HP/Cupertino

I implemented this also with the dual loop timing method. The body of
the second loop contains calls to lock/unlock semaphores only.

Here are the results for approach2:
10000 process context switches
3868.02 milliseconds elapsed time
386.80 microseconds per operation

All measurements were taken on a SUN IPC.

This seems to indicate that the overhead of signals is somewhat lower
than semaphores.

Then I wrote a dual loop timing where a process installed a signal
handler and send the signal repeatedly to itself. This way I timed the
overhead of executing a signal handler.

Here are the results for approach3:
10000 signal overhead
2008.19 milliseconds elapsed time
200.82 microseconds per operation

Thus, the overhead for a process context switch seems to be around
210usec (approach1 - approach3).

And, to come back to Warwick's question, the context switch time for
threads in my implementation is somewhere around 70usec. Maybe POSIX
threads really do have a future. We are currently working on
non-blocking I/O for threads. Once this is done we hope to be able to
release a library version of POSIX threads for the Sun SPARC
architecture under SunOS, probably in source code accessible via ftp
around the end of the year!? If the different parties who are funding
this project agree, that is.

Thanks for everybody's input. (And maybe someone still knows a
better way...:-)

Frank
[e-mail]