jsq@ut-sally.UUCP (08/09/83)
- 32 -
8.2.3 _I_n_t_e_r_n_e_t__(_T_C_P_/_I_P_) Both TCP and UDP are available for
use with IP either on the local network or over the
internet. ICMP is supported, and there are some gateway
facilities.
The socket IPC, together with a network library,
provides many of the functions of the Session layer. The
socket type SOCK_STREAM, which provides a reliable, ordered,
byte stream, is currently supported by TCP, while
SOCK_DGRAM, providing datagram service, is supported by UDP.
There is no internet protocol to support SOCK_SEQPACKET, for
sequenced packets. SOCK_RAW allows direct access to, for
instance, the IMP interface, for debugging and development
of new protocols. Only the superuser is permitted to use
this socket type.
At the Applications layer, the Internet protocols
Telnet, FTP, SMTP, and TFTP are supported.
8.2.4 _B_e_r_k_e_l_e_y__p_r_o_t_o_c_o_l_s The _b_e_r_k_n_e_t facilities of 4.1 are
officially removed from 4.1C and 4.2.
There are also various new protocols developed at
Berkeley, including remote login among machines under the
same administration without passwords (_r_l_o_g_i_n/_r_l_o_g_i_n_d).
Remote shells and remote procedure calls (_c_o_u_r_i_e_r_d) are
supported, as are file copy (_r_c_p/_r_s_h_d), and status protocols
such as the one that supports _r_w_h_o and _r_u_p_t_i_m_e (_r_w_h_o_d).
This latter takes advantage of the broadcast packet facility
of Ethernets and rings to exchange status information about
who is on what system and what systems are up on the local
network. (The idea is easily extensible to networks without
broadcast packets.) Some of these protocols use UDP and some
use TCP.
These protocols make use of several machines over a
local network or networks quite convenient.
8.3 UUCP
Both systems support UUCP, though the details diverge:
System V allows _u_u_c_p copy addresses to specify paths across
multiple systems (as for mail), while 4.1C still permits
copies only between adjacent systems. Naturally, all
systems in a multisystem path must be running _u_u_c_p with
forwarding to properly effect forwarding.
4.2 has all well-known _u_u_c_p bugs fixed. It also
supports more than half a dozen auto-dialers. The spooling
directories have been made sane.
- 33 -
The _c_u command is retained in System V, but dropped by
4.1C in favor of _t_i_p. _T_i_p gets parameters for a remote
system from /etc/remote (yet another _t_e_r_m_c_a_p-like file) so
it is possible to just type
tip system-name
and be connected to the remote system (whose name, _s_y_s_t_e_m-
_n_a_m_e, is in /etc/remote), without having to know the phone
number or devices involved.
If the _c_u interface is desired, linking _t_i_p to _c_u is
all that is required to get it. Various _c_u-like commands
are supported directly by _t_i_p.
System V includes a library routine, _d_i_a_l, used to
establish a dialout connection. This routine is used by _c_u,
but, curiously, _u_u_c_i_c_o still relies on the same old conn.c
code.
8.4 USENET
Neither system includes USENET news program sources.
4.2 will provide both USENET programs (_r_e_a_d_n_e_w_s, _p_o_s_t_n_e_w_s,
et al.) and notesfiles, as user contributed software.
In any case, the best version of news is clearly Bnews
2.10, which has been distributed over USENET. One method to
get it might be to set up a UUCP connection to a neighboring
USENET site and copy it over.
The USENET and UUCP networks have become widespread
enough that connection to them is certainly beneficial.
9. Performance
This is a sticky issue which we will not treat in
detail, as this is not a performance evaluation
presentation. We will give a few tentative benchmarks, and
mention two qualitative performance areas.
9.1 Some Qualitative Remarks
Two important areas where performance varies widely due
to system configuration and usage are paging vs. swapping
and terminal I/O.
9.1.1 _P_a_g_i_n_g__v_s_.__s_w_a_p_p_i_n_g System V, like System III, 32V,
V7, and all the PDP-11 Unixes, swaps, while 4.1C, like 4.1,
pages. With enough memory on a VAX-11/780, it is difficult
- 34 -
to tell the difference for a load of small processes,
because System V just doesn't swap.
If it is desirable to run huge graphics processes or
many Emacs editors or the like, the telling point is not so
much the performance as the virtual address space provided
by the 4.1C paging system. Such things as LISP _r_e_q_u_i_r_e the
large address space paging provides, and _I_n_g_r_e_s is much more
usable with it, since it can run as one process instead of
half a dozen.
We certainly do not intend to indicate, however, that
we think paging and swapping produce equivalent performance.
There are many technical papers on comparative performance
that indicate paging gives much better performance; it is
merely that our (admittedly idiosyncratic) experience was
that under a light load it is hard to tell the difference
without measuring it.
9.1.2 _T_e_r_m_i_n_a_l__I_/_O Using DH11 terminal controllers, 4.1C
provides reasonable terminal I/O performance. Berkeley has
modified the DZ11 driver sufficiently that even these
(basically interrupt per character) devices are usable. It
should be remembered that DEC does not provide DH11
controllers for VAXen. This affects DEC maintenance, though
similar hardware is available from other vendors.
If you need numerous terminals running at 9600 baud or
higher, the System V combination of DZ11s and KMC11 terminal
controllers seems preferable. The other side of this coin
is that little choice has been left for System V users,
since DH-11 driver support is not included in the
distribution and since DZs alone are unlikely to yield
acceptable response.
9.2 Tentative Benchmarks
These measurements were taken on a VAX-11/780 with six
megabytes of memory and a single RP07 disk.
The disk was partitioned into three sections which had
similar sizes under the two operating systems. The various
kernel parameters were chosen by configuring 4.1C for 32
users, and, for System V, by picking the largest parameter
values suggested in the documentation. The resulting
numbers of buffers, inode and file structures, etc., were
similar. Memory was interleaved.
No particular care was taken beyond these steps to tune
either system to its maximum performance.
- 35 -
The numbers given here should not taken too literally,
but only as indicative.
9.2.1 _L_o_a_d__s_i_m_u_l_a_t_i_o_n This was done using a program that
forks _p_t_y_s instances of itself, and then each _p_t_y* repeats a
_j_o_b forever, or rather, until the _r_u_n is over, as decided by
the original parent program. The _j_o_b is a brief shell
script that uses commands common to both systems, as found
on each system. Sources to compile with _c_c were taken from
System V to avoid the long filename problem. They were
carefully picked to avoid any System V peculiarities, such
as _g_e_t_o_p_t. Files to use with _n_r_o_f_f were also taken from
System V, for no particular reason.
The output was redirected to a file to avoid terminal
I/O considerations.
Repeated runs were taken until the job throughput
stopped decreasing due to file system degradation. The
following figures were obtained:
ptys 1 2 4 8 16
System V
jobs/hour/pty 46 25 13 6.4 3.2
jobs/hour 46 50 51 51 51
4.1C BSD
jobs/hour/pty 60 32 16 8 4
jobs/hour 60 64 64 64 64
The total number of jobs per hour increased slightly
from one to two ptys, and then remained constant, as all CPU
cycles were absorbed. The number of jobs per pty is, of
course, just the total divided by the number of ptys.
We interpret these results to mean that 4.1C is
noticeably faster than System V. We do not state the
obvious figure of 25%, because the results could easily be
varied by, for instance, increasing the amount of file I/O a
job uses (to take advantage of the faster 4.1C file system),
__________
* No _p_t_y devices were used: this term is used only for
convenience.
- 36 -
or by using larger processes (to force System V to swap,
which it never did with the above job).
Tuning either kernel could, of course, vary the results
either way.
Definitive benchmarks will have to await the release of
4.2BSD.
9.2.2 _F_i_l_e__s_y_s_t_e_m__t_h_r_o_u_g_h_p_u_t Our experience has been that
the 4.1C filesystem is markedly faster than the System V
one. However, the actual figures vary so much according to
the size of the files used, the transfer block size, the
filesystem block size, whether memory is interleaved or not,
etc. (though under all conditions we have tried 4.1C is
faster than System V), that it would take some months and
another paper the size of this one to deal with the problem.
Rather than present partial and possibly misleading figures,
we have decided to not present any.
10. Vendor Support
The amount and variety of support for UNIX has
increased dramatically over the last few years.
10.1 Western Electric
Western Electric supports System V on VAXes and the
larger PDP-11s, providing software assistance and user
training. (User training is now available, though software
assistance has apparently not yet been fully implemented.)
10.2 U.C. Berkeley
The University of California at Berkeley cannot,
because of the nature of the institution and of the funding
used to support the development of Berkeley UNIX, provide
commercial support. They do, however, accept bug reports,
which may affect future versions. See below on _D_E_C.
10.3 DEC
Digital Equipment Corporation has announced they will
support UNIX in the manner they have supported VMS as a VAX
operating system (and they will also support it on PDP-11s
(_V_7_M)). This is apparently basically Berkeley UNIX, i.e.,
4BSD (and 2BSD).