Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!dali.cs.montana.edu!caen!news.cs.indiana.edu!ux1.cso.uiuc.edu!midway!clout!chinet!les
From: les@chinet.chi.il.us (Leslie Mikesell)
Newsgroups: comp.dcom.lans
Subject: Re: UN*X ffs vs. OS/2 hpfs for file server
Message-ID: <1991Jun18.145432.23646@chinet.chi.il.us>
Date: 18 Jun 91 14:54:32 GMT
References: <1991Jun11.175144.24736@cfctech.cfc.com> <PCG.91Jun14183441@aberdb.aber.ac.uk>
Organization: Chinet - Chicago Public Access UNIX
Lines: 78

In article <PCG.91Jun14183441@aberdb.aber.ac.uk> pcg@aber.ac.uk (Piercarlo Grandi) writes:

>norm> Right now we have a IBM PS/2 Model 95 (33MHz 486) running OS/2 1.3 EE
>norm> and Lan Manager 2.0 with a 3Com MC/32 (3C527) ethernet card.
>norm> There are those that suggest that we should try comparing this to an
>norm> AT&T Star Server E running UNIX SVR4.0.2.1 and their StarGroup software
>norm> version 3.4b, using a berkely fast file system partition.

>I would like to oberve that maybe using either machine as a file server
>is a bit funny; both machine can run one or two dozens users in
>timesharing, without any problems.

I can't comment on the original question, but I would like to disagree
with most of your premises.

>Using a high speed machine with
>high speed disks is wasted as a file server; in practice file service is
>neither CPU bound nor IO bound, but network bound.

I've only rarely seen this on a 1M starlan network, I doubt if it would
be true on the 10M ethernet or 16M token ring net that you would be
likely to install with a 486 server.

>If you have a mainframe class machine (a 486@33 MHZ with suitable disks
>is definitely mainframe class, running at 20MIPS and being capable of
>running several GB of disk at several megabytes per second aggregate
>thruput) you can just do a timesharing system. If the "mainframe" is
>[34]86 based, you can easily run DOS under Unix on it (VP/IX, MERGE).

The 386 machines I use don't manage several megabytes/second through the
unix file system, but maybe that will improve with SysVr4.  Vp/ix is
not a general solution for multi-user dos access because it don't present
a network interface for network-aware programs and it typically consumes
about 10x the CPU of a file server handling a PC.

>Networks of PC with a file server only make sense for economic reasons,
>when you want to centralize your disk space to take advantage of
>economies of scale, and any suitably slow machine will do.

This is just not true.  The real reasons for PC networks are:
  (A) Dos programs can do everything a typical office user needs, and
      many have no affordable unix equivalent.  If you work with outside
      resources (and who doesn't) the odds are about 100 times better    
      that their programs and media are dos instead of your particular
      version of unix.  If your people travel with laptops, they have
      to be able to copy everything off to them.
  (B) It doesn't make any sense to have office users spend time installing
      their own software or making backups.  Nor should they be able
      to accidentally erase or modify the installed programs and data
      files that make the office work.
  (C) Everybody needs to be able to share data.

The economy of sharing disk space and resources like printers is really
trivial compared to centralizing the machine management duties. (University
people with cheap student labor may disagree...).

>After all,
>think, most PC based networks cannot physically transmit more than
>1MB/sec. (or something of that order of magnitude) of data between all
>stations. Having a server than can provide an aggregate thruput of more
>than 1MB/sec. is entirely pointless, and any modern (16Mhz) 286 AT with
>some decent ESDI or SCSI disk controller and a couple of disks will do.

Yes, if all you do is read and write from a few large files.  In practice,
that's not the case.  In a fair sized network you will have people making
and breaking connections all the time, the file server will provide
security functions and file and record locking with some associated overhead.
Most DOS programs these days provide internal directory reading functions
which may involve a great deal of overhead for the server to process.
Also, the server may be simultaneously handling many other functions like
mail transfers, gateways to mainframes, fax boards, and logged in users.
The server may also allow direct program execution with i/o piped to and
from the client.  The ability to perform these other functions transparently
along with the file services should be considered when choosing the server
platform.

Les Mikesell
  les@chinet.chi.il.us