Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!topaz.rutgers.edu!hedrick
From: hedrick@topaz.rutgers.edu (Charles Hedrick)
Newsgroups: comp.dcom.lans
Subject: Re: Smart Ethernet boards
Message-ID: <13203@topaz.rutgers.edu>
Date: Tue, 7-Jul-87 18:15:37 EDT
Article-I.D.: topaz.13203
Posted: Tue Jul  7 18:15:37 1987
Date-Received: Fri, 10-Jul-87 06:00:39 EDT
References: <283@sering.cwi.nl> <8212@utzoo.UUCP> <8255@utzoo.UUCP> <2302@ames.arpa>
Organization: Rutgers Univ., New Brunswick, N.J.
Lines: 33

Hugh LaMaster comments
>According to information from Excelan, there is almost no difference between a
>tty connection and Excelan on-board tcp/ip for 4.2 BSD Unix; there is a much
>greater overhead (on a standard test, about 10-20X) between either tty or
>on-board tcp/ip and 4.2 BSD pseudo-tty.  

Note that there is a lot more going on here than meets the eye.  This
is talking about an incoming telnet connection.  That involves more
than just the overhead of protocol handling.  In the standard 4.2
software implementation, incoming telnet involves a separate daemon
that passes data between the network and a pty.  Thus characters go
through three device drivers (network, pty, and tty) and a process
activation in each direction (typin and echo).  The actual TCP
processing is a small part of the overhead.  On our Pyramids, we
bypass this daemon for most of the telnet conversation, by having an
ioctl that crosspatches a TCP connection directly to a pty.  The
characters are passed between the network and the tty buffers in the
kernel.  (If the code detects an IAC, it returns from the ioctl, so
that the daemon can still do the negotiations and other complex
stuff.)  This implementation gets a dramatic improvement, possibly as
much as 10 to 20X.  It's not just an issue of CPU time.  Under
moderate load, the normal telnet implementation has kind of mediocre
response time.  Recall that a user-level process has to be activated
for each character you type and the echo.  On a busy machine, the
process activations and possible pageins can slow things down.  Like
you, I would not consider doing large-scale timesharing on a machine
where most of the users came in through the normal telnetd mechanism.

At any rate, the point is that the tests you quote may be confusing
the benefits of offloading protocol processing with the benefits of
getting rid of telnetd and pty overhead.  If you want to just the
benefits of offloading protocol processing, it would be better to use
FTP for the tests.