Path: utzoo!utgpu!watmath!clyde!bellcore!rutgers!mailrus!cornell!uw-beaver!mit-eddie!bloom-beacon!arktouros!dyer From: dyer@arktouros.MIT.EDU (Steve Dyer) Newsgroups: comp.unix.xenix Subject: Re: TCP/IP boards Message-ID: <8364@bloom-beacon.MIT.EDU> Date: 8 Dec 88 14:43:16 GMT References: <374@intek01.UUCP> <6800058@cpe> Sender: daemon@bloom-beacon.MIT.EDU Reply-To: dyer@arktouros.MIT.EDU (Steve Dyer) Organization: MIT Project Athena, Cambridge MA 02139 Lines: 41 In article <6800058@cpe> tif@cpe.UUCP writes: > >In article <873@applix.UUCP> jim@applix.UUCP (Jim Morton) writes: >>Interactive 386/ix 1.06 has, and SCO Unix V.3.2 will have, as options, >>host based TCP/IP with support for the following dumb ethernet boards: > >Does it bother anybody else that they are only supporting dumb boards? >Won't that be an awful heavy load on the CPU? So-called "smart" board support has been available for a while for 386/ix and SCO XENIX from companies like MICOM/Interlan and Excelan (maybe CMC, too.) Usually, these so-called "smart" boards have limited memory and processing power, placing constraints on the number of virtual circuits you can have active and limiting throughput due to the anemic CPU on the intelligent board. I have mentioned before the problems with routing on multi-homed hosts using such boards. They have an important role, however, since it is rather easy to develop a device-driver interface to such a board which requires minimal changes to a kernel binary distribution. I was involved with moving a protocol stack (not TCP) from a smart board to the OS kernel to solve the embarassing situation of a super- supermini being only able to have 5 virtual circuits active, and those with rather poor throughput compared to what the machine was capable of. An extreme case, but not too far from the truth with today's mini-class 386 systems. Host-based TCP/IP need not impose excessive load on a system. I think the current BSD TCP/IP takes less than 5-10% of the CPU under ordinary use (using many telnetd and rlogind processes may require more, but then, these run on the host CPU with most smart boards too.) The advantage of a host-based protocol stack, assuming the host has richer resources of CPU and memory, is that the protocol suite has a greater "dynamic range" and can respond to demands for additional memory and/or CPU more easily. When a smart board runs out of its 256K of memory or runs out of steam from its processor, you're out of luck. --- Steve Dyer dyer@arktouros.mit.edu dyer@spdcc.com aka ...!{harvard,linus,ima,m2c,rayssd}!spdcc!dyer