Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!brchs1!bnr.ca!rice.edu!sun-spots-request
From: hakanson@cse.ogi.edu (Marion Hakanson)
Newsgroups: comp.sys.sun
Subject: Re: Socket operation delays
Keywords: SunOS
Message-ID: <543@brchh104.bnr.ca>
Date: 29 Nov 90 17:09:08 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 43
Approved: Sun-Spots@rice.edu
X-Original-Date: 21 Nov 90 23:40:27 GMT
X-Refs:  Original: v9n376
X-Sun-Spots-Digest: Volume 9, Issue 384, message 2
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

In article <409@brchh104.bnr.ca> THIER@orcad2.dnet.ge.com writes:
>. . .
>I am attempting to characterize system response times for IPC operations
>on a SPARCStation 1+, running "out-of-the-box" 4.1 (generic kernel,
>. . .
>Surrounding the IPC system call with two gettimeofday calls and computing
>the difference, I've measured gross variations in socket create, connect
>and send durations. The periods are most often only 1 microsecond, but
>frequent delays of 10 millisecond intervals are encountered. I assume that
>the delays result from the UNIX scheduler taking over during, or between,
>the system calls. Is this correct? If so, I'm looking for information

I'm certain that the reason is not what you think.  The clock is broken on
this machine/OS combination.  Even though a SPARC-1 and SPARC-1+ have the
same kind of clock (with 1-microsecond resolution), the SunOS-4.1 kernel
has a bug which causes the SPARC-1+ to run as a normal Sun-4, with a
10-millisecond resolution "soft" clock, while a SPARC-1's gettimeofday()
syscall has access to the hardware clock.

The many 1-microsecond values you're getting come from an artificial
increment added between softclock ticks, which is intended to keep two
subsequent gettimeofday() calls from returning the same value (those with
kernel source can look in microtime(), I believe).  If the clock were
working, you'd most likely see something more than 40-50 usec, which is
about the fastest one can make two gettimeofday() calls without doing much
in between.

So, the 1 usec values are erroneous, and the 10 msec value comes when two
calls happen to straddle a soft tick.  Note that you'll see these kinds of
results on a SPARC-330, 4/280, 4/110, and just about any 4.3bsd-based
system with a 10 msec soft clock.  I have a generic (BSD) test program:
anonymous FTP to cse.ogi.edu, file pub/clockres.c, which can usually tell
you the effective resolution of your system clock.

Reports from folks at Sun say that the bug is fixed in SunOS-4.1.1, which
means that all Sun-4c's (SLC, IPC, SS1+) provide access to the 1 usec
resolution of the underlying hardware clock.

Too bad the SPARC's clock stability (e.g. for use as an NTP platform) is
still so poor....

Marion Hakanson         Domain: hakanson@cse.ogi.edu
                        UUCP  : {hp-pcd,tektronix}!ogicse!hakanson