[comp.protocols.misc] TCP/IP vis Netware.

latzko@zydeco.rutgers.edu (Alexander Latzko) (10/17/88)

Well,

Having some netware and a large amount to IP around here ( Rutgers U )
has lead me to some astonishing conclusions:

1> Boards which do TCP on board are generally a waste of time and
effort.  The two which I have handy to gripe at are the EX205T and the
UB PCNIU.  

2> The Micom/Interlan Gateway lists for $3995 and has performance
limitations.  You also probably don't want to use it in anything
smaller than a 386.

3> Packet drivers are available and work well.  Basically this will
let you use your favorite TCP and Novell on the same workstation 
with a much less expensive card since the software does the work.
Several companies sell this but as far as I can tell the bottom line
is everyone is buying the TCP from FTP Inc.  This is the path I have
chosen here for our Netware networks which might want to speak IP.

The ethernet card we use here it the Micom NI5210-8 although Western
Digital told me to expect theirs before the end of 88 for the WD
EtherCard Plus.

cheers
/S*

As always please send comments and barbs to 
latzko@rutgers.edu
{backbone}!rutgers!latzko

PS.  Standard Disclaimer...  I neither work for nor receive payment
from Interlan, WD or FTP INC.  Micom Interlan FTP Inc Excelan WD
and Ungermann Bass are trademarks probably owned by someone

dannyb@kulcs.uucp (Danny Backx) (10/19/88)

In article <Oct.16.15.09.26.1988.269@zydeco.rutgers.edu> latzko@zydeco.rutgers.edu (Alexander Latzko) writes:
>Having some netware and a large amount to IP around here ( Rutgers U )
>has lead me to some astonishing conclusions:
>
>1> Boards which do TCP on board are generally a waste of time and
>2> The Micom/Interlan Gateway lists for $3995 and has performance
>limitations.  You also probably don't want to use it in anything
>smaller than a 386.
>3> Packet drivers are available and work well.  Basically this will
>let you use your favorite TCP and Novell on the same workstation 
>with a much less expensive card since the software does the work.

Could you provide us with some explanation of these statements?

Especially (1) seems to be the direct opposite of what everybody claims: that
the host OS can be relieved of a lot of work with TCP on a board.

	Danny Backx
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Danny Backx                            |  mail: Danny Backx
 Tel: +32 16 200656 x 3544              |        Katholieke Universiteit Leuven 
 Fax: +32 16 205308                     |        Dept. Computer Science
 E-mail: dannyb@kulcs.UUCP              |        Celestijnenlaan 200 A
         ... mcvax!prlb2!kulcs!dannyb   |        B-3030 Leuven
         dannyb@blekul60.BITNET         |        Belgium     

latzko@zydeco.rutgers.edu (Alexander Latzko) (10/22/88)

In article <132@icarus.kulcs.uucp> dannyb@kulcs.uucp (Danny Backx) writes:

> In article <Oct.16.15.09.26.1988.269@zydeco.rutgers.edu> latzko@zydeco.rutgers.edu (Alexander Latzko) writes:
> >Having some netware and a large amount to IP around here ( Rutgers U )
> >has lead me to some astonishing conclusions:
> >
> >1> Boards which do TCP on board are generally a waste of time and
> >2> The Micom/Interlan Gateway lists for $3995 and has performance
> >limitations.  You also probably don't want to use it in anything
> >smaller than a 386.
> >3> Packet drivers are available and work well.  Basically this will
> >let you use your favorite TCP and Novell on the same workstation 
> >with a much less expensive card since the software does the work.
> 
> Could you provide us with some explanation of these statements?
> 
> Especially (1) seems to be the direct opposite of what everybody claims: that
> the host OS can be relieved of a lot of work with TCP on a board.

1> I realize I shouldn't generalize but occasionally it looks safe in
context.  It depends on what the host processor is and what the
processor on the card is.  If the host processor is a 386 and the
processor on the card is a 186 or a slow 286 then under DOS ( which is
where these comments are pointed ) it will indeed slow the system
down.  Moreover, the implementations of TCP I have seen for the
embedded cards haven't been nearly as good as for dumb cards.

Under a true multitasking operating system which knows how to block io
they can be a win.  Novell is a multitasking OS and I will admit to
using Micom NP600A cards in 286 servers.

2> The Micom/Interlan gateway does indeed list for US$3995.  It is
limited in the number of IP connections it can maintain.  The last
time I looked to would only handle 24 connections.  In a fairly large
network this is simply not enough.  The last time I saw one in action
it was chewing up over 10% of the cpu on a compaq 386/16 for 4
telnets.  Unfortunatly, I didn't get a chance to see if that was a
constant. I suspect Larry Backman of Interlan will come breating down
my neck if I am too far off the mark.  I expect it will get better as
time goes on ( it has improved remarkably in the last year and
development continues ) so I would like to be proven wrong.  For
someone who had an installed base of some random network interconnect
and won't be heavy IP users it is the only solution.

3> Packet drivers are low level device drivers which pass information
to more than one active job.  Simply put you load the device driver as
you normally would.  Then instead of only talking to IP or IGX it
speaks to both.  Nifty, eh what.   The list of companies which have
packet drivers is much longer than I may have implied, here are all
the ones I know of: Micom/Interlan, Sytek, Western Digital,Proteon, 
BICC,and Torus.

>  Danny Backx                            |  mail: Danny Backx
>  E-mail: dannyb@kulcs.UUCP              |        Celestijnenlaan 200 A

cheers
/S*

ron@ron.rutgers.edu (Ron Natalie) (10/23/88)

1.  It's a crime to put $1000 of networking hardware in a $2000 PC.

2.  If the OS is MS/DOS, then it isn't multitasking anyway and the
    286 on the CPU board isn't likely to be running while you're
    using the 286 on the interface card.

3.  When you buy a generic dumb card you can get software and updates
    from any number of places.  For example, I know of two public domain
    and at least four commercial TCP products for PC's.  None of these
    supports any of the smart cards (they would not be big sellers).
    I've got two different smart cards (Excelan and UB).  Neither are
    terribly useful because they're software is so out of date.  I can
    go out and buy stuff for any of the dumb cards that works 100% better.

-Ron

backman@interlan.UUCP (Larry Backman) (10/27/88)

In article <Oct.21.13.38.50.1988.528@zydeco.rutgers.edu> latzko@zydeco.rutgers.edu (Alexander Latzko) writes:
>> >1> Boards which do TCP on board are generally a waste of time and
>> >2> The Micom/Interlan Gateway lists for $3995 and has performance
>> >limitations.  You also probably don't want to use it in anything
>> >smaller than a 386.
>
>
>2> The Micom/Interlan gateway does indeed list for US$3995.  It is
>limited in the number of IP connections it can maintain.  The last
>time I looked to would only handle 24 connections.  In a fairly large
>network this is simply not enough.  The last time I saw one in action
>it was chewing up over 10% of the cpu on a compaq 386/16 for 4
>telnets.  Unfortunatly, I didn't get a chance to see if that was a
>constant. I suspect Larry Backman of Interlan will come breating down
>my neck if I am too far off the mark.  I expect it will get better as


	[]

	Hpoe I'm not breathing too hard...  However, we argue the smart board
	dumb board, gateway question a lot here; so. a few points to ponder..

	
	1.  Generally speaking, a smart board can match an 8 or 10 MHz. AT
	     in performance.  Our smart board as well as others can actually
	     out-perform an equivilent speed AT running the same code.  Why?
	     The smart board has some sort of communication oriented OS that
	     is dedicated to two things, responding to host requests, and
	     picking packets off of the wire.  This OS does not have to deal
	     with keyboards, screens, disks, etc..

	2.   Smart boards save host memory.  This is a big win in DOS-land;
	     not so important in UNIX, OS/2, and other protected mode OS's.

	3.   Smart boards cost more, and have memory which cannot be used
	     outside of communications.

	4.   Dumb boards and host based protocols clearly out-perform the
	     same protocol on a smmart board as soon as tou move into 
	     the 80386 family.  I have an ISO-NETBIOS protocol stack that
	     runs in both DOS and OS/2 on both smart and dumb boards.
	     On a 386-16 the host based protocol stack is 70% faster than
	     the board based protocol stack, on a 386-20 it was 120% faster;
	     I have not measured a 386-25 yet.  

	5.   Gateways are not for everyone.  They do a lousy job of serving
	     heavy TCP user's.  On the other hand, they do a great job of
	     serving the casual TCP access most PC user's seem to need.
	     No, a gateway will not help 20 users who wish to spend 80%
	     of the time doing keyboard intensive TELNET apps.  It will
	     help a workgroup of 30 or 40 users who do casual TELNET, FTP,
	     and SMTP access, casual being defined as less than 33% TCP
	     usage.

	6.   A well-designed gateway provides minimal disruption of the
	     host CPU.  I believe that the CPU usage you saw with 4 TELNET's
	     would be duplicated by those 4 Novell workstations doing any
	     sort of continous file server access using IPX.  Gateway's
	     (and for that matter, all intelligent boards) are nice in
	     that they remove the Ethernet receive function from the host.
             All those broadcasts that IP drops, all those keepalives
	     that TCP drops never make it up to the host.  A dumb board,
	     with a host based protocol stack, can swamp even the fastest
	     host, provided the network has a lot of traffic.

	This argument is fun, its one of those religious wars that has no
	correct answer.  Another good one (next time) is the correct hardware
	architecture needed to do fastt protocols.



					Larry Backman
					Interlan, Inc.
	

brad@interlan.UUCP (Brad Kemp) (10/27/88)

	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