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")