Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!husc6!bloom-beacon!think!ames!ucla-cs!zen!ucbvax!ucdavis!uop!exodus
From: exodus@uop.UUCP (Greg Onufer)
Newsgroups: comp.sys.atari.st
Subject: Disk R/W times for large files
Message-ID: <383@uop.UUCP>
Date: Sun, 5-Jul-87 03:42:12 EDT
Article-I.D.: uop.383
Posted: Sun Jul  5 03:42:12 1987
Date-Received: Sun, 5-Jul-87 21:01:20 EDT
Organization: University of the Pacific, Stockton, CA
Lines: 56

Anybody care to explain what's wrong here?

I used GULAM's timing function to time misc. file copies onto several
formats of disk.  The tables should explain:

***** 505338 Byte file from near-empty HD partition to Floppy *****

Formatter   Fast/Slow   Tracks  Sec/Trk   # of 5-ms 'ticks'
===============================================================
DCFORMAT     FAST         82      9            7407
DCFORMAT     SLOW         82      9            7408
DCFORMAT     SLOW         80      9            7429
DCFORMAT     FAST         80      10           7640
DCFORMAT     FAST         82      10           7726
TWISTER      FAST         82      9?           8284

***** Same file from each disk to the same near-empty partition *****
	(File on HD deleted each time, and saved and deleted prior
	 to any timing)

Formatter   Fast/Slow   Tracks  Sec/Trk   # of 5-ms 'ticks'
===============================================================
DCFORMAT     FAST         82      9            7117
DCFORMAT     SLOW         82      9            7117
DCFORMAT     SLOW         80      9            7159
DCFORMAT     FAST         80      10           7355
DCFORMAT     FAST         82      10           7392
TWISTER      FAST         82      9?           7392

***** Same file from floppies to 580K RamDisk *****
	(Same conditions as above, file removed after
	 each copy, obviously)

Formatter   Fast/Slow   Tracks  Sec/Trk   # of 5-ms 'ticks'
===============================================================
DCFORMAT     SLOW         80      9            6784
DCFORMAT     FAST         82      9            7082
DCFORMAT     SLOW         82      9            7083
DCFORMAT     FAST         82      10           7399
TWISTER      FAST         82      9?           7478
DCFORMAT     FAST         80      10           7640


I wasn't overly scientific about this, and a file this large probably
brings into play some of GEMDOS's faults.  But it's slightly more
realistic this way.  There are serious flaws in some of these sector
skewing formats when these types of results are produced.  I may try
using DCFORMAT to 'copy' these disks and record the read times for an
entire diskette.  I assume that DCFORMAT's Slow/80/9 is the same as a
what is produced by the desktop formatter?


Greg Onufer (exodus)    1040ST        | Mail: University of the Pacific
GEnie: G.ONUFER         No less!      | UTH c21, Stockton, CA 95211
UUCP: ...!{lll-crg,ucbvax}!ucdavis!uop!exodus 49-6221-76.18.42 (Home-Germany) 
      ...!{ptsfa!cogent,cepu!retix}!uop!exodus  (209) 474-1795 (College-Un th