/share/doc/papers/sysperf/5.t

  1.\" Copyright (c) 1985 The Regents of the University of California.
  2.\" All rights reserved.
  3.\"
  4.\" Redistribution and use in source and binary forms, with or without
  5.\" modification, are permitted provided that the following conditions
  6.\" are met:
  7.\" 1. Redistributions of source code must retain the above copyright
  8.\"    notice, this list of conditions and the following disclaimer.
  9.\" 2. Redistributions in binary form must reproduce the above copyright
 10.\"    notice, this list of conditions and the following disclaimer in the
 11.\"    documentation and/or other materials provided with the distribution.
 12.\" 3. All advertising materials mentioning features or use of this software
 13.\"    must display the following acknowledgement:
 14.\"	This product includes software developed by the University of
 15.\"	California, Berkeley and its contributors.
 16.\" 4. Neither the name of the University nor the names of its contributors
 17.\"    may be used to endorse or promote products derived from this software
 18.\"    without specific prior written permission.
 19.\"
 20.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
 21.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 22.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 23.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
 24.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 25.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 26.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 27.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 28.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 29.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 30.\" SUCH DAMAGE.
 31.\"
 32.\"	@(#)5.t	5.1 (Berkeley) 4/17/91
 33.\"
 34.\" $FreeBSD$
 35.\"
 36.ds RH Functional Extensions
 37.NH
 38Functional Extensions
 39.PP
 40Some of the facilities introduced in 4.2BSD were not completely
 41implemented.  An important part of the effort that went into
 424.3BSD was to clean up and unify both new and old facilities.
 43.NH 2
 44Kernel Extensions
 45.PP
 46A significant effort went into improving
 47the networking part of the kernel.
 48The work consisted of fixing bugs,
 49tuning the algorithms,
 50and revamping the lowest levels of the system
 51to better handle heterogeneous network topologies.
 52.NH 3
 53Subnets, Broadcasts and Gateways
 54.PP
 55To allow sites to expand their network in an autonomous
 56and orderly fashion, subnetworks have been introduced in 4.3BSD [GADS85].
 57This facility allows sites to subdivide their local Internet address
 58space into multiple subnetwork address spaces that are visible
 59only by hosts at that site.  To off-site hosts machines on a site's
 60subnetworks appear to reside on a single network.  The routing daemon
 61has been reworked to provide routing support in this type of
 62environment.
 63.PP
 64The default Internet broadcast address is now specified with a host part
 65of all one's, rather than all zero's.
 66The broadcast address may be set at boot time on a per-interface basis.
 67.NH 3
 68Interface Addressing
 69.PP
 70The organization of network interfaces has been
 71reworked to more cleanly support multiple
 72network protocols.  Network interfaces no longer
 73contain a host's address on that network; instead
 74each interface contains a pointer to a list of addresses
 75assigned to that interface.  This permits a single
 76interface to support, for example, Internet protocols
 77at the same time as XNS protocols.
 78.PP
 79The Address Resolution Protocol (ARP) support
 80for 10 megabyte/second Ethernet\(dg
 81.FS
 82\(dg Ethernet is a trademark of Xerox.
 83.FE
 84has been made more flexible by allowing hosts to
 85act as a ``clearing house'' for hosts that do
 86not support ARP.  In addition, system managers have
 87more control over the contents of the ARP translation
 88cache and may interactively interrogate and modify
 89the cache's contents.
 90.NH 3
 91User Control of Network Buffering
 92.PP
 93Although the system allocates reasonable default amounts of buffering
 94for most connections, certain operations such as file system dumps
 95to remote machines benefit from significant increases in buffering [Walsh84].
 96The \fIsetsockopt\fP system call has been extended to allow such requests.
 97In addition, \fIgetsockopt\fP and \fIsetsockopt\fP,
 98are now interfaced to the protocol level allowing protocol-specific
 99options to be manipulated by the user.
100.NH 3
101Number of File Descriptors
102.PP
103To allow full use of the many descriptor based services available,
104the previous hard limit of 30 open files per process has been relaxed.
105The changes entailed generalizing \fIselect\fP to handle arrays of
10632-bit words, removing the dependency on file descriptors from
107the page table entries,
108and limiting most of the linear scans of a process's file table.
109The default per-process descriptor limit was raised from 20 to 64,
110though there are no longer any hard upper limits on the number
111of file descriptors.
112.NH 3
113Kernel Limits
114.PP
115Many internal kernel configuration limits have been increased by suitable
116modifications to data structures.
117The limit on physical memory has been changed from 8 megabyte to 64 megabyte,
118and the limit of 15 mounted file systems has been changed to 255.
119The maximum file system size has been increased to 8 gigabyte,
120number of processes to 65536,
121and per process size to 64 megabyte of data and 64 megabyte of stack.
122Note that these are upper bounds,
123the default limits for these quantities are tuned for systems
124with 4-8 megabyte of physical memory.
125.NH 3
126Memory Management
127.PP
128The global clock page replacement algorithm used to have a single
129hand that was used both to mark and to reclaim memory.
130The first time that it encountered a page it would clear its reference bit.
131If the reference bit was still clear on its next pass across the page,
132it would reclaim the page.
133The use of a single hand does not work well with large physical
134memories as the time to complete a single revolution of the hand
135can take up to a minute or more.
136By the time the hand gets around to the marked pages,
137the information is usually no longer pertinent.
138During periods of sudden shortages,
139the page daemon will not be able to find any reclaimable pages until
140it has completed a full revolution.
141To alleviate this problem,
142the clock hand has been split into two separate hands.
143The front hand clears the reference bits,
144the back hand follows a constant number of pages behind
145reclaiming pages that still have cleared reference bits.
146While the code has been written to allow the distance between
147the hands to be varied, we have not found any algorithms
148suitable for determining how to dynamically adjust this distance.
149.PP
150The configuration of the virtual memory system used to require
151a significant understanding of its operation to do such
152simple tasks as increasing the maximum process size.
153This process has been significantly improved so that the most
154common configuration parameters, such as the virtual memory sizes,
155can be specified using a single option in the configuration file.
156Standard configurations support data and stack segments
157of 17, 33 and 64 megabytes.
158.NH 3
159Signals
160.PP
161The 4.2BSD signal implementation would push several words
162onto the normal run-time stack before switching to an
163alternate signal stack.
164The 4.3BSD implementation has been corrected so that
165the entire signal handler's state is now pushed onto the signal stack.
166Another limitation in the original signal implementation was
167that it used an undocumented system call to return from signals.
168Users could not write their own return from exceptions;
1694.3BSD formally specifies the \fIsigreturn\fP system call.
170.PP
171Many existing programs depend on interrupted system calls.
172The restartable system call semantics of 4.2BSD signals caused
173many of these programs to break.
174To simplify porting of programs from inferior versions of
175.UX
176the \fIsigvec\fP system call has been extended so that
177programmers may specify that system calls are not to be
178restarted after particular signals.
179.NH 3
180System Logging
181.PP
182A system logging facility has been added
183that sends kernel messages to the
184syslog daemon for logging in /usr/adm/messages and possibly for
185printing on the system console.
186The revised scheme for logging messages
187eliminates the time lag in updating the messages file,
188unifies the format of kernel messages,
189provides a finer granularity of control over the messages
190that get printed on the console,
191and eliminates the degradation in response during the printing of
192low-priority kernel messages.
193Recoverable system errors and common resource limitations are logged
194using this facility.
195Most system utilities such as init and login,
196have been modified to log errors to syslog
197rather than writing directly on the console.
198.NH 3
199Windows
200.PP
201The tty structure has been augmented to hold
202information about the size
203of an associated window or terminal.
204These sizes can be obtained by programs such as editors that want
205to know the size of the screen they are manipulating.
206When these sizes are changed,
207a new signal, SIGWINCH, is sent the current process group.
208The editors have been modified to catch this signal and reshape
209their view of the world, and the remote login program and server
210now cooperate to propagate window sizes and window size changes
211across a network.
212Other programs and libraries such as curses that need the width
213or height of the screen have been modified to use this facility as well.
214.NH 3
215Configuration of UNIBUS Devices
216.PP
217The UNIBUS configuration routines have been extended to allow auto-configuration
218of dedicated UNIBUS memory held by devices.
219The new routines simplify the configuration of memory-mapped devices
220and correct problems occurring on reset of the UNIBUS.
221.NH 3
222Disk Recovery from Errors
223.PP
224The MASSBUS disk driver's error recovery routines have been fixed to
225retry before correcting ECC errors, support ECC on bad-sector replacements,
226and correctly attempt retries after earlier
227corrective actions in the same transfer.
228The error messages are more accurate.
229.NH 2
230Functional Extensions to Libraries and Utilities
231.PP
232Most of the changes to the utilities and libraries have been to
233allow them to handle a more general set of problems,
234or to handle the same set of problems more quickly.
235.NH 3
236Name Server
237.PP
238In 4.2BSD the name resolution routines (\fIgethostbyname\fP,
239\fIgetservbyname\fP,
240etc.) were implemented by a set of database files maintained on the
241local machine.
242Inconsistencies or obsolescence in these files resulted in inaccessibility of
243hosts or services.
244In 4.3BSD these files may be replaced by a network name server that can
245insure a consistent view of the name space in a multimachine environment.
246This name server operates in accordance with Internet standards
247for service on the ARPANET [Mockapetris83].
248.NH 3
249System Management
250.PP
251A new utility, \fIrdist\fP,
252has been provided to assist system managers in keeping
253all their machines up to date with a consistent set of sources and binaries.
254A master set of sources may reside on a single central machine,
255or be distributed at (known) locations throughout the environment.
256New versions of \fIgetty\fP, \fIinit\fP, and \fIlogin\fP
257merge the functions of several
258files into a single place, and allow more flexibility in the
259startup of processes such as window managers.
260.PP
261The new utility \fItimed\fP keeps the time on a group of cooperating machines
262(within a single LAN) synchronized to within 30 milliseconds.
263It does its corrections using a new system call that changes
264the rate of time advance without stopping or reversing the system clock.
265It normally selects one machine to act as a master.
266If the master dies or is partitioned, a new master is elected.
267Other machines may participate in a purely slave role.
268.NH 3
269Routing
270.PP
271Many bugs in the routing daemon have been fixed;
272it is considerably more robust,
273and now understands how to properly deal with
274subnets and point-to-point networks.
275Its operation has been made more efficient by tuning with the use
276of execution profiles, along with inline expansion of common operations
277using the kernel's \fIinline\fP optimizer.
278.NH 3
279Compilers
280.PP
281The symbolic debugger \fIdbx\fP has had many new features added,
282and all the known bugs fixed.  In addition \fIdbx\fP
283has been extended to work with the Pascal compiler.
284The fortran compiler \fIf77\fP has had numerous bugs fixed.
285The C compiler has been modified so that it can, optionally,
286generate single precision floating point instructions when operating
287on single precision variables.