NetNews Usenet Archive 1992 #26/NN_1992_26.iso/spool/comp/unix/large/364

Internet Message Format | 1992-11-10 | 12.0 KB

Xref: sparky comp.unix.large:364 mi.misc:727
Newsgroups: comp.unix.large,mi.misc
Path: sparky!uunet!destroyer!cs.ubc.ca!newsserver.sfu.ca!sfu.ca!vanepp
From: [e-mail] (Peter Van Epp)
Subject: Re: LISA VI paper availible via anon ftp
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: Simon Fraser University, Burnaby, B.C., Canada
References: <[e-mail]> <[e-mail]>
Date: Tue, 10 Nov 1992 16:09:00 GMT
Lines: 198

[e-mail] (Steve Simmons) writes:

>[ I've taken the liberty of re-crossposting this to comp.unix.large,
>  where Peter hangs out.  Peter, feel free to correct me or add
>  your own comments.  mi.misc is the Michigan general discussion
>  group.  Neither Ed nor Peter says this explicitly -- the mainframe
>  they dropped was running MTS in a usage model very much like the
>  University of Michigan.  --scs ]

>[e-mail] (Edward Vielmetti) writes:

>>The folks at Simon Fraser University have managed to
>>get themselves out of using MTS and onto other computing
>>systems (Unix and VMS) without an undue amount of grief.
>>I know that there's a lot of angst building up at the
>>U of Michigan about the same sort of transition, and in
>>the absence of strong central planning here's at least some
>>hint of what some other organization facing the same
>>move has gone through.

    I would note that this summer both Durham and Newcastle (both
also MTS sites) have converted to Unix (I assume successfully!).
The same ftp site has a paper from the MTS community workshop last year
at RPI that covers more of the MTS specifics of the converstion (and an
FS tape utility) as well. The workshop this year is at SFU, so the UM
folks can come over and see how we did (and how we didn't :-) ) as well.
    Remember that all the MTS sites (SFU probably less than most of
the others due to people leaving) have a very important resource for
conversions like this: very skilled people. The skills needed to architect
and write and maintain a mainframe operating system (i.e. MTS) transfer
easily to the Unix environment. The major problem that we found (and are
still finding) is a lack of understanding of performance issues at high
loads (but to be fair, for political reasons "mainframe like" Unix boxes
were a no no here) among at least the Unix vendors that we talked to. UM
also has a signifigant amount of Unix expertese (Peter Honeyman comes to
mind as the most obvious example, but there are lots of other skilled folks
that have been at various MTS workshops as well). In return for that though,
UM is a lot bigger than SFU, and some of the issues that we managed to slid
through (a common uid space for the whole campus for instance) will be
more difficult at UM, a lot more demand (at least I expect) for things like
3480 and 3420 tape support.
    I'll note here that things seem to be looking up on the Unix front
(and if you have a big sequent or HP, maybe they have always looked up :-) ),
machines with reasonable sounding I/O are coming. I borrowed a SCSI 3480
tape drive that I know is capable of streaming (or big VAX has two and it
can make them stream!), and couldn't get any Unix box we have to make it
stream. The drive data starves (just like when you give it a small block size
from MTS and the buffer empties and it loses stream), and as a result it was
slower than a single density 8mm drive (instead of the 1 megabyte/ sec that
it is capable of). It sounds like some of the new Unix boxes should have
decent I/O rates, and make at least 3480 type tapes accessable (not cheap,
but at least accessable).

>>[ Article crossposted from comp.unix.large,comp.org.usenix ]
>>[ Author was [e-mail] ]
>>[ Peter Van Epp / Operations and Technical Support ]
>>[ Posted on Mon, 9 Nov 1992 20:36:30 GMT ]

>>I have just made a copy of our LISA VI paper "Dropping The Mainframe
>>Without Crushing The Users: Mainframe to Distributed UNIX in Nine Months"
>>availible for anon ftp from ftpserver.sfu.ca in directory
>>/pub/ucspapers/LISA-VI.paper.ps.Z
>>(which as the file name implies is in PostScript).

>Peter's paper and talk were quite interesting.  He did stress a few
>points in the talk that are worth repeating.

>There was not an overall reduction in cost when you count many of the
>conversion costs.  It was not clear to me how much was conversion (new
>network stuff, etc) and how much was CPU and disk.  IMHO, the cost
>benefit will probably improve over time as distributed UNIX boxes
>continue to decline in cost.  For a site like University of Michigan,
>much of that conversion wouldn't be needed -- they already have the
>network, AFS, etc.

I should point out that the lack of overall cost reduction is my opinion,
and includes the cost of installing the fibre based network over the last
5 or 6 years. Around here, that is not taken into account, and the Unix
conversion is considered "much cheaper" than the mainframe solution. I
will point out that this only considers the machines in the central
machine room, not the various labs of PCs that were installed to take some
of the load off of the mainframe over the years (and at several hundred
thousand each, are a signifigant chunk of money). We are just installing a
public lab of 40 NeXT stations that also don't get counted in to the costs
(at least so is my impression!). I include all those costs when saying that
the Unix conversion was more expensive (note that I believe it was worth it,
just that "cost reduction" probably isn't an issue if we are being honest).
    I completely agree that Unix boxes are cheap and getting cheaper, the
problem (here and elsewhere, listening to the other LISA participents) is
not hardware, but people. In my opinion, there has been a net reduction in
service to the community as a result of this conversion. We have gone from
maintaining "one" (there are actually three of them, 2 of which are still here
for the admin side) machine to maintianing the 16 Unix boxes that have replaced
it (to say nothing of the new NeXT lab) of 4 different architectures on the
same number of people. That has been lost (again in my opinion) is the level
of service to the community. Several people that used to be user consultants
have been conscripted to be Unix support people, simply to keep up with the
work, and provate workstations on campus have been deserted due to lack of
staff time. There is certainly demand out in the community for many more
people to support distributed Unix on the desktop, the only thing lacking
is money to pay for them (and I expect the salaries will make IBM maintance
look cheap!).

>There was *very* strong central control.  Last year at LISA he
>mentioned the project had just been started, and they had some doubts
>about their ability to execute.  Fortunately for him, he was wrong.
>The central control got behind the project and pushed with resources
>and political support to get it done.

The central control is a series of committees of academics that set computing
policy, and (I will admit that this part suprised me, and I think all of us)
they have done an excellant job. I believe they also got a very eye opening
education in the costs and economics of computing along the way.
    The resources used are (and as far as I am aware only!) the operating
money that was funding the mainframe (which is part of the reason for the
speed of the conversion, since while the mainframe was still here, the same
money was being spent twice).
    There is no question that from the political side, there was strong
(and politically irresistable) support, since the push was coming from
members of the academic community, not the computing center! This was a major
win for the committee structure (that and the seriousness that the committees
brought to the task of educating themselves on computing, since many of them
are not proffessional computing people, nor even Computing Science people).

>Many MTS utilities were not ported to the UNIX environment.  I asked
>specificly about MICRO and we talked briefly about a few others.  They
>seem to have adopted a policy that if there was already a UNIX
>equivelent, conversion would have to be done.

Other than an FS tape conversion utility, no MTS specific utilities were
ported. Spires applications went to a package called BRS, and everything
else was either dropped or converted to an off the shelf Unix solution.
A small number (less than 10) of people continued their work (if it was
going to end soon) on the MTS system at UBC. This turned out to be a much
smaller number than we expected.

>Some users just couldn't get it.  They had people claiming not to know
>the change was coming even after the mainframe was turned off.

They knew, they just didn't believe it would happen, with good reason. MTS
came to SFU to replace OS/MVT, MTS is gone, OS/MVT is now scheduled to be
shut down next April, given that would you have believed that MTS would
actually be gone in the 9 months that management claimed? We suprised a
lot of people (including ourselves!).

>Tapes were a big issue.  They found the unix tape facilities woefully
>underpowered.  Lack of ability to read IBM formatted tapes was a big
>lose (they've got years and years of backup and archives), and tape
>thruput speed left a lot to be desired.

>Mainframe I/O speed was a big issue.  They had a small number of people
>who put huge (by mainframe standards!) datasets onto 250
>inch-per-second tape drives and did data processing.  There is no UNIX
>box on their site which can do this; such processing is now farmed
>out.

Not even that good, in some cases the data sets spin on disk, in some cases
I don't know what the people do. We have an optical juke box that is supposed
to help with this (20 gigs of space) but it isn't online yet. Even when it
is, it is not going to give the same I/O performance as an IBM tape connected
to an IBM channel. The common method of work on MTS was mount three or four
tapes, and use the tape as the input to the processing going on in the CPU,
I expect that the optical juke performance isn't going to replace that function.
It looks more like, pull some of your data down to temp disk, process it, and
then put that part back to the juke and do another piece (but we don't know
yet).

>One thing that came out stronger in his talk was "the mainframe
>attitude".  I don't know how to put it any better than that, and it's
>meant as a compliment.  They did serious work evaluating, benchmarking,
>and testing performance of the various pieces they installed, much more
>thorough than I see at most installations.  Then they tested afterwards
>to see what they'd actually done.  Very refreshing, almost inspiring.
>--

Also very hard and not very successful, since the basic performance measurement
tools that we take for granted on mainframes seem to be totally lacking on
Unix boxes (or at least the ones that we have), or we haven't found the Unix
equivelent yet (which is also possible).
    The general (and possibly wrong!) impression I get of typical Unix
shops is that they don't tend to be of the "bet the business" type of
seriousness that a large commercial DP shop is. I came here from an airline
where the reservations system was considered so vital, that there was a spare
$4 million mainframe (and 2 of everything else involved as well) just in case
something broke, so I may be a bit biased shall we say :-).
    A good case in point, is backup tapes, I see many sites using Sony
video tape, because it is $10 instead of the $20 a certified data tape is,
but you may be risking $100,000 of data (on your backup tapes) to save $10.
How many other Unix sites duplicate their weekly full backup tapes and move
them offsite in case of disaster (or tape breakage for that matter?), both
standard mainframe/commercial shop practices that are being done on Unix here.
    I was talking to someone I know at the local telephone company, whose
background is the same as mine, and we were shaking our heads over the
practices that he found on Unix boxes that were helping to run the telephone
network, so I don't think the impression is necessarily wrong.

Peter Van Epp / Operations and Technical Support
Simon Fraser University, Burnaby, B.C. Canada