mrr@amanpt1.zone1.com (Mark Rinfret) (06/18/88)
I just installed a Seagate ST-251 (40 MB) drive in my PAL Jr. expansion box (Remember it? I bought it just before Byte-by-Byte stopped making them, also just before I found out my Ami 1000 was obsolete.) Well, the PAL Jr. has performed very well with the original MicroScience 20 MB drive, but I found myself spending too much time rolling things on/off floppy disks. Thus the ST-251 ($335 from The Computer Terminal + $33.50 lifetime warranty). The "problem" I'm about to describe is essentially a perceived substantial increase in seek activity. I say "perceived" since I have no measurements to back up my claim. However, last night I did observe a phenomenon much like David Childs (right name?) observed with his system. While restoring files to the hard disk, large files seemed to create a very intense period of seek activity. During the copy of one file (mg2a, to be exact - about 97K bytes), my system appeared to lock up. Workbench windows were held in suspension (no icons appeared). Once the copy completed, everything went back to normal. Each time I invoke a disk-resident command, there is a long (.25 - .5 seconds) period of seek activity with a very distinct "audio" pattern to it (I think you know what I mean - the mechanical noises emanating from the disk have a recognizable/repeating pattern). Here's an attempt (somewhat silly, I agree) to recreate it in text: ---burst1---|---burst2-----------|----bumpetybumpetybumpetybumpety---| The above representation is not drawn to scale :-). Burst 1 is quite short and has a sort of "low frequency" characteristic. Burst 2 is about twice as long as burst 1 and has a higher frequency characteristic. Each of these sounds like the head is jumping back and forth between the same two tracks, a little like machine gun fire. The "bumpeties" at the end of the sequence sound like random thrashing. This is all followed by the loading of the application which proceeds in what I would characterize as "normal" disk activity. Subsequent invocations of the same program do exhibit lessened amounts of disk activity (apparently due to caching a la AddBuffers). I did a "Path Reset" and invoked commands known to be in my C: directory to see if it was a result of directory scanning - no change. I also tried explicit pathname invocation (e.g. bin/mg) - no change. ....Technical details.... The disk came with a data sheet with test results and a list of eight bad blocks: HD CYL MFM BFI HITS 0 22 8771 8 2 760 8089 8 3 33 8710 40 3 699 1755 30 4 426 9249 8 4 627 2094 21 5 659 4222 38 5 660 4220 33 I've included the bad block list info in case anyone might spot a collision with trackdisk specific requirements (where are the root block and bitmap blocks on this disk?). I did the low-level format, specifying 820 cylinders, 6 surfaces, 1:1 interleave and head parking zone at cylinder 821. Nothing unusual occurred during the (very long) formatting process. This was done with a program supplied by Byte-by-Byte, named "hdtest". Indeed, the blocks described as bad showed up as bad during the formatting and test run. Oh yeah - I did map out the bad blocks. There was a tense moment when I re-booted and the system complained that it couldn't find DH0:. I didn't panic, however. Instead I RTFM (past tense) and was reminded to do the high level format. I knew that :-)! Everything went fine after that, with the exception of the "condition" I am describing. If you're still reading, thanks for being patient. If you've had similar experiences and have either an explanation or a solution, please share your discoveries with me. You don't have to be a PAL Jr. owner (hell - I'd never hear from anybody!). Is there a disk activity monitoring tool I can use to "watch" disk accesses and determine the reason for this possibly strange behavior? I'm not too concerned with data reliability at this point, but if I've done something obviously wrong, I'd like to undo it before I commit large quantities of development stuff to this new disk. The thought of going through another backup/restore cycle is depressing (gotta' rewrite MRBackup!!! :-). Thanks in advance, Mark -- < Mark R. Rinfret, mrr@amanpt1.ZONE1.COM | ...rayssd!galaxia!amanpt1!mrr > < AMA / HyperView Systems Home: 401-846-7639 > < 28 Jacome Way Work: 401-849-9930 x301 > < Middletown, RI 02840 "If I just had a little more time...">
papa@pollux.usc.edu (Marco Papa) (06/21/88)
In article <476@amanpt1.zone1.com| mrr@amanpt1.zone1.com (Mark Rinfret) writes: |I just installed a Seagate ST-251 (40 MB) drive in my PAL Jr. expansion box |(Remember it? I bought it just before Byte-by-Byte stopped making them, also |I did the low-level format, specifying 820 cylinders, 6 surfaces, 1:1 |interleave and head parking zone at cylinder 821. Nothing unusual occurred ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |during the (very long) formatting process. This was done with a program |supplied by Byte-by-Byte, named "hdtest". Indeed, the blocks described as |bad showed up as bad during the formatting and test run. Oh yeah - I did |map out the bad blocks. The Seagate ST-251 AUTOMATICALLY parks the heads at power down. If one uses the "prep" program that comes with the CBM A2090 HD controller and selects the "programmed" parking after inactivity, one gets "unuasual seek activity" plus random lock ups. I don't know what the program supplied by Byte-by-Byte does, but it probably performs similarly. Try to select a "NO HEAD PARK" option if available and reformat. -- Marco Papa 'Doc' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= uucp:...!pollux!papa BIX:papa ARPAnet:pollux!papa@oberon.usc.edu "There's Alpha, Beta, Gamma and Diga!" -- Leo Schwab [quoting Rick Unland] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
arnie@tikal.Teltone.COM (Arnold Koster) (06/21/88)
In a previous article > I just installed a Seagate ST-251 (40 MB) drive in my PAL Jr. expansion box > (Remember it? I bought it just before Byte-by-Byte stopped making them, also Remember the PAL sr. ? > The "problem" I'm about to describe is essentially a perceived substantial > increase in seek activity. I say "perceived" since I have no measurements > Each time I invoke a disk-resident command, there is a long (.25 - .5 seconds) > period of seek activity with a very distinct "audio" pattern to it (I think > during the (very long) formatting process. This was done with a program > supplied by Byte-by-Byte, named "hdtest". Indeed, the blocks described as > If you're still reading, thanks for being patient. If you've had similar Anything about the PAL/PAL Jr. I read. > discoveries with me. You don't have to be a PAL Jr. owner (hell - I'd never > hear from anybody!). Is there a disk activity monitoring tool I can use to You'll have to settle for a PAL Sr owner. I have a PAL expansion box with the same HD controller as in the PAL JR. It was one of the first 24 built (maybe the only 24 built :-) ) and has performed flawlessly for almost 2 years. However I did experience a similar problem with the Seagate ST-225 drives on mine. If you have a version of the disk driver that parks the heads after a few seconds of inactivity, disable it. Parking the heads requires that the driver seek from the parking track to the desired location. According to Murphy this will always be the opposite end of the disk thus requiring a long seek. It is the sound of this seek that you hear. I found that by NOT parking the heads on my drives the problem went away. In addition get a copy of the driver and utility software supplied with the Commodore 2090 controller. (i.e. hddisk v33 rev 18 and Prep ). Use hddisk for the driver and Prep to prepare the drive. The 2090 and the Byte by Byte controller seem to be identical in design ( if someone knows the full story I'd like to hear it ) with the exception of the SCSI interface which is only complete on the 2090. Using hddisk fixes a bug in using overscan screens and also appears to be somewhat faster than the supplied driver. I have been using this combination since last fall with no problems at all. Of course if your driver does not park the heads this is all food for the bit bucket :-) Hope this helps - now if I can only get the SCSI port to work :-) and autoboot hacked in for 1.3 :-) > Thanks in advance > Mark Your Welcome Ken Koster (N7IPB) algedi!kenk@pilchuck.Data-IO.COM or 12653 NE 95th ...uunet!pilchuck!algedi!kenk or Kirkland,Wa 98033 ...uw-beaver!tikal!pilchuck!algedi!kenk Mine all Mine. Hee Hee :-) :-) Amiga,1.5meg,40megHD,UUPC