TCP/IP boards

[Steve Dyer]

In article <6800058 at cpe> tif at cpe.UUCP writes:
>
>In article <873 at applix.UUCP> jim at 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 at arktouros.mit.edu
dyer at spdcc.com aka ...!{harvard,linus,ima,m2c,rayssd}!spdcc!dyer