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