X-Mailer: ELM [version 2.3 PL11]
Newsgroups: bit.listserv.banyan-l
Date:         Mon, 9 Nov 1992 08:00:37 PST
From:         "(Richard Warner)" <rick@SJSUMCS.SJSU.EDU>
Subject:      Re: Banyan versus Novell
              "Brabham.MONASH.EDU.AU@VM1.CC.UAKRON.EDU" at Nov 9, 92 4:02 pm

> Dear all,
>
> An associate asked for my comments on this so just to keep everybody up
> to date on what the Novell@suvm list is doing I am also forwarding this
> here for your amusement/amazement.
>
> Regards Ian
>
>
> *****  ATTACHMENT: reply.txt *****
>
> As with any namespace management if it is not thoughtfully layed out then
> it can be a real pig to use.  We use effectivly 2 part ST names, the 3rd
> part alway being "@Monash" is redundant.  Our layout is not to bad but
> there is room for improvments.  Most users once they discover the pattern
> cannot believe how crippled other schemes really are.

For most students, even computer literate ones, e:\apps\bcpp is bad enough,
"BCPP@APPS" if worse, and the more normal Banyan-ite
"Borland C++@Applications@MathCS" is ridiculous.  Couple that with the
lack of a reasonable method for adding to the path, e.g., the
Novell MAP INS S1:= construct, and StreetTalk is a royal pain in the
butt for most users.

> >Banyan's greatest weakness is StreetTalk.  It is a performance hog.
>
> Generally StreetTalk access within a local group is on a par with Netware
> bindary access.  When a group is remote you suddenly replace very fast
> processor memory accesses with slow ethernet accesses, this is not a
> performance hog, the server can process many other requests while a remote
> request is being deflected, but it can dramatically effect response time
> for an individual when it happens inappropriatly.  If Novell have done
> rev 4 properly this will become a new variable Netware 4.0 administrators
> may have to come to terms with.

Absolutely false.  Every review that has ever been done has shown that there
is a very large overhead to StreetTalk, and the overhead is geometrically
proportional to the largest group that resides on a given server.  There
is no case in which StreetTalk overhead and Novell bindery overhead are
even remotely comparable.

> >InfoWorld's review of VINES 5.0 (the Banyan product that can take
> >a Mac add-on) found that VINES performance (throughput) was 1/3 that
> >of a similar Netware 3.11 network with 24 simultaneous users,
>
> The default tuning parameters Banyan set for Vines are frequently not
> very appropriate.  This is almost certain for ultimate load testing.
> Infoworld admit everytime they test Vines that they have limited Vines
> experience and they do rely on these defaults or hotline suggestions
> when they are in trouble.  I would normally expect such a wide descrepency
> with similar hardware platforms to be caused by some external influence,
> bug or some gross misconfiguration error.  Because a Vines server can do
> more for you than simple file and print sharing it generally requires
> a little more memory than Netware to achieve the same ultimate performance.
> Novell have entered this areana with all the NLM that now can be loaded
> to add functionality.  I have seen a 3.11 Netware server perform so badly
> just because that administrator was an NLM junkie, the poor software had
> no memory left to do useful work.

Banyan assisted InfoWorld in tuning the server.  There was still a 3X
difference with 24 users - a very lightly loaded server.

> >          Banyan also has a nasty habit of making you upgrade to a new
> >version to get new features.
>
> I cannot think of any vendor (software of other) who does not do this, it
> is a commercial reality if you give things away you go broke.  Richard is
> confusing, maybe validly, new hardware support with new features.  Can you
> get file level trustees or use the 32 bit instructions of a 486 processor
> in 286 Netware?  No!

What about Source Routing support.  Novell supplied it with 2.15C, but
made the parts available so that anyone with 2.1x could add it.  Banyan
required an upgrade to get it.  What about Windows client support;
Novell supplied it for every version later than 2.10, even though it
came out when 2.15C was shipping.  Banyan required an upgrade to 4.10
(and did not provide it until >2 years after Windows 3.0 came out).  Same
with OS/2 support.  Banyan requires an upgrade for every new little piece
of software/hardware that is released!  If I want OS/2 2.0 support I
will need to do YAU - Yet Another Upgrade.

> Ian Brabham                 email: ian.brabham@monash.edu.au
> Micro Support Group         phone: +61 3 565 4742
> Monash University           fax:   +61 3 565 4746
> Melbourne Australia
>

+-----------------------+-------------------------------------+
|   Richard M. Warner   |   Internet:  rick@sjsumcs.sjsu.edu  |
|                       | CompuServe:  71121,2257             |
+-----------------------+-------------------------------------+
|  ** DISCLAIMER:  All opinions are strictly my own.  I work  |
|                  hard enough at forming them!               |
+-------------------------------------------------------------+