shulman@topaz.UUCP (04/27/86)
Delphi Mac Digest Sunday, 27 Apr 1986 Volume 2 : Issue 16
Today's Topics:
68000 Assembly Language Tools
RE: 68000 Assembly Language Tools (Re: Msg 7402)
RE: 68000 Assembly Language Tools (Re: Msg 7403)
RE: 68000 Assembly Language Tools (Re: Msg 7402)
RE: 68000 Assembly Language Tools (Re: Msg 7402)
'HOT' Tip!!!
Lightspeed C
TWO hard disks on Mac+
RE: Volumes 0.5 (Re: Msg 6735)
Interleave/DiskBench
Watch out for DataPak Software
Where's Sierra Info. Systems?
Re: Hyperdrive Removal request
RE: Open Mac rumors cont'd (Re: Msg 7570)
MDS and Lightspeed C
Dollars & $ense
Is Mac Really Naked?
MS Word HELP!!!!
----------------------------------------------------------------------
From: GBL (7402)
Subject: 68000 Assembly Language Tools
Date: 17-APR 23:02 Developer's Corner
I'm just finishing up a book on Mac assembly language. I thought I'd include an
appendix on "Invaluable Development Tools" or something like that. I'd like to
include references to the most useful commercial and shareware utilities like
Fedit, ConCode, etc.
I'd like to hear comments on what you feel are the best utilities for a 68000
programmer to have at hand.
Thank you.
------------------------------
From: PEABO (7403)
Subject: RE: 68000 Assembly Language Tools (Re: Msg 7402)
Date: 17-APR 23:40 Developer's Corner
MacsBug (from Apple) or TMON (from ICOM simulations, a commercial product) are
a necessity for debugging.
I'll also plug a public domain product of my own, TextDiff, which is
available in the Tools topic of the database here. Over the years I
have come to depend of a good utility to compare successive versions
of source code for what changes took place, and that's what TextDiff
does. Currently in beta test, but there will a another version out in
a little while with bug fixes and some nifty new features.
peter
------------------------------
From: RICFORD (7406)
Subject: RE: 68000 Assembly Language Tools (Re: Msg 7403)
Date: 18-APR 00:43 Developer's Corner
I assume you've already included ResEdit and other Apple utilities. Other... is
important for testing DA's, and I'd suggest a modem and Red Ryder as important
development tools...
Ric
------------------------------
From: LOFTUSBECKER (7407)
Subject: RE: 68000 Assembly Language Tools (Re: Msg 7402)
Date: 18-APR 07:43 Developer's Corner
1. MDSMake (Shebanow).
2. BaseTool (32-bit hex/decimal/octal/binary converter)
3. TMON (debugger).
------------------------------
From: JIMH (7411)
Subject: RE: 68000 Assembly Language Tools (Re: Msg 7402)
Date: 18-APR 19:07 Developer's Corner
The best single tool for assembly language programming is TMON. The best tool
to learn how to program in 68k ASM is MacNosy as theres no teacher like
examples. jim
------------------------------
From: MACINTOUCH (7408)
Subject: 'HOT' Tip!!!
Date: 18-APR 17:02 Business Mac
I got a great piece of info today which confirms a previous rumor that I posted
here....
dBASE III+ will be out for the Macintosh in the last
quarter of this year. My source at Ashton-Tate didn't
know whether the programs would be compatable between
the IBM and Mac but he assumed that the data would be.
Josh Wachs - MacInTouch
------------------------------
From: ASMCOR (7415)
Subject: Lightspeed C
Date: 19-APR 00:30 Programming
All: Been playing with LightSpeed C, here are my first impressions:
I have been working in Megamax for a good year now, and I've been quite happy
with it, but LightSpeed is really going to spoil me... it's very easy to work
in. I have a little application than I am using as a test bed for the List
Manager routines, to get them all working right so I can use them. It took me a
couple of full evenings, I would guesstimate approximately 10 hours to get the
thing running in Megamax. I wrote all the glue routines in assembly, and it
took about 6 of those hours. Tonight, inside of three hours I was able to
convert the entire LIST application from Megamax to LightSpeed, and get it
running. And that *includes* re-writing all the glue routines for Lightspeed,
which doesn't support inline assembly. I used the little trick posted here
yesterday of declaring something like:
pascal Boolean Pack0() = 0xA9E7;
and using that to create the inline traps. Works great.
The turnaround in Lightspeed is very fast, and the error messages are
much clearer than Megamax. It also only gives you one error message at
a time, so it's less confusing, and it's more accurate at flagging the
line where the error actually occurs. Interestingly, the LIST
application was 8930 bytes in Megamax, and 9744 in Lightspeed. About
10% larger, but that may be because it's linking in more than it has
to. I think the difference would be less in a more fully-fleshed
application. Still, it is significant. Jan
------------------------------
From: JIMWEINRICH (7431)
Subject: TWO hard disks on Mac+
Date: 19-APR 14:34 Hardware & Peripherals
Is it possible to put TWO hard disks onto a Mac+ in the following config: One
SCSI disk on the SCSI port; one old-style Mac hard disk on the serial port? If
so, is it also possible to put the imagewriter onto the back of the old style
disk (assuming of course the proper disk)? Thanks guys!
------------------------------
From: MACLAIRD (7450)
Subject: RE: Volumes 0.5 (Re: Msg 6735)
Date: 20-APR 17:54 MUGS Online
As an addendum to my earlier Forum message about Volumes:
I reported a problem running MDS from a remote host over the AppleBus.
After applying patches to allow use of System 3.1.1, the applications
(Exec, Link, and PackSyms) began to work with Volumes 0.5 as well.
These patches are described in the introductory notes to the "December 1985
Software Supplement Additions". See the heading "MDS (Macintosh 68000
Development System) Update"; it's on the first page.
One other difference was that I ran Volumes and MDS from a 5 megabyte
ProFile not shared with Lisa software. I can't see how this should
make a difference. Now, PackMacs.Txt has SFGetFile as an EQU. Can
anyone explain how I can write a SFGetFile macro without completely
revising PackMacs.Txt?
------------------------------
From: BRECHER (7507)
Subject: Interleave/DiskBench
Date: 22-APR 10:19 MUGS Online
Which Interleave is best?
-------------------------
Recently John Bass pointed out that 1:1 interleaving is sometimes
disadvantageous due to the frequency of logically-contiguous
single-sector requests. He estimated that interleaving of
approximately 6:1 would be optimal for handling such requests. I
tested that estimate by modifying DiskBench to issue 64 single-sector
requests on increasing sector addresses, in place of each prior 32KB
request. I ran this "SSDiskBench", as well as the original DiskBench,
on a MicahDrive at various interleaves; results were as follows (read
and write results were in all cases identical or nearly so, so I show
here only the read results):
Interleave SSDiskBench DiskBench
1:1 6801 507
2:1 7206 812
3:1 7511 1116
4:1 7518 1523
5:1 6513 1827
6:1 2538 2233
7:1 2538 2537
8:1 2943 2943
These results clearly confirm Bass's "about 6:1" estimate for optimal
handling of consecutive single-sector requests. However, Bass claimed
that this is also the best system interleave -- i.e., that assuming
that all requests are single-sector is appropriate. This is not to
say that Bass claims that ALL requests actually are single-sector --
just that such requests are so relatively frequent that the best
interleave is one which accommodates them.
I gathered some statistics on the distribution of disk I/O requests by
writing a hook into _Read and _Write which records the size of each
request and the the sector (logical block) distance from the end of
the previous request to the start of the current request. I invoked
this recorder, and then performed the following activities on a 512K
Mac, 128K ROMs, System 3.2b3, Finder 5.2, big TMON loaded, MicahDrive
HFS volume about 9MB full, starting in Finder with the disk directory
window open:
Open folder; double-click MacWrite document; change document, quit
with save; close folder; open folder; double-click MacPaint document;
change document; quit with save; duplicate (Finder copy) 22K document;
close folder; open folder; open MDS Asm; use SFGetFile to select
document (go up, down, down in directory hierarchy); assemble;
transfer directly to Consulair Link 1.5; Link; quit to Finder; close
folder; open folder; double-click Excel worksheet document; change
worksheet; quit with save; close folder.
Size of disk read/write requests, 512-byte sectors:
Number of sectors Number of requests Sectors transferred (%)
1 1785 1785 (49%)
2 16 32
3 16 48
4 6 24
5 23 115
6 8 48
7 3 21
8 22 176
9 4 36
10 2 20
13 1 13
14 9 126
16 1 16
17 2 34
18 2 36
23 1 23
24 1 24
25 1 25
43 1 43
44 3 152
48 1 48
49 1 49
61 1 61
63 4 252 ( 7%)
70 1 70 ( 2%)
374 (Excel PCOD resource) 1 374 (10%)
---- ----
1916 total requests 3651 total sectors
Sector distance between chronologically consecutive requests (end of
request N-1 to start of request N; 0 means requests are physically
contiguous):
Sector distance Number of requests
0 1060
1 20
2 13
3 14
4 5
5 8
negative or 6 or more 796
----
1916 total requests
Clearly, consecutive single-sector requests predominate. However,
this is not sufficient to establish the best interleave. Consider:
for each consecutive single-sector request in a series, a 1:1 drive
takes about one disk revolution, and a 6:1 drive takes about one-third
of a revolution. For a single 374-sector request, a 6:1 drive takes
about 124 revolutions; a 1:1 drive, about 21 revolutions. Hence, in
terms of relative advantage, a single 374-sector request balances a
series of about 154 single-sector requests. These calculations are
back-of-the envelope; the exact magnitude of the results is not the
issue. The point is that a few big requests at 1:1 interleave can
offset the advantage of many contiguous single-sector requests at 6:1
interleave.
So, whether 1:1 or 6:1/7:1 is better from the standpoint of getting the user
home quicker depends on the user's job mix. To find out what kind of
activities favor interleaving or lack thereof, I wrote another _Read/_Write
hook. Here, if the request started in the same cylinder in which the previous
request ended, and if there were five or fewer intervening logical sectors,
the relative advantage of 6:1 vs. 1:1 interleave was calculated and
cumulated. And, the relative disadvantage of 6:1 in terms of sectors passing
under the heads during actual data transfer was calculated and cumulated.
The following is a general summary of the net winner by activity:
Activity Winner
All launches--
(MacWrite, MacPaint, Excel, MDS Asm, Consulair Link) 1:1
Finder copies 1:1
MDS Assembly 1:1
Consulair Link 6:1
Opening/Saving Write/Paint documents 6:1
I presume that any backup program will do multi-sector requests, and therefore
would run faster with 1:1.
In general, if the user does a lot of document opening/saving, then
the 6:1 or so interleave is better. If he does a lot of
launching/quitting (launching Finder), file copying, etc., then 1:1 is
better. It should be noted, though, that with a "normal" mix of
activities the perceived difference will not be great. I've been
running the MicahDrive at 7:1 for a couple of days (previously 1:1);
the perceived throughput is not noticeably different. I clocked a few
different activities at both interleaves, and the difference was
typically a few percent one way or the other.
DiskBench
---------
DiskBench has been aptly criticized for not being a realistic measure
of normal user I/O patterns. (To which I have previously responded
that it was a quick hack that was never advertised as realistic.) In
light of the foregoing data, I'd like to make clear (especially to
non-technical readers) that the DiskBench data transfer tests measure
only performance on large multi-sector I/O requests, and that in "real
life" such requests comprise only about 20% or so of the total data
that goes back and forth between the Mac and the disk. Hence,
DiskBench data transfer results are not necessarily representative of
relative performance in real use. FOR WHAT THEY ARE WORTH, here is
the last set of results I will publish:
The read data transfer test consists of 100 reads of 32KB from the beginning of
the volume; the write data transfer test consists of 100 writes of 32KB to the
beginning of the volume. The access time test consists of 40 repetitions of:
read 512 bytes from an offset of 1MB into the volume; read 512 bytes from the
beginning of the volume.
Results on only one specimen should be regarded as provisional.
Data transfer Access Tester
---- time ---- time
Reads Writes
400K floppy drive, Apple 8756 11816 N/A S. Brecher
400K floppy drive, Apple N/A 12392 N/A G. Frascadore
400K floppy drive, Apple 8796 11629 N/A C. Nicolais
400K floppy drive, Apple N/A 12351 N/A R. Perez
800K floppy drive, SS, Apple 8758 11407 N/A S. Brecher
800K floppy drive, SS, Apple 6842 11462 N/A D. Etchells
800K floppy drive, SS, Apple 7544 11550 N/A C. Nicolais
800K floppy drive, DS, Apple 7701 10874 N/A S. Brecher
800K floppy drive, DS, Apple 7523 10913 N/A N. Fong
800K floppy drive, DS, Apple 7737 10897 N/A C. Nicolais
AST 4000, AST Research 1495 1533 159 KATZ, Mousehole BBS
AST 4000, AST Research 1495 1549 160 KATZ (second drive)
AST 4000, AST Research 1495 1537 169 KATZ (third drive)
Bernoulli Box, 5MB, Iomega 4174 24437 66 JCOM, Mousehole BBS
Corvus 45MB 10080 16632 323 R. Scorer, Corvus
Corvus 126MB 9822 16438 240 R. Scorer, Corvus
DASCH external RAMdisk 2482 2797 N/A J. Eugenides
DataFrame 20, SuperMac 1319 2233 488 J. Bean
DataFrame 20, SuperMac 1344 2233 487 S. Brecher
DataFrame 20, SuperMac 1319 2233 446 L. Custer
Hard Disk 20, Apple 7029 7938 368 M. Chally
Hard Disk 20, Apple 7074 7871 368 N. Fong
Hard Disk 20, Apple 7054 7944 370 KATZ, Mousehole BBS
Hard Disk 20, Apple 9714 9718 263 R. Scorer
Hard Disk 20, Apple 9883 6948 368 R. Wiggins
HD-20, MDIdeas 1726 3260 446 S. Brecher
HD-30, MDIdeas 1749 3576 406 S. Brecher
HyperDrive 10, obsolete model 1591 1616 401 S. Brecher
HyperDrive 10, GCC (V2R1) 8000(?) 7982(?) 648(?) H. Conover
HyperDrive 10, GCC (V2R1) 7985(?) 6892(?) 485 R. Perez
HyperDrive 20, GCC (V2R1) 1703 1506 640(?) R. Ford
HyperDrive 20, GCC 1704 1506 241(?) W. Luckie
LoDOWN 10MB 1504 1503 321 S. Brecher
LoDOWN 20MB 1503 1504 242 M. Bohlig
MacBottom 10, v2.1, PCPC 4159 6897 686 M. O'Connor
MacBottom 10, v2.6, PCPC 4159 6897 608 S. Aronian
MacBottom 20, v2.1, PCPC 4110 6817 601 L. Becker
MacBottom 20, v2.6a, PCPC 4161 6901 657 S. Fischbach
MacDrive, Tecmar 6102 6704 440 L. Custer
MacDrive, 10MB Fixed, Tecmar 6017 6719 401 C. Nicolais
Macintosh XL, 10MB 3489 3589 370 MACLAIRD, Delphi
MagNet 20, Mirror Tech. 14539 14538 322 D. Etchells
MicahDrive 20 AT, Micah 508 507 488 S. Brecher
MicahDrive 20 AT, Micah 508 507 527 S. Harris
OverDrive 60/16MHz CPU, Levco 1102 1102 121 S. Brecher
Profile, 5MB, Lisa 2/5, Apple 4107 4407 721 MACLAIRD, Delphi
Quark QC-20 6476 6488 82(?) R. Thacker
QuickDrive external RAMdisk 2411 2479 52 R. Bates
QuickDrive external RAMdisk 2466 2535 33 J. Eugenides
RamStart RAMdisk/Beck-Tech RAM 186 186 N/A G. Frascadore
Warp 20, Warp Nine Engin'rng 14537 14537 321 G. Frascadore
------------------------------
From: RICFORD (7531)
Subject: Watch out for DataPak Software
Date: 23-APR 11:00 Business Mac
One of our subscribers, Peter Fleischhacker, reports that he purchased
Executive Office from DataPak software, only to find that it was
obnoxiously copy-protected, so that it cannot be used on a hard disk
or an 800K floppy; furthermore, it comes without any manual -- only a
promise to send one when it's ready. So, Peter decided to return the
product. The company would not accept it, or refund his money! A few
days later, he called for technical support. This time they said that
everyone was busy on a project and that it wasn't possible to help
him. When asked when he _could_ get help, they replied they had no
idea!
Our advice: stay away from DataPak Software.
Ric Ford
"MacInTouch" newsletter
------------------------------
From: RICFORD (7532)
Subject: Where's Sierra Info. Systems?
Date: 23-APR 11:02 Business Mac
Does anyone know the status of Sierra Information Systems, the company
which was selling Accountant's Choice. They seem to have disappeared,
at least as far as answering their phone goes.
Ric Ford
------------------------------
From: RDETCHELLS (7552)
Subject: Re: Hyperdrive Removal request
Date: 24-APR 22:23 MUGS Online
To: Michael C. Adler
All I've eveer known to do is to GENTLY pry the board-guides with a small
screwdriver, to release the board, allowing it to be removed in a downward
direction, rather than sliding it out. --- David Etchells, DELPHI
------------------------------
From: MOUSEKETEER (7581)
Subject: RE: Open Mac rumors cont'd (Re: Msg 7570)
Date: 26-APR 17:20 Macintosh In Fact
Dear Ric,
The Expandable Mac UGLY like the PC AT?? Don't worry! I received a Kodak
Instant Print of the "artist's conception" of the unit this week from a secret
source at Cupertino, and really, it's kinda cute! From the front, it looks a
lot like a normal Mac, but around 4 inches taller and 6 inches wider to allow
room for the new larger screen. It's the side view that will take a bit of
getting used to.....
-------------------------*------------------------
| \
( \
FRONT ( \
( \
( \
( |
/ |
/ |
| ---- ---- |
| ------- ------ |
\-------------------------------------------------------
Yep, the new Mac is just over two feet deep! Seems the original specs
were worded a bit vaguely, and required a "Bus Mac", and while WE all
know they *meant* EXPANSION bus, the folks at that were thinking rather
literally. It's code-named the GRUMMAC, after the company who builds the
boxy buses. I'm told, also, that the little doo-dad at the top is a "pull tab"
for access to the expansion "Chassis".
Hope this helps,
Alf
------------------------------
From: ASMCOR (7586)
Subject: MDS and Lightspeed C
Date: 26-APR 20:59 Programming
All-
For what it's worth, i had my first experience trying to get some MDS
things linked into a Lightspeed C program. I have not used MDS much,
so I had a little problem figuring out how to set up the file so that
the labels would be available, but once I had that right all went
smoothly. The RelConv program from lightspeed worked just fine to
convert the REL file into a Lightspeed library, and it linked in and
worked right. So, it does work, for those who are wondering.
Jan
------------------------------
From: PIZZAMAN (7591)
Subject: Dollars & $ense
Date: 26-APR 22:12 Bugs & Features
Anyone get Dollars & $ense to work on an HD-20? I just bought a copy
to do some home finance stuff, and can't believe that this very
popular package is totally HD-20 incompatible. Could this be the case.
Even tried Hdutil with the patch. No luck. Hasn't there been an
upgrade since the origional release that wiwill let it be used with a
hard disk. They've added a file called "move to top", but this isn't
any better than just option control click finder. Any info available?
Barry
------------------------------
From: MOUSEKETEER (7594)
Subject: Is Mac Really Naked?
Date: 26-APR 22:47 Telecommunicating
I read an interesting book this morning, and am curious about how many here
might be interested in inviting the author to an online conference. The book
is "THE CULT OF INFORMATION, The Folklore of Computers and the True Art of
Thinking" by Theodore Roszak (1986, Pantheon Books).
While it's rather expansive (perhaps too much so?), the book challenges the
computer's current status in our society, initially using as comparison the
figure of the Emperor and his New Clothes, suggesting that "Unburdened of
vainglorious ambition, dressed in more modest but palpable working clothes,
the computer, like the emperor in the fairy tale, may yet become a reasonably
valuable public servant." Also, the author suggests that by giving an undue
importance to "information", which as been twisted to mean "knowledge", we
may be in danger of not teaching students how to actually think.
Surprisingly, the only two computer programs mentioned favorably in the book
are MacPaint and MacWrite.
While it would be impractical for everyone attending the conference to have
read the book, it might be possible to obtain the publisher's permission to
upload several selections for discussion.
I will post on poll you may "vote" in to express interest (or non).
Alf
------------------------------
From: MACINTOUCH (7595)
Subject: MS Word HELP!!!!
Date: 26-APR 22:57 Business Mac
I have an interesting problem using running heads with Microsoft word:
Everytime I do it, it doesn't work. (Pretty interesting, eh?)
Anyway, here's the problem. I do exactly as it says in the manual and I even
get the << sign in the left column but it NEVER shows up on the printout. I
have it set for even and odd pages, at many different positions and NOTHING
works. One weird thing does happen though: when I select and choose 'Running
Head' from the menu and select the choices, after I hit <ok>, the running head
in the document moves over 1.5 inches. If I have the running head right
justified, it goes OFF the screen and center or left justified moves it to the
right, 1.5 inches!!
Any and all help would be very appreciated since I have a 30 page
paper due Mon. am and it NEEDS running heads. Of course I could print
it on with one of the typewriter things or whatever they're called...
Thanks.
josh
------------------------------
End of Delphi Mac Digest
************************dad@mit-vax.UUCP (David Duff) (04/30/86)
In article <4863@topaz.RUTGERS.EDU> shulman@topaz.RUTGERS.EDU (Jeff Shulman) writes: > >Delphi Mac Digest Sunday, 27 Apr 1986 Volume 2 : Issue 16 > >From: MACINTOUCH (7595) >Subject: MS Word HELP!!!! >Date: 26-APR 22:57 Business Mac > >I have an interesting problem using running heads with Microsoft word: > >Everytime I do it, it doesn't work. (Pretty interesting, eh?) > >Anyway, here's the problem. I do exactly as it says in the manual and I even >get the << sign in the left column but it NEVER shows up on the printout. I >have it set for even and odd pages, at many different positions and NOTHING >works. One weird thing does happen though: when I select and choose 'Running >Head' from the menu and select the choices, after I hit <ok>, the running head >in the document moves over 1.5 inches. If I have the running head right >justified, it goes OFF the screen and center or left justified moves it to the >right, 1.5 inches!! > >Any and all help would be very appreciated since I have a 30 page >paper due Mon. am and it NEEDS running heads. Of course I could print >it on with one of the typewriter things or whatever they're called... > Sorry, but I don't think this will get to you in time for your paper. When you declare a paragraph to be a running header or footer in MS Word, the rulers for that paragraph are traslated from "indented" to "absolute" (my terms). What this means is that header and footer paragraphs ignore the "right margin" and "left margin" settings in the "page setup" menu. Standard paragraphs align the zero on the ruler with a point <left margin> from the left edge of the page, while ruuning headers and footers align the zero point on the ruler with the left edge of the page. This is consistent with the "division layout" commands for setting the vertical positions of the headers and footers. They are specified in units from top/bottom of the page. I don't know if I made that clear. If you print a character at the zero mark in the rule of a regular paragraph, its position on the page will depend upon the left-margin setting, while a character in a header or footer paragraph would (theoretically) come out right at the edge of the page. Keep in mind that the laserwriter can not print closer than .5" from any edge of the page, so your head/footer margins must be >.5" and <8.0" for printing in the regular orientation. So, even though your centered text appears to move off center on the _screen_, it is still centered on _page_ (and between the margin markers on the screen). About the problem of headers and footers not showing up: That used to happen to me, too. I don't think I ever figured out exactly what the problem was, but it doesn't seem to happen much anymore, so I must have changed the way I use word. Here are some things I would try: 1) repaginate before printing. Your're not supposed to have to do this, but I have seen it correct a different problem. 2) Check the "header" and "footer position" items in the "division layout" dialog box. Then check the size of your header or footer paragraph and the top and bottom margin settings, to make syre that you left enough room for it to fit without writing over other stuff. Come to think of it, I'm pretty sure that this is what my problem was. In case that doesn't work, try deleting them and re-entering them to see if that helps. It took me a couple of trys to master them, too. The key to both your problems is the fact that word uses "absolute" page coordinates to specify header and footer position. This is quite different from Mac Write's style. Hope this helps. Dave Duff
ephraim@wang.UUCP (pri=8 Ephraim Vishniac x76659 ms1459) (05/05/86)
> Delphi Mac Digest Sunday, 27 Apr 1986 Volume 2 : Issue 16 > > From: BRECHER (7507) > Subject: Interleave/DiskBench > Date: 22-APR 10:19 MUGS Online > > Which Interleave is best? > ------------------------- > [results from SSDiskBench, which does single-sector operations] > These results clearly confirm Bass's "about 6:1" estimate for optimal > handling of consecutive single-sector requests. Not really. It actually confirms Bass's claim *assuming consecutive requests are issued with minimal processing between them*. The diskbench program issued consecutive reads/writes as quickly as possible. Do most applications that do single-sector reads/writes do that, or do they process each sector of data between operations? > I gathered some statistics on the distribution of disk I/O requests by > writing a hook into _Read and _Write which records the size of each > request and the the sector (logical block) distance from the end of > the previous request to the start of the current request. The missing item here is the *interval* between requests. Unfortunately, the Mac's clock is to coarse to be much help here. If the apparent time between two requests is 0 or 1 ticks, they *might* be "back-to-back." Or, enough time might have elapsed to defeat any attempted optimization of the disk interleave. If more than 1 tick has elapsed, you can be sure that the disk interleave doesn't matter anymore, since typical disk rotation times are on the order of 1 tick. > So, whether 1:1 or 6:1/7:1 is better from the standpoint of getting the user > home quicker depends on the user's job mix. To find out what kind of > activities favor interleaving or lack thereof, I wrote another _Read/_Write > hook. Here, if the request started in the same cylinder in which the previous > request ended, and if there were five or fewer intervening logical sectors, > the relative advantage of 6:1 vs. 1:1 interleave was calculated and > cumulated. And, the relative disadvantage of 6:1 in terms of sectors passing > under the heads during actual data transfer was calculated and cumulated. > The following is a general summary of the net winner by activity: > Again, all this assumes that single-sector requests are issued with no intervening processing. I suspect that the real picture is very different. Ephraim Vishniac decvax!wanginst!wang!ephraim