Article View: comp.sys.atari.st
Article #27461Disk R/W times for large files
From: Greg Onufer
Date: Sun, 05 Jul 1987 07:42
Date: Sun, 05 Jul 1987 07:42
56 lines
3131 bytes
3131 bytes
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
Technical Details
Message-ID:
<383@uop.UUCP>Path:
arc1-ca.pugleaf.net!utzoo!mnetor!seismo!columbia!rutgers!husc6!bloom-beacon!think!ames!ucla-cs!zen!ucbvax!ucdavis!uop!exodusShow Full Headers
Complete Article Headers
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: arc1-ca.pugleaf.net!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