Context switching performance of SunOS

Context switching performance of SunOS

Post by Yi Qin (BCW P » Wed, 01 Dec 1993 10:55:20



Hello.

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.

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?

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.

Thanx in advance.

Yi QIN

 
 
 

Context switching performance of SunOS

Post by Frank Muell » Thu, 02 Dec 1993 02:43:19



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

 
 
 

Context switching performance of SunOS

Post by Guy Harr » Thu, 02 Dec 1993 06:37:07


Quote:>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.

That's exactly what they do, on machines that have such a fine-grained
timer (all SPARC-based machines other than the Sun-4/2xx and
Sun-4/1xx machines).
 
 
 

Context switching performance of SunOS

Post by Danny Ch » Thu, 02 Dec 1993 13:12:28




>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.

you have to watch out for an "atomicity of access" problem when
combining two counters like this.  depending on the implementation,
you might have bad data at clock boundary conditions (such as at clock
interrupt time).  one clock might be wrapping around while the other
is being examined.  i think i talked about this problem in a paper
i presented at usenix in (i believe) 1989.  title was "casper the friendly
daemon".  i don't know what steps, if any, the sunos implementation
takes to avoid this problem.  if the problem has not been addressed,
then your timing measures will have a potential error of one clock
tick (even if the resolution is usec).

regarding (a), whenever we did measures of this nature, we ran the
system single user with as many processes/services turned off as possible.
this was tougher in the days when we were working on production pdp/11s
and vaxes (large machines shared by lots of people) but should be easier
now with individual workstations.  if not, then other factors beside
(c) will come into play (disk interrupts, etc.) and you will have to
try to factor them out.

danny chen

 
 
 

Context switching performance of SunOS

Post by John C Sag » Thu, 02 Dec 1993 19:20:30





> >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.

> you have to watch out for an "atomicity of access" problem when
> combining two counters like this.  depending on the implementation,
> you might have bad data at clock boundary conditions (such as at clock
> interrupt time).  one clock might be wrapping around while the other
> is being examined.  i think i talked about this problem in a paper
> i presented at usenix in (i believe) 1989.  title was "casper the friendly
> daemon".  i don't know what steps, if any, the sunos implementation
> takes to avoid this problem.  if the problem has not been addressed,
> then your timing measures will have a potential error of one clock
> tick (even if the resolution is usec).

Check out the xntp distribution in louie.udel.edu:/pub/ntp. This
contains a file, microtime.s, and instructions on how to incorporate it
into a SunOS4.1.x kernel to replace the uniqtime() routine (the kernel
routine called by gettimeofday()). This runs much faster than uniqtime()
and specifically does not have any problems with atomicity of access. If
you are going to do any serious kernel measurements, then this could be
very useful.

I also believe that certain Sparc models have an extra 1us resolution timer
which is not used for anything. This could also be pressed into service
with similar software to do independent timing.

John C Sager                                    Mail:   B67 G18, BT Labs

Tel:            +44 473 642623                          IPSWICH  IP5 7RE
Fax:            +44 473 637614                          England
Disclaimer:     This is me, not BT.