hmm@exunido.UUCP (09/21/86)
Our experience has been that the best way to use the harddisk for compiling is: 1. partitioning it into 4 partitions first. This way creating files takes not too much time. 2. using a ramdisk for every temporary file. This speeds up a lot ! However, the whole slowness of the GEMDOS filesystem handling is a pain in the *** ! Maybe the following would help: Implement a track buffer for reading. Useful for floppies only, I think. But it would help considerably. Do some write-behind if possible. It gets a bit complicated, and I don't know if it would fit into the bios well. !! Beat those bugs out of GEMDOS !! The slowness of file creation is a real bug. As far as I know the file system layout, it should not depend on the filling grade of the partition. When you watch the activity light on the harddisk during file creation you see that there is something realy weird going on. Hans-Martin Mosner (hmm@unido.uucp, hmm@unido.bitnet)
slavenbg@prle2.UUCP (Gert Slavenburg) (09/22/86)
References:
Sender:
Reply-To: slavenbg@prle2.UUCP (Gert Slavenburg and Joost Janse)
Followup-To:
Distribution:
Organization: Philips Research Laboratories Eindhoven
Keywords: SH204 HARDDISK
We recently aquired the European SH204. Since we found several problems
with the previous prototype harddisk, we were eager to compare them :
- The noise level seems to be down by a factor of two (subjective).
Where the prototype produced a steady hum, the commercial SH204
produces mostly fan-noise, which to us is much less distracting.
- The cablelength is now 60 cm, which allows placing the drive next
to the ST with the indicator light facing towards you.
- Partitioning of up to 4 partitions (max. 16 M per partition) is now
possible.
- The major problem with the prototype is the slow speed of writing on
a substantantially filled hard disk. This problem appears NOT solved
in the commercial SH204.
The measurements below show that overhead on file writing depends
on the usage of a partition. For a partition containing 7.5 MByte,
allocation for an empty file takes approx. 7 seconds ! (on a floppy,
this takes 4 seconds.....)
Copying time for 4 folders totalling 55 items (1.5 MByte)
from harddisk into another partition (of size 10M) :
destination partition empty : 2:06 minutes
destination 1.5 M filled : 3:27
destination 3.0 M filled : 4:38
destination 4.5 M filled : 5:52
destination 6.0 M filled : 7:03
With the partition containing 7.5 M, writing an empty file takes
approx 7 seconds and a 32kByte file 7.5 seconds. Writing the same
file on floppy takes 10.5 seconds.
The above measurements were done using a AHDI.PRG version 1.4 (dyer).
As long as this problem is not fixed, you should consider if this is
a device you want :
File reading and program loading is fast.
Applications allocating many small files (compilers...) run slow,
sometimes slower than a floppy drive.braner@batcomputer.TN.CORNELL.EDU (braner) (09/22/86)
[] 7 seconds to write an empty file????? To repeat: It takes about 15 seconds to compile and link a typical C program (and handle all those intermediate files, of course) with Megamax C on a... RAM DISK!! BTW: Partitions??? Why would you want THAT? (assuming you are the sole user of the machine, as it should be) Can you have 10 (20, 30, 40) Megs in ONE partition? Will Atari ever fix the %$@#&@ 40-directory limit (and the other bugs in GEM/TOS)? - Moshe Braner "One user, at least one CPU!" (let's see: one in my watch, one in my modem, one in the printer, 2 (or 3?) in the ST (not counting the ACIAs, MFP...)...)
Lynn%PANDA@SUMEX-AIM.STANFORD.EDU (Lynn Gold) (09/25/86)
The reason you'd want to partition your hard disk is that GEMDOS has problems with a disk size larger than I-forget-what. Perhaps if Landon Dyer is reading this, he could give more exact details. --Lynn -------
dclemans@mntgfx.UUCP (Dave Clemans) (09/25/86)
The ST hard disk format is that same as used on MS-DOS 2.X systems, and has its same limitations. In particular that's where 32MB size limit per disk partition comes from. The only way to make it bigger would be to increase the number of sectors per cluster, which may or may not work under GEMDOS. (And it would depend on whether or not the driver would understand logical sector numbers that didn't fit in a 16-bit word). The code to create/delete files in GEMDOS is particularly slow (probably because of seeking back and forth between the FAT and where the data is being written much more than it should). This is the reason for the recommendation that partitions have a maximum size of around 10MB. dgc