Content-transfer-encoding: 7BIT
Newsgroups: bit.listserv.banyan-l
Date:         Tue, 10 Nov 1992 18:13:06 ADS
From:         Ian.Brabham@CC.MONASH.EDU.AU
Subject:      re: Banyan versus Novell

Dear all,

>> As with any namespace management if it is not thoughtfully layed out then
>> it can be a real pig to use.
>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.

My my what a totally twisted and crippled way of viewing the world.  This
must be a real pig to use.  None of our users, Banyan or Novell, ever need to
know a streettalk name or server/volume name (apart from their own account
name).  Much less the Dos pathname to an application.  They can use them if
they wish but we provide batch files, default paths and default names so a
users need never see all the nasty mechanics of how things really work.

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

The MAP INS S1:= construct would have to be one of the most confusing and
time wasting constructs anybody ever half implemented.  The number of times
people, who should know better, try to use this from a spawned Command.Com and
get so totally confused and befuddled I can just not believe.  There are at
least half a dozen public domain path manipulating programs available, all
of which do an infinitly less butcherous job than MAP INS does.  MAP INS
appears to be a nifty concept but it just encourages the weak minded to make
an even bigger mess.

Besides what has MAP INS got to do with StreetTalk.  StreetTalk has nothing
to do with Dos paths.

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

Richard I am starting to suspect you really don't have any idea what
StreetTalk really is or how Vines services use it.  StreetTalk like the
Novell bindary is just a simple database, you feed them a key (ST name or
property ID) and they return you some data simple as that.  It is really
quite efficient at doing that.

Ever seen what happens to SYSCON when you put 2000 usernames into the
Bindary I have had tried it and it is not a pleasent sight.  To be fair
MUSER was not to flash when asked to select the whole 2000 but at least
you could ask for a subset.  There is definitly no geometric degradation
in StreetTalk performance with large groups it is in fact very close to
the ideal n*log(n) rule.

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

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

I sort of doubt this, maybe someone from Banyan Technical support has
some comments on the subject.  I live in Australia and haven't seen the
InfoWorld review so for all I know we are comparing apples to grapefruit.

>>>          Banyan also has a nasty habit of making you upgrade to a new
>>>version to get new features.

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

>+-----------------------+-------------------------------------+
>|   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@banyan.cc.monash.edu.au
Micro Support Group         phone: +61 3 565 4742
Monash University           fax:   +61 3 565 4746
Melbourne Australia

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