Content-transfer-encoding: 7BIT
Newsgroups: bit.listserv.banyan-l
Date:         Mon, 9 Nov 1992 16:02:21 ADS
From:         Ian.Brabham@CC.MONASH.EDU.AU
Subject:      Banyan versus Novell

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 *****

Date:          03 Nov 1992 15:01:16 -0800 (PST)
From:          Richard Warner <rick@SJSUMCS.SJSU.EDU>
Subject:       RE: Banyan versus Novell
Reply-to:      Novell LAN Interest Group <NOVELL@SUVM.SYR.EDU>

>> I have a user who is trying to decide whether to go Banyan or Novell.
>> This university has both network operating systems.  The only campus-wide
>> standard is TCP/IP.
>> I use Netware but hear that Banyan is good.
>> I used to recommend Netware for its Mac support but understand Banyan does
>> that now.   My question is why should a user pick Netware over Banyan?

>Why pick one over the other?  Really, your University, as a whole should
>probably try to standardize on one over the other. There economies of
>efficiency and scale by simplifying things.

This assumes either Banyan or Novell can offer everything a large University
needs.  Banyan could if they stopped pissing on their third party vendors,
they claim they have changed there attitudes and recently they seem to be
really cooperating with the world.  Novell could if they get away from there
"small network" mindset, maybe rev 4 will be a step in the right direction,
but I don't see how they will be able to integrate successfully with their
existing product and not be hamstrung by the existing designs.  So do we
now end up with a choice of Old Netware, Vines and New Netware.

>Anyway, Banyan's strong suit is its naming protocol, StreetTalk.  But
>that advantage may be short-lived, as Netware 4.0 will have a
>somewhat similar naming protocol.  StreetTalk is mainly an advantage
>if you have a lot of servers; it simplifies administration.

StreetTalk is really just the distributed name space directory management
service.  There is more to the Vines advantage than just a distributed
global naming system, it is more to do with a network design that implements
the concept of a "Service" logically independant from the server that hosts
it.  This is what makes global administration possible, it is an advantage
even with only 2 servers.  It basically allows any number of servers to be
a single network.  Like most advanced ideas there is responsibility in the
physical implementation, performance can be poor when setup the wrong way
or functionality can be incredibly flexible with good performance.

>Some Banyan-ites say it makes it easier for the user, but in my experience
>that is not true; the users get frustated with these long, 3-part
>StreetTalk names.

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.

>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.

>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.

>        and the performance degradation curve was exponential - so ....

Vines degradation curve in most cases is better described as knee shaped.
If the server is configured correctly for a given load then it will
perform very well upto that load.  When you exceed the resources of the
hardware then things can get slow quite quickly.  Netware servers also
tend to suffer from this phenomenon.

>                                              - so expect it to die
>at about 50-60 simultaneous users on one server.

It is hardly appropriate to make wild statements that Vines will choke at 50
to 60 users, a 25Mhz 386 with 8 meg and a slow disk very probably would.  A
big Compac SMP with 64 meg and a large IDA drive array could cope with well
over 400 users.

>Banyan plays a very proprietary game.  You will find that there are very
>few add-ons from 3rd parties - Banyan supplies them, and they charge
>dearly.  They are, admittedly, nicely integrated, but the financial hit
>is big.

Banyan have always aimed to provide a complete homogeneous network
operating environment and they didn't leave many niches for 3rd parties
to fill.  Netware more or less really only provided a network transport
service, a file system and print deflection, this left lots of gaps for
3rd party developers, Novell may have made the better marketing desision.
Things are changing so rapidly with both Banyan and Novell that the above
comments are almost out of date more or less as I write.

>          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!

>                              Novell has traditionally supplied support
>for older versions when new hardware comes along; Banyan usually will add
>it to the next release, and make you upgrade to get it.  For example,
>3Com's new, fast 16-bit Ethernet adapter, the 3C509; Banyan will supply
>drivers only for Version 5.x and above.  Those of us with versions 4.x
>(4.10 is 15 months old, 4.11 less than a year old) will need to upgrade
>to a new version of the NOS if we want to put 3c509 cards on our LAN's.
>Novell support for the 3c509 can be extended back to 2.15 (even 2.10 if
>you dare) and 3.0 - versions that are several years old now.

This is a very valid point.  Banyan have cut there throat very badly in
the past by refusing to provide the information to allow 3rd parties to
write drivers for Vines servers and clients.  They are again considering
the question of releasing a drivers development kit but the question is
still deeply steeped in internal politics.  3Com wrote the Netware drivers
for the 3C509, Novell only certified them.  Ultimatly the question of
client drivers may pass everyone by with the move towards Packet Drivers,
NDIS and ODI generic interface specification.

>Both companies need to work on tech support.  I do not like either,
>but there is a lot more unofficial support for Novell.

I have found both official and unofficial support for both to be on a
very even par (offical is poor, unofficial is good).

>Oh - and one thing I absolutely hate about Banyan is that it is
>copy-protected.  It uses a hardware key form of copy protection - and
>the keys sometimes go south.  When that happens, you are SOL until
>your VAR can wedge a replacement out of Banyan - which can take
>days!  Ironically, the keys usually go bad when you are adding new
>features - features that you paid $$$$$$$$ for, and the stinking
>copy protection scheme makes those $$$$$$$$ and all the others you
>have paid worthless for then next n days.  [you can tell I have
>been whacked by this demon one too many times].

Banyan are marketing the SCO version of Vines without the parallel port
connected key protection.  They are switching to a scheme very similar to
the one now used by Digital where you type in numbers from a licence card.
Hopefully PC based Vines will follow suit soon.

>+-----------------------+-------------------------------------+
>|   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!               |
>+-------------------------------------------------------------+

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