shulman@topaz.RUTGERS.EDU (Jeff Shulman) (04/18/86)
Delphi Mac Digest Friday, 18 Apr 1986 Volume 2 : Issue 15
Today's Topics:
MacWrite & new ROMS
Re: DiskBench
Re: DiskBench (Re: Msg 7316)
DISK DRIVE
Re: Bad Mount Bug in New ROMs
RE: Hot rumor (Re: Msg 7278)
Re: another survey
Lightspeed C and New Traps
RE: Lightspeed C and New Traps (Re: Msg 7334)
VAX host software for Mac
RE: INFO-MAC Digest V4 #56 (Re: Msg 7345)
Drive queue
RE: Drive queue (Re: Msg 7366)
Re: 128K ROM version number
Re: 128K ROM version number
Reply to "The art of benchmarks"
RE: Reply to "The art of benchmarks" (Re: Msg 7386)
RE: Reply to "The art of benchmarks" (Re: Msg 7386)
RE: Reply to "The art of benchmarks" (Re: Msg 7391)
Reply to "The art of benchmarks"
----------------------------------------------------------------------
From: JEFFS (7301)
Subject: MacWrite & new ROMS
Date: 13-APR 19:37 Bugs & Features
Ever since my upgrade to the new ROMS, MacWrite keeps bombing about
once an hour or sometimes not for several. Anyone else have these
problems? It happens randomly with both RAM cache disabled and
enabled.
Jeff
------------------------------
From: BRECHER (7316)
Subject: Re: DiskBench
Date: 14-APR 06:45 MUGS Online
To: ephraim@wang.UUCP (pri=8 Ephraim Vishniac x76659 ms1459)
The enthusiasm with which DiskBench has been received is due to the
fact that it's the only game in town. Previously, the only timely
"information" on hard disk performance was advertising hype and
reports from users that such-and-such a disk is "very fast," or
subjective comparitive reports where influential extraneous factors
(such as the file system in use) were not held constant. I wrote
DiskBench in the afternoon preceding a local MUG meeting at which a
vendor demoed his hard disk product. I have never claimed that
DiskBench is "realistic" in the sense of emulating I/O patterns
generated by typical user activity. It merely provides *some*
indication of performance of the hardware and hardware-related
software.
"Unheard of" may be too strong -- there are large code segments and
large documents. Regardless, as to emulating typical I/O patterns, I
think the best way to do that would be to instrument a disk driver, or
install a patch to _Read/_Write, to record the locations/extents of
requests during some sequence of "typical" user activity -- such as
launching documents and quitting from several heavily-used
applications -- and then using the resulting activity database to
direct a "raw I/O" benchmark program. This approach, although much
more realistic than DiskBench's, is flawed by the problem of different
drive geometries causing a different frequency of cylinder-crossing
for a given set of logical I/O requests. If the set were large
enough, though, that problem might not be significant.
As to the unknown rotational latency bias, your point is well taken.
Courtesy of Jeff Shulman, I have your modified DiskBench source
(version 3.0) which incorporates your "dithering" scheme. One problem
with the implementation is that it applies the 60Hz timer granularity
to each I/O rather than to the test as a whole. With the faster
drives, there is a chance of significant cumulative timing error. A
simple solution would be to use a constant ordered set of "dither"
delays rather than generating a new random set on each run; a dry run
pass without I/O could be used to measure the total delay and subtract
it out of the total test time. A constant set could be obtained
without actually incorporating the data into the program merely by
seeding QuickDraw's random variable with a constant.
I encourage you, or anyone improving DiskBench, to modify the name of
the program as distributed (e.g., "DiskBench3") and to modify the
results dialog to include the new name. It will get confusing at best
if people start unknowingly comparing results from two different
programs.
More generally, I would like to see some disinterested party -- e.g.,
a non- advertising publication such as MacInTouch, or a user group --
undertake construction of a really good hard-disk benchmark, run it on
*several* specimens of each drive (to eliminate outliers due to bad
sectors/tracks in the set comprising the test) and maintain and
publish the results. Before such a program is used its source code
might be submitted to the community for comment and criticism.
------------------------------
From: RICFORD (7322)
Subject: Re: DiskBench (Re: Msg 7316)
Date: 14-APR 09:51 MUGS Online
My current plan for MacInTouch benchmarks is to establish a new set of tests
based on a 1M-byte Mac Plus with the EA-checksum ROMs, System 3.2, Finder 5.3,
etc. We'll do basically the same thing we did before, but may add things to
test graphics performance, performance with larger files, and a numerics test
with something which uses SANE (not Excel).
We have already done some tests comparing HFS to MFS (MacBottom) and
Finder 5.0 to Finder 4.1 (HyperDrive). Our intent is to solidify
these comparisons between "generations" when Apple gets stable system
software out, and to then standardize on the new generation of
software for testing.
We'd certainly like to test multiple samples of hard drives from vendors, but I
expect that it will be a problem getting them, unless there is a major outcry
from users/consumers. We're not quite the "Consumer Reports" of the Mac World
-- we don't have a hardware budget big enough to purchase a number of units of
each drive.
It's true, though, that performance, and things like noise and reliability are
hard to judge from a single sample. The best information is an informed
consensus that develops over time, and I had hoped other people would do the
MacInTouch benchmarks, too. They haven't -- probably because it's too much
work. DiskBench is sure a lot easier to run. I think we need to develop
something in between the two, if we don't establish a complete, funded testing
organization.
Ric Ford
"MacInTouch" newsletter
------------------------------
From: JIMSB (7310)
Subject: DISK DRIVE
Date: 14-APR 00:23 Hardware & Peripherals
Can any one recommend a good disk drive diagnostic program ?
Thanks,
Jim
------------------------------
From: BRECHER (7317)
Subject: Re: Bad Mount Bug in New ROMs
Date: 14-APR 06:47 MUGS Online
To: Roy Leban <roy%farg.umich.csnet@CSNET-RELAY.ARPA>
The disk mounting logic knows nothing of the Desktop file. On my
system (128K ROMs, no Aztec), lack of a Desktop file is no bar to
mounting when Finder is not running. There must be some other cause
of your problem. With a debugger, you could trap _Mount and see what
result it's returning. The problem could be related to the system
heap configuration when Shell is running.
------------------------------
From: RICFORD (7325)
Subject: RE: Hot rumor (Re: Msg 7278)
Date: 14-APR 14:27 Macintosh In Fact
Mac 512K Enhanced 4/14/86
Apple announced today the Mac 512K Enhanced for $1999. This
replacement for the Mac 512K includes the 128K ROMs that are in the
Mac Plus, and the 800K internal disk drive. Instead of MacWrite and
MacPaint, Apple now encloses a disk with _sample_ versions of
MacWrite, MacPaint, MacProject, Mac Pascal, and Mac Draw. Also
included is a tools disk for upgrading disks with older systems.
Availability is real soon now... oops, I mean late April.
Ric Ford
"MacInTouch" newsletter
------------------------------
From: RICFORD (7342)
Subject: Re: another survey
Date: 15-APR 08:53 MUGS Online
In reply to Rocko at: BOB%BCVAX3.BITNET@WISCVM.WISC.EDU
The latest versions we know of are: MacTerminal 2.0, Red Ryder 8.0 (has some
bugs, but works better on Mac Plus), FEdit 3.5, ResEdit 1.0D7, MacTools/Copy II
5.1 (supports 800K drives), Switcher 4.9 (not quite released), MacDraw 1.9,
System 3.1.1 and Finder 5.2 (new System/Finder/Chooser/print drivers in May?)
Ric Ford
"MacInTouch"
------------------------------
From: DWB (7334)
Subject: Lightspeed C and New Traps
Date: 14-APR 22:59 Programming
Just got off the phone with the folks at THINK. I was complaining
about the lack of support for the traps in the new roms and they
provided the following assistance. If you declare a routine:
pascal short NewTrap() = 0xa835;
You declare a new inline call NewTrap which returns a short and is $a835. Note
two things. First, this will only work for stack based traps. Second, the hex
number can be anything, it doesn't have to be a trap. Well, actually it can be
any word. You could, however, if you really wanted to say:
pascal void RTE() = 0x4e73;
int_routine()
{
...
RTE();
}
and insert an inline RTE instruction.
Given this information, I have updated the NewRom stuff located in the Public
Domain section to take advantage of this fact.
David
------------------------------
From: DWB (7337)
Subject: RE: Lightspeed C and New Traps (Re: Msg 7334)
Date: 14-APR 23:26 Programming
Oh yeah, another neat and hidden feature. When you use RelConv to turn an MDS
.rel into a Lightspeed .lib file it creates a .voc file. If you edit that file
you can change the capitalization of routine names. Basic process looks like:
Edit .asm
Assemble .asm
RelConv .rel
Edit .voc
RelConv .rel
You now have a .lib with multi-case names. You could also create the
.voc file before running RelConv the first time. Any symbols not in
the .voc file will be added to it.
Ain't it wunnerful the things they don't tell you. Especially when they're
useful things.
David
------------------------------
From: RICFORD (7346)
Subject: VAX host software for Mac
Date: 15-APR 12:55 Business Mac
Pacer Software, Inc. is supposedly now shipping host software for VAX
systems running either VMS or Ultrix that supports terminal emulation,
print spooling, and file transfer between Macintoshes. MacBinary file
transfer is supported now, and so is the high-speed Omninet hardware.
(RS232 is the normal means of connection). Future plans include file
server support, which they now suppy for IBM/PCs, and VT240 emulation
(currently VT100, VT220 and third-party emulation).
pcLINK requires a Mac 512K or Mac Plus and costs $2000 for a host license that
provides for up to 5 Mac's operating concurrently. The Mac software itself is
not copy-protected. A command language for the VAX host software permits
batched file transfers, and the VAX can initiate transfers to the Mac.
The main office is at 1227 Pearl St., La Jolla, CA 92037. 619-454-0565 The R&D
office is at 100 Pennsylvania Ave., Suite 320, Framingham, MA 01701.
617-879-1765.
I have no affiliation with Pacer Software and I have not seen the system in
action, but I thought it sounded interesting.
Ric Ford
"MacInTouch" newsletter
------------------------------
From: MOUSEKETEER (7351)
Subject: RE: INFO-MAC Digest V4 #56 (Re: Msg 7345)
Date: 15-APR 21:56 MUGS Online
One more to add to the current version list: Thunderscan software is presently
at version 3.2.
------------------------------
From: JIMH (7366)
Subject: Drive queue
Date: 16-APR 23:05 Programming
INside mac says that the drive queue contains elements that have 4
status and flag bytes followed by pointer to the next item,
qtype,drive number, ect. however my globals list says the header is
at $308 and it does not seem to be a valid queue entry as it is 10
bytes long which is to short. it also points to a linked list of
entrys which have only 2 bytes befor the pointer. in this months
mactutor there is an excellent article on a nested volume manager in
C, and i am just hacking aroun d with my debugger looking at this
queue. could anyone tell me why it does not look like the queue in
the documentation? Also the article talks about a byte which when set
to 8 will make the drive no ejectable. does this also include dragging
it to the trash can? my tecmar will let me eject the hard disk, what i
really want to know is if i set this byte to 8 will that stop the
tecmar from being ejected? thanks jim
------------------------------
From: DWB (7380)
Subject: RE: Drive queue (Re: Msg 7366)
Date: 17-APR 01:53 Programming
What is located at $308 is a "Drive Queue Header". What it contains
is a 2-byte flag word, a 4-byte pointer to the head of the queue and a
4-byte pointer to the end of the queue. If you find the Drive entry
corresponding to the TecMar by following the queue and then change the
byte at offset -3 from the entry and change it to 8 the drive will be
non-ejectable. This doesn't prevent it from being drug into the
trashcan I don't believe. The reason you have to use index -3 is
because the flags aren't a proper part of the mac's generic queue
structure. Some queues have them some don't. Thus some genious
decided that the link entries would point to the next link entry and
the flag words would be before that. To clarify $30A: $1000 ; this is
the first drive in the queue $30E: $2000 ; this is the last drive in
the queue
$FFC: driveflags ; flags word
$1000: $2000 ; link to next drive
$1FFC: drive2Flags ; flags for drive 2
$2000: 0 ; null link is end of queue
Hopefully this will clear things up
David
------------------------------
From: RICFORD (7390)
Subject: Re: 128K ROM version number
Date: 17-APR 13:43 MUGS Online
I don't want to belabor this, and I thank Darin Adler for his helpful
information on PTCH resources and ROM versions, but I think he meant
$0075 and 117(dec.) for the 128K ROM version number, not $0076. We
did find $0075 in both EE-checksum and EA-checksum ROMs.
(aside: it's good to see Darin on the net. We are very fond of
SkipFinder, although the latest version we have exits to the Finder
when one attempts to use the open document option)
Ric Ford
"MacInTouch"
------------------------------
From: PEABO (7392)
Subject: Re: 128K ROM version number
Date: 17-APR 14:45 MUGS Online
Re: "exit to Finder when one attempts to use the open document option"
Well, the Finder *does* open documents, does it not?
;-)
------------------------------
From: BRECHER (7386)
Subject: Reply to "The art of benchmarks"
Date: 17-APR 07:40 MUGS Online
To: bass@dmsd.UUCP (John Bass)
Subject: Reply to "The art of benchmarks"
From: Steve Brecher
Background: DiskBench was written during an afternoon prior to a
user's group meeting at which Steve Edelman of SuperMac was appearing
with his DataFrame product. DataFrame was getting a reputation as a
relatively fast, well-designed and well-supported product (deserved,
as far as I can tell). I had spoken with Edelman at the January Expo
and he was, at that time, the *only* person I had spoken with who had
some understanding of the problems in Apple's SCSI Manager
implementation. I took DiskBench to the meeting to get some
indication of DataFrame's performance. DiskBench was intended to
provide, and does provide some indication of data transfer speed and
access speed. I have never claimed it to be a realistic benchmark in
the sense of measuring typical I/O patterns.
Since DiskBench was the only objective (if quite imperfect) measure of
performance extant among a sea of ad claims and user impressions, I
published it (on nets, source included) and invited hard disk owners
to submit results. One of the results submitted was for the Warp 20,
indicating a 32KB data transfer speed an order of magnitude slower
than other SCSI or internal subsystems. I questioned the submittor of
those results, under the assumption that they were invalid for some
reason. Pursuant to my skepticism, he repeated the test with the same
results. Later, a virtually identical result for the Mirror MagNet
seemed confirmative, as I had heard that Mirror and Warp 9 were
closely-related companies.
I can't follow the timing arguments (thus I opt for stupidity rather than
dishonesty, which are the alternatives provided me in Bass's message):
> I know of NO SASI/SCSI controller that will read a sector in LESS than
> 4ms from select to status complete if the data is just about under the
> heads.
A sector takes less than 0.9ms to pass under the head. Overhead for header
processing, ECC calculation, status, etc., does not quadruple the time. If it
took at least 4ms per sector, how could SCSI controller manufacturers advertise
(and provide) 1:1 interleave capability?
> Even if Micah's hostadapter is fully hardware DMA ...
> ...
> 1: the 1:1 interleave he claims can only be had by turning off
> interrupts -- this will certainly cause performance problems
> ...
> At 1:1 ANY mouse, printer, or clock interrupts WILL cause
> the interleave to be lost resulting in about a 18.6ms rotational
> delay.
MicahDrive does not use DMA nor turn off interrupts. It uses programmed I/O
with an NCR 5380-based host adapter (same as in Mac Plus and MacSCSI).
I just performed DiskBench on MicahDrive whilst continuously moving the mouse
around in about a 4-inch circle approx. 2 rev/sec. The results (along with the
originally-reported results):
Data transfer Access
---- time ---- time (all figures are ticks)
Reads Writes
continuous mouse movement 794 814 499
original (no mouse movement) 508 507 488
The total reported time is accurate to within a second as verified by
the second hand of a wristwatch (i.e., time is not understated due to
loss of VBL interrupts). If, as Bass claims, it took 18+ms for each
sector, due to inevitable missed sectors, the data transfer times
would be an order of magnitude higher. Perhaps Bass assumes a
controller that has no buffering; Micah's has a buffer.
> The Micah host adapter is not MacPlus compatable -- where will you have to go
> to get a second drive or tape when you upgrade with Micah??? --- only Micah.
Huh? The MicahDrive will install in either a 512K or Mac Plus, and is
currently running in both, in customer machines. If you want a second
drive or tape on a Plus, you plug it into the SCSI port on the back
(or if it's a serial or floppy-port drive, into those ports). The
MicahDrive host adapter and the Plus built-in (motherboard) host
adapter are entirely separate and non-interfering.
> If there is really a warped need to go faster I can supply a drive/controller
> and host adapter that is MacPlus compatable that is a full 7.5mb/sec ...
> (that is 50% faster than Micah) -- not cheap (about $1600) ...
(Nice pun.) While admittedly without marketing expertise, I think
that speed is important to hard disk buyers. Since MicahDrive and
HyperDrive currently list for more than $1600, I feel you would do
very well with such a product. Programmed byte-wide I/O executing
from ROM, stock Mac 8MHz CPU, is limited to about 5.3 Mbit/sec (0.67
Mbyte/sec) [12 clock cycles for Move.B (An),(An)+]. Thus I guess
you'd need either a word-wide interface, or DMA (which my hardware
friends tell me is hard to do on a Mac); if you've got the design, go
for it.
> Micah's cheap shot at Mirror with this shoddy benchmark ...
DiskBench was written and published without the knowledge of Micah, Inc., nor
any of their personnel. (I wrote the MicahDrive system software under contract
to Micah.) As to the idea that it's a "shot at Mirror" -- I'm at a loss.
> They [Micah] bought one of my units very early on and drove down here and
> wasted a half day of my time to help them get it going with their drive.
This was before my association with Micah. When they called me, they were
watching their system decay to death fairly rapidly due to utter lack of I/O
error checking in Bass's formatter and driver. The current Micah hardware and
software bear no resemblance, as progeny or otherwise, to the MacSCSI products.
> My background and qualifications include nearly 15 years of systems
> programming and performance tuning on IBM, DEC, UNIX and a dozen other
> mini/micro systems.
Yeah, I'm getting old too. Don't remind me. About ten disk drivers, firmware
for four or so disk controllers, and far too few wanton women.
DISCLAIMER: I don't have to disclaim anything, because I'm writing this on
Delphi. Nyah, nyah.
APHORISM: Nostalgia ain't what it used to be.
COMPLICATED NETWORK ADDRESS: Jeff Shulman takes care of that for us
(thanks, Jeff).
------------------------------
From: RICFORD (7389)
Subject: RE: Reply to "The art of benchmarks" (Re: Msg 7386)
Date: 17-APR 10:57 MUGS Online
We gonna have to start giving out Purple Hearts for flame burns around here...
:-)
------------------------------
From: PEABO (7391)
Subject: RE: Reply to "The art of benchmarks" (Re: Msg 7386)
Date: 17-APR 14:43 MUGS Online
A sense of humor is a valuable asset in an otherwise complicated world.
(I guess that's my aphorism.)
peter
------------------------------
From: FRIED (7395)
Subject: RE: Reply to "The art of benchmarks" (Re: Msg 7391)
Date: 17-APR 19:24 MUGS Online
Just don't count on getting rich selling it. <grin>
------------------------------
From: RWIGGINS (7397)
Subject: Reply to "The art of benchmarks"
Date: 17-APR 20:23 MUGS Online
To: bass@dmsd.UUCP (John Bass)
Subject: Reply to "The art of benchmarks"
From: Robert R. Wiggins
I feel compelled to respond to this unprofessional attack against a
fellow professional. I also have 15 years of experience in this
business, including 5 working for IBM. If an IBM employee made the
same kind of negative remarks about a competitor in public, he or she
would be fired, whether or not the remarks were accurate. IBM knows
that such remarks only serve to detract from the reputation of the
speaker. As a consumer, I agree, and find your remarks to say more
about you than they do about Steve Brecher or Micah.
Mr. Brecher has already responded to your technical arguments, but I would like
to add some comments of my own. I am not in any way associated with Micah, and
in fact derive my primary income from mainframes, not micros.
> I did a study of disk requests to the driver last summer on my 5mb drive,
> nearly all were less than a few sectors.
"Less than a few" is a remarkable number for a study to turn up.
> To wrap this up -- Micah's cheap shot at Mirror with this shoddy benchmark
> is only to try and buy market share after they have been advertising
> vaporware for months.
Again, the fact that you view this benchmark as a "shot" says more
about you than it does about anyone else. Micah did not write this
benchmark, nor distribute it, nor (as far as I know) have they made
any use of the results. Steve Brecher did write the software for the
Micah on a contract basis, but this hardly makes him an agent for
Micah in all his future endeavors.
> In this case I think that the lack of understanding that Mr Brecher seems to
> have in the total system timings may reflect other short comings in the
> quality of the product he is pushing. More over IF HE REALLY DOES UNDERSTAND
> THESE TIMINGS AND WITHHELD THEM then he is very guilty of presenting a
> falsehood on the market place. In either case it leaves a lot of
> questions in my mind about both Mr. Brecher and Micah.
This is truly insulting to Mr. Brecher. Not only do you question his
competence, but also impute base motives to him. I will agree (and
Mr. Brecher might also) that his benchmark is not the be-all and
end-all when it comes to disk performance. It is merely an attempt to
measure two variables of disk speed in a consistent manner across many
different types of disk in an industry where virtually no one
publishes geometry specifications. Andy Hertzfeld and Steve Brecher
had a dialog in public about this benchmark, with Andy on the side of
access time (which the benchmark does include) as the more important
variable. After a spirited discussion, Andy agreed that the benchmark
was one way to get an idea of relative disk performance, but not the
only way. I am a large systems performance specialist, and for the
DASD I work with data transfer is a small component of total service
time (of course, these service times are usually less that 20 ms), so
I would tend to agree with Andy. But I think that Mr. Brecher has
done the Mac community a service in providing a means, however
simplistic, of comparing disk drive performance. And I think you do
yourself and your company a disservice by promulgating innuendo about
a well-known and well-respected professional.
-- Robert R. Wiggins
------------------------------
End of Delphi Mac Digest
************************