Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ll-xn!ames!pioneer!lamaster From: lamaster@pioneer.arpa (Hugh LaMaster) Newsgroups: comp.dcom.lans Subject: Re: Smart Ethernet boards Message-ID: <2318@ames.arpa> Date: Wed, 8-Jul-87 12:35:13 EDT Article-I.D.: ames.2318 Posted: Wed Jul 8 12:35:13 1987 Date-Received: Sat, 11-Jul-87 06:49:08 EDT References: <283@sering.cwi.nl> <8212@utzoo.UUCP> <8255@utzoo.UUCP> <2302@ames.arpa> <146@eagle_snax.UUCP> Sender: usenet@ames.arpa Reply-To: lamaster@ames.UUCP (Hugh LaMaster) Organization: NASA Ames Research Center, Moffett Field, Calif. Lines: 50 In article <146@eagle_snax.UUCP> geoff@eagle_snax.UUCP ( R.H. coast near the top) writes: >not forget that for the average PC DOS client the metric we care >about is not CPU load but response time. In the case of telnet, everything > >While it's appropriate to focus on TCP, we shouldn't ignore UDP-based >services like NFS : a smart-board version of PC-NFS working with downloaded >protocols would be _significantly_ slower than the dumb board version. > >Distinguish also between the theoretical and the here-and-now. All of the >current smart cards use 80186 or (slow) 68000 processors. This is >a sufficiently price-sensitive area that it would be difficult to >market a really powerful design except for server applications. >Meanwhile almost all AT class CPUs are significantly faster >than the smart card processor. In the PC arena, I find nothing to disagree with here. Smart cards only make sense, in general (there is always an exception), on multi-user and/or multitasking systems. I didn't previously discuss ftp performance, but Excelan also has data showing that, naturally, a faster CPU with a dumb controller outperforms their board on an unloaded system, but that on a loaded system there is a significant performance advantage with a smart card. Now, there are a lot of complications here, so I would not make a blanket statement (a previous posting from Pyramid discusses some kernel mods that can change the situation), but there are fewer interrupts for the CPU to process, fewer context switches necessary, and better "scheduling" performance available to the on-board TCP/IP, which give it better performance above and beyond the result expected by looking only at available CPU cycles. So, while there is no doubt that a faster main CPU with a dumb controller will provide better "server" performance, the on-board implementation can be significantly better on a loaded multiuser system. 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")