Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!ames!pioneer!lamaster
From: lamaster@pioneer.UUCP
Newsgroups: comp.dcom.lans
Subject: Re: Smart Ethernet boards
Message-ID: <2302@ames.arpa>
Date: Tue, 7-Jul-87 12:14:12 EDT
Article-I.D.: ames.2302
Posted: Tue Jul  7 12:14:12 1987
Date-Received: Thu, 9-Jul-87 05:46:52 EDT
References: <283@sering.cwi.nl> <8212@utzoo.UUCP> <8255@utzoo.UUCP>
Sender: usenet@ames.arpa
Reply-To: lamaster@ames.UUCP (Hugh LaMaster)
Organization: NASA Ames Research Center, Moffett Field, Calif.
Lines: 63

In article <8255@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes:

>> If the on-board TCP/IP imposes more load on the CPU than an off-board
>> TCP/IP, then something is radically wrong with the design...

I do not think that this is correct.  It takes a lot of CPU cycles to build a
packet.  If your system is limited to one CPU, it may make a lot of sense to
offload tcp/ip somehow, especially if you are using mostly terminal servers.

>Yes, the decision to use an on-board TCP/IP is a mistake! :-)  Seriously,
>measure the overhead of talking to the board before you make such a sweeping
>statement.  It's considerable, I'm told.  And TCP/IP is not inherently a
>very costly protocol to implement off-board.

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.  Now, it all depends on a lot of
factors, such as the amount of data per write, which implementation (4.2 BSD,
4.3 BSD, etc. etc.) of tcp you are talking about, to see whether it is
appropriate.  But, the net result is that on-board tcp-ip can be a big win.
It is noted that there is a large difference in terminal controller boards
also, and whether the device driver is smart enough to take advantage of the
board.  Interrupt-per-character boards can be even slower than a slow tcp-ip
connection.  Now, there may be OTHER reasons for not using an on-board tcp.
Such as bug fixes and installation of new features.  But, I think the
performance improvement is not generally an issue.  Also note that there may
be other limitations that are not desirable, such as a limit of 48 tcp
connections active at any one time, etc.

I have done some measurements, and it is a fact that telnetd/tcp/ip is costly.
Maybe not impossibly costly, but costly.  In a typical editing &etc.
environment with a lot of users per machine, I think you can expect to buy
twice the CPU power to provide the same level of service if all your
connections are via telnet/tcp/ip from a terminal server.  I am not saying
that you won't want to do it.  There are a lot of good reasons to use terminal
servers.  But, it will cost you, especially if you are supporting a lot of
"little" users.  If you have fewer, more greedy users, tcp/ip overhead will
not be an issue.  I haven't done any measurements with 4.3 BSD and/or rlogin,
and things may be different there.  I would invite anyone who has more hard
data on this to post it.

>Given that we have a similar CPU and a large amount of memory, why not go
>for a dumb Ethernet board and a dual-CPU main processor?  That's probably
>a better use of the second CPU.

This is correct.  Unfortunately, multi-processor Unix is still a novelty.  If
AT&T and Berkeley can get their multiprocessor acts together, it should be a
lot easier to do this.  




  Hugh LaMaster, m/s 233-9,  UUCP {seismo,topaz,lll-crg,ucbvax}!
  NASA Ames Research Center                ames!pioneer!lamaster
  Moffett Field, CA 94035    ARPA lamaster@ames-pioneer.arpa
  Phone:  (415)694-6117      ARPA lamaster@pioneer.arc.nasa.gov


                 "IBM will have it soon"


(Disclaimer: "All opinions solely the author's responsibility")