Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!interlan!brad From: brad@interlan.UUCP (Brad Kemp) Newsgroups: comp.protocols.misc Subject: Re: TCP/IP vis Netware. Keywords: Dumb vs. Smart Controllers Message-ID: <571@interlan.UUCP> Date: 27 Oct 88 13:22:57 GMT References: <132@icarus.kulcs.uucp> <570@interlan.UUCP> Reply-To: brad@interlan.UUCP (Brad Kemp) Organization: Interlan, Inc., Boxborough, MA (1-800-LAN-TALK) Lines: 36 One point that has not been brought up in this discussion of the advantages of dumb over smart cards is the topology of the network in question. Although end to end throughput may be slower using an intelligent processor on a fast machine (i.e 80386, 68030 etc...) this should not be the only concern when making the dumb vs. smart choice. Some networks produce an astonishingly high amout of broadcast noise. This is especially true when multiple protocols are run over the same media. The host must deal with each of these recieve interrupts and determine if the packet is for it. This consumes host resources and lowers the total work capacity of the host since packets are recieved regardless of whether the user(s) are using the network or not. A compromise on fast machines seems to be using an intelligent data link controller. The fastest version of TCP/IP we run here uses a smart card as a data link controller. This frees the host from servicing extranious noise since packet filetering is done in the controller yet lets the speed of the host meet the end to end throughput requirements of faster machines. This also reduced the CPU time spent on protocol processing by 50% vs. the dumb card implementation. Of course previous points have been made when the host is multi-user but even here the topology should be taken into account. Some fast implementations of protocols are sutible for a host based solution on fast machines, others are not. If the network has many short lived connections, establishment and release of connections can eat host cycles. Here it may be a better idea to use a smart implementation. These arguments over Smart vs Dumb can become as religious as TCP vs ISO or Intel vs. Motorola. It is best to look at what you want to accomplish and make your choice based on your own environment. Brad Kemp Interlan, Inc. {ulowell,mit-eddie}!interlan!brad brad@interlan.UUCP