X-Mailer: ELM [version 2.3 PL11]
Newsgroups: bit.listserv.cdromlan
Date:         Fri, 14 Aug 1992 08:04:41 CDT
              <CDROMLAN@IDBSU.BITNET>
From:         David Robinson <robinson@KNUTH.MTSU.EDU>
Subject:      Re: Networked access to muliple CD-ROMs
X-To:         uunet!pucc.PRINCETON.EDU!CDROMLAN%IDBSU.BitNet@uunet.UU.NET
              10, 92 7:37 pm

>Now, the databases we want to use are multiple-disk products, and there
>are a few of them, for a total of about 12-14 disks (for now). So, my question
>is, what experiences/recommendations/etc. have you for mounting multiple
>disks on a network. As I see it, there are 3 possible scenarios:
>
>	- some type of jukebox affair.
>	- multiple CD-ROM drives on the server
>	- multiple hard disk drives, with CD-ROM data copied to the hard drives.
>
>The jukebox solution would likely be the cheapest, and for that reason is the
>one that I would like to pursue. However, is the performance any good? I would
>think that there would be significant delays involved in changing disks, and
>if multiple users were flogging it, there would be serious contention. Have
>these problems perhaps been addressed already with some kind of caching
>arrangement?

We have one of those Pioneer DRM-600s.  We currently have it mounted on
a standalone workstation rather than on our LAN. This may change in the
future, but for now we're leaving it off the network.  You're correct in
your supposition about delays changing disks. In our experience, it is
S*L*O*W.  The Pioneer consists of 1 laser, and a 6-disk cartridge.
Every time you need to change disks, the Pioneer has to unload one disk
in the cartridge and load another one.  This cycle takes about 8 to 10
seconds.  It's slow during bootup 'cause the Future Domain SCSI
controller insists on looking at every disk in the cartridge (it's
looking at every configured drive ... D: through I:) as part of the
startup routine.  It's also slow executing with some applications, such
as SilverPlatter or ProQuest, 'cause those applications look at every
available disk in the cartridge as part of *their* startup routines.
Subjectively, this seems to add 90 seconds or more to the startup time
for these applications.

As an example: with SilverPlatter, you can select multiple ERIC
disks and search them simultaneously.  On the Pioneer, every search
requires that all the selected ERIC disks be cycled in and out in
order to complete the search.  Consequently, a search that takes maybe
10 seconds on our CDROM LAN with individual drives, can take over a
minute on the standalone workstation with the Pioneer drive.

Imagine what would happen if two workstations on your LAN requested two
different disks on the Pioneer changer.  The changer would have to load
one disk, search it, unload it, and load the next disk.  By this time,
the first workstation is ready to display, so the changer has to reload
the first disk and display the results of the search. By now, say, a 3rd
workstation wants yet another disk, the changer has to load the 3rd
disk, the 2nd workstation wants to display the results of its search,
the 1st workstation is requesting the 1st disk again... and you have a
10 second lag time between each action.  You can go out for coffee while
waiting for your job to finish up.  I think someone once called this
'thrashing'.

I really don't think you'll be happy trying to put one of those Pioneer
changers on your LAN unless you can confine it to some relatively seldom
used databases like maybe the GPO Census disks, or Dissertation
Abstracts.  For databases like those, that are very large (spanning
multiple disks) and seldom used, (here anyway) that might not present many
contention problems, the Pioneer may be an effective way to save some
money.  Used in combination with single drives for more heavily used
databases you might be able to get away with using the Pioneer.

>The multiple CD approach seems to be quite common, from the little bit of
>research I have done. But it is more expensive, as would be the third approach.
>(Some colleagues have expressed concern that one drive per CD is a bit of
>overkill. :-) )

IMO, on your LAN where you potentially have many users hitting on the
same disk at the same time, one drive devoted to that database is *not*
overkill.  Overkill, to me, is going out and buying a 650 Mb hard drive
to copy the contents of that perfectly good CD onto.  Sure the searcher
is going to get faster response time, but imagine having 14 650 Mb
drives, or even 7 1Gig drives hung off your LAN... (boy, I wish I
*could* imagine that !!! :-)  While you're at it, imagine how long it'd
take copying all that data from the CDs to the hard drives... now imagine
doing it every month.

Oh, well, that's just my opinion, anyway.  Your mileage may vary.


>|--- Jonathan Moore  ------------------|--  Voice:  (306) 966 5295 --------|
>|    College of Engineering            |    FAX:    (306) 966 8710         |
>|    University of Saskatchewan        |    Email:  moorej@dvinci.USask.CA |
>|___ Saskatoon, Canada  S7N 0W0________|____Office: 2A23.1 Eng. Bldg.______|
>


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 David Robinson                         |   robinson@mtsu.edu
 Automation Librarian                   |   615/898-2572 (voice)
 Middle Tennessee State University      |   615/898-5551 (FAX)
 Murfreesboro, Tennessee 37132          |   P.O. Box 13  (snail)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
"A well-schooled electorate, being necessary to the security of a free
State, the right of the people to keep and read Books, shall not be
infringed.'                                    -- J Neil Schulman
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU