Path: utzoo!utgpu!cunews!bnrgate!brtph3!brchh104!date '+%m/%d/%y %H:%M:%S'brchs1!bnr.ca!riceu!sun-spots-request
From: THIER@orcad2.dnet.ge.com
Newsgroups: comp.sys.sun
Subject: Socket operation delays
Keywords: SunOS
Message-ID: <409@brchh104.bnr.ca>
Date: 21 Nov 90 14:30:23 GMT
Sender: news@brchh104.bnr.ca
Organization: Sun-Spots
Lines: 22
Approved: Sun-Spots@rice.edu
X-Original-Date: Wed, 7 Nov 90 14:36:56 EST
X-Sun-Spots-Digest: Volume 9, Issue 376, message 3
X-Note: Submissions: sun-spots@rice.edu, Admin: sun-spots-request@rice.edu

I am attempting to characterize system response times for IPC operations
on a SPARCStation 1+, running "out-of-the-box" 4.1 (generic kernel,
standard daemons enabled, etc.). The objective is to identify how
deterministic (or not) TCP transfer times can be, given a fixed, small LAN
environment (host-to-host, each running a single user process, no other
network traffic). 

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
regarding the scheduling mechanism and other OS overhead (frequency of the
scheduler taking control, duration that it holds control, how it handles
interrupted system calls, time allocated to daemons, etc.) and suggestions
for managing these delays. Thanks in advance.

John Thier
GE DSD
Pittsfield, MA
thier@orcad2.dnet.ge.com