Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!boingo.med.jhu.edu!haven!ni.umd.edu!sayshell.umd.edu!louie
From: louie@sayshell.umd.edu (Louis A. Mamakos)
Newsgroups: comp.sys.next
Subject: Re: Spotted Workspace ? Why? (and BlastApp??)
Keywords: memory errors, non-parity memory, spotted display
Message-ID: <1991Apr5.170240.13210@ni.umd.edu>
Date: 5 Apr 91 17:02:40 GMT
References: <5596@media-lab.MEDIA.MIT.EDU> <1991Apr3.230504.27819@mp.cs.niu.edu> <1991Apr5.075135.23325@cs.ubc.ca>
Sender: usenet@ni.umd.edu (USENET News System)
Organization: University of Maryland, College Park
Lines: 47
Nntp-Posting-Host: sayshell.umd.edu

In article <1991Apr5.075135.23325@cs.ubc.ca> sritchie@cs.ubc.ca (Stuart Ritchie) writes:

>Personally, I would like to see NeXT offload networking support
>to a dedicated CPU.  Protocol performance inside the Unix kernel
>is relatively poor (that's an understatement) compared to more
>special purpose implementations.

I disagree with this comment.  Can you cite any references or examples
to support this?  I have not found the performance of UNIX kernel
based TCP/IP to be an issue.

>Just like their special purpose Mach and DPS implementation on
>the i860, one could see a lightweight Mach and x-kernel running
>TCP/IP on an 88000 based board.  Hell, even a 68020 would probably
>be better than sucking cycles from the 040 at each Ethernet
>interrupt.

Of course, then you have to worry about how to move the data to and from the
special purpose "network" processor to where the UNIX kernel can get at
it, and shove it into and out of socket buffers, etc.

Look real hard at what tcp_input() does in the most common case for
bulk data transfers; its not that many instructions.  The great pile
'o code that's in there is for the (relatively) unusual case where
packets get dropped, retransmissions, out of order segments, etc.  If
your network traffic begins to operate in that regime much of the
time, you can probably forget about performance and worry about what's
wrong with your network.

>If NeXT did this, I would be really impressed.  Finally our machines
>could reach Ethernet speeds!

>Out-on-limb-statement:  Dedicated multiprocessors are the way to go.
>Of course, a few 040's for general application use would also help :-)

I agree that having multiprocessors would be a good thing; I just
don't think that dedicating one for network stuff (or any other thing,
for that matter) will be any better than what you have right now.  If
you're interested in raw network performance, wouldn't you rather have
a 68040 doing the protocol processing (which really isn't that
intensive in most cases) rather than having a slower processor do part
of the work, and then having to give it to the faster processor?

Witness the utter failure of "intelligent" ethernet cards in the PC marketplace
as compared to "dumb" ethernet cards.  The performance win just isn't there.

louie