Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!apple!agate!eos!shelby!portia!roadman
From: roadman@portia.Stanford.EDU (arthur walker)
Newsgroups: comp.sys.amiga
Subject: Re: C-ltd controller
Summary: kronos handshake
Keywords: hard disk controllers
Message-ID: <4832@portia.Stanford.EDU>
Date: 25 Aug 89 16:15:17 GMT
References: <179@gcrc.aecom.YU.EDU> <288@bilver.UUCP> <2354@jhunix.HCF.JHU.EDU>
Sender: arthur walker <roadman@Portia.stanford.edu>
Organization: Stanford University
Lines: 52

In article <2354@jhunix.HCF.JHU.EDU>, barrett@jhunix.HCF.JHU.EDU (Dan Barrett) writes:
> In article <288@bilver.UUCP> alj@.UUCP () writes:
> >
> > Speaking of the new C. Ltd Kronos controller ("Quotes, what quotes?")...
> > Regardless, my times (diskperf v3.0) are around 70K read with a 1024 buffer,
> >and 54K write.  Are you sure your read time (680K) is correct?
> >Given, my drive is an Adaptec 4070 controlled model with an unknown access
...
> 	I have an old C.Ltd. controller, Adaptec 4070, and slow 65ms-access
> hard drive.  My reads are easily 140Kb/sec.
> > Oh, these incredibly-fast times are realized with an interleave of four
> >(for the Adaptec), turning on all the BlockReads/BlockWrites, and worst of
> >all, disabling IRQ interrupts....
> 
> 	Read the manual carefully.  My interleave is at 5, which is the
> recommended interleave on the 4070-based drives.  C.Ltd. controllers tend to
> be VERY interleave-sensitive.  Also, I recall that certain options in the
> devs:DevSetup file must NOT be turned on with the 4070.  I forget which
> ones, but they are clearly marked in the example DevSetups in the manual.
Ah, but the Kronos is different.  It's my understanding that it has hardware
handshaking to check that the REQ line on the SBIC has been asserted again
before allowing the byte read or write in what's called pseudo-dma mode by
the chip-makers, which has more to do with the chip state than what's going
on outside of it.  Apple uses a similar trick on the SE and the mac II to
allow what they call blind transfer.

The 4070 evidently does some internal service right in the middle of sector
transfers, and it takes enough time that a blind reading host can get the
same byte more than once if its code is running at all fast.  The 4000 has
the same sort of internal service, but manages it much better, such that 
you have to have a 68020 to catch it.  Remember, it only has to move 2/3 
as many bytes per unit time to the SBIC, its 8085 has an easier life.

So the fact that this guy is not swamped by r/w errors indicates that the
Kronos DOES fix this in hardware.
He should continue to use BLOCKREAD although BLOCKWRITE
is inactive in the current rev.  I found that 4:1 was OK, but that was with
a 68020 and the older controller.  I'm surprised that he's not getting a lot
more out of his controller though.  

Even the mac II couldn't get more than around 300k r/w with the 4070 though,
even with blind reads (hardware handshaking, remember).

The strategy should be to use the old drivers, if they'll work, to low-format
a large enough section to perform benchmark tests on, and go through a bunch
of interleaves.  Note he'll have to back up ALL data anyway, formatting a
subset just makes the testing go faster.

> | Dan Barrett, Systems Administrator  --  barrett@cs.jhu.edu (128.220.13.4) |

art walker
roadman@portia.stnaford.edu