Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!lll-tis!ames!rutgers!mtune!whuts!homxb!ihnp4!alberta!auvax!rwa
From: rwa@auvax.UUCP (Ross Alexander)
Newsgroups: comp.sys.atari.st
Subject: Re: SH204 hard disk
Message-ID: <507@auvax.UUCP>
Date: 25 Jan 88 00:29:07 GMT
References: <2697@dadla.TEK.COM>
Organization: Athabasca U., Alberta, Canada
Lines: 58
Summary: he's absolutely right

Jim's article <2697@dadla.TEK.COM> is absolutely correct.  Why *is* there
no CHKDSK.TTP or whatever?  Lord knows there are enough known bugs in the
filesystem that a correction-and-defragmenting utility ought to be standard
issue with any SH product.  I have worked around this by doing entire dumps
(via TURTLE) of the SH204 to many, many floppies and then reformatting,
building new partitions, testing, and restoring.  This is tedious at best
and error-prone & dangerous at worst.  I do it Sunday afternoons (like
today).

Jim is also right about relative filesystem performance.  Any
ibm-clone XT-class machine in the building can beat my ST/SH in
general filecopy performance.  Good grief, 1024 Kbytes of RAM to play
with and they don't even cache the FATs much less the directories, or
attempt read-ahead or any of the other tricks that (even with the
brain-damaged toy MSDOS filesystem) could easily be done to improve
performace.  The hardware is certainly quick enough.  As an example,
when I run my machine under the Magic Sac mac-emulation system, I
notice a considerable improvement; the hard disk performance
approachs TOS ramdisk speeds.

My interim solution has been to logically separate my files into two
groups; files which are essentially static and read-only (executables
and resource files, libraries, standard #include stuff, documentation
and the like) and files which are mutable and/or ephemeral (source,
mail, databases, pictures, any work in progress) and assign them to
different partitions.  

The mostly-read-only partition is loaded in the order of expected usage
frequency (i.e., \bin first, then \include and \lib, then \doc and so on)
and can be allowed to become moderately full (say 75%).  The read-write
partition holds \src and whatever else you have, and shouldn't get more
than 30% to 50% full.  In either case, small partitions are a speed win.
I always go with 4 x 5 megs for simplicity.

The final thing is to assign a RAM partition for really ephemeral stuff,
like compiler temporaries, .obj's, and suchlike objects.

Even with all this planning, the XT's still beat my ST.  Are you listening,
Neil?  Your people are crying out for help ;-).

BTW, here's my bench:  compile microemacs 3.9e from scratch. times:

	17 mins 32 secs with c:\{bin,lib,include}, d:\src, m:\tmp
	13 mins 25 secs with everything on m:\ (ramdisk).

( MWC 2.1.7, stock 1040STf or ST-4, stock SH204, in mono mode,
no acc's; in both cases, the command was 'make clean; time make' )

Who's got PC/XT times for this?  It's a good test from my
perspective; lots of compute, lots of reading, a fair bit of writing.
And its the kind of job load that I often offer this machine.  

> At least the 68000 computes faster...:->

But this is getting to be cold comfort :-< !

--
Ross Alexander, Sr. Systems Programmer & Bottlewasher @ Athabasca University
alberta!auvax!rwa