Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!iuvax!ux1.cso.uiuc.edu!tank!cps3xx!eecae!netnews.upenn.edu!eniac.seas.upenn.edu!jeff
From: jeff@eniac.seas.upenn.edu (Jeffrey M White)
Newsgroups: comp.sys.mac
Subject: Re: Quantum ROM fix report
Message-ID: <17524@netnews.upenn.edu>
Date: 30 Nov 89 21:50:04 GMT
References: <14618@well.UUCP> <9323@batcomputer.tn.cornell.edu> <20837@mimsy.umd.edu> <27801@dhw68k.cts.com> <32331@auc.UUCP> <89334.141000ALE101@PSUVM.BITNET>
Sender: news@netnews.upenn.edu
Reply-To: jeff@eniac.seas.upenn.edu.UUCP (Jeffrey M White)
Organization: University of Pennsylvania
Lines: 26

In article <89334.141000ALE101@PSUVM.BITNET> ALE101@PSUVM.BITNET (Allen Edmiston) writes:
>In article <32331@auc.UUCP>, rar@auc.UUCP (Rodney Ricks) says:
>><  Oddly enough, the problem does seem to have "fixed itself" after approx.
>><1 month of hyperactive, rattling, performance-degrading accesses on my IIcx.
>>
>>I wonder if it would be a good idea for users who just got the fix to just
>>let the system sit for a few days and "exercise" itself to get rid of the
>>performance problem?
>><-ken
>>Rodney
>

  My impression of this ROM fix was that it would exercise the heads when
they would otherwise sit idle, but once a transfer was requested the drive
would behave as usual (I believe a lot of larger drives sort of run 
continuous diagnostic exercises like this).  Unless the exercise was 
CONSTANTLY being run and interfering (more like interleaving) with the
transfer, I don't understand why throughput should be lower now.
  As far as having the drive "exercise" itself and get rid of the problem,
I would think the exercise would always be run.  I doubt they added a real
time clock chip and counter to the drive, so that after so many hours
of operation, it wouldn't do the tests anymore.

					Jeff White
					University of Pennsylvania
					jeff@eniac.seas.upenn.edu