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.