a464@mindlink.UUCP (Bruce Dawson) (04/13/90)
Deven, how do you _know_ that the blitter is the bottleneck. Is there anything else it could be? What about, for instance, the data lines to the drives. Presumably having to share these between two drives will slow things down over the speed of a format. Should be easy enough to test. .Bruce Dawson.
deven@rpi.edu (Deven T. Corzine) (04/13/90)
As an experiment, I am going to split apart the long posting I already made into its component subjects, so people won't be so put off by the length, hopefully. (and they can easier read the parts that interest them.) I am doing this because I am looking for feedback, and have a number of difficult questions for which I am seeking answers. I have been working on writing an asyncronous track-by-track disk copier recently. I have a working prototype, but bugs remain. This posting is to describe the usage of the copier and to solicit feedback on how it may be improved. When the program is run, it opens the trackdisk units for both drives and inhibits the drives from AmigaDOS intervention. The program uses DF0: and either DF1: or DF2: -- tries DF2: if DF1: fails. Single drive copies are not supported yet, but will be soon. It then prompts for source and destination disks in the drives. A "source" disk is defined as a write-protected disk, and a "destination" disk is defined as a write-enabled disk. Any disks in the drives when it prompts are considered "invalid". Ejecting and reinserting a disk validates it. Pressing return in response to the prompt will validate any disks in the drives. The copy does not begin until neither drive contains an invalid disk, and there is at least a valid source disk in either drive. If there are two valid disks in the drives with the same protection status, the user is prompted to fix the source or destination disk, as appropriate. The copier starts reading the source disk, and when the destination disk is available, will simultaneously write to the destination disk with whatever has been read already. It will keep reading until it has read the entire source disk, or until it runs out of memory for tracks, at which point it will wait for a track buffer to be available after a write so it can continue the read. Track buffers will be freed after writing unless a read is waiting for a track buffer. (Which only happens when there is not enough free memory to simply allocate a new buffer.) If the destination disk is not in the drive, it will read from the source disk until it is out of memory, or until you insert the destination disk, when it will start writing and freeing the dynamic buffers for further reads. The entire copy operation will run to completion even with memory for only a single track buffer, albeit synchronously. A Control-C will cleanly abort the diskcopy. Unfortunately, in practice, the blitter is a bottleneck in the I/O, since the trackdisk.device uses the blitter for encoding, decoding and shifting the tracks. Hence, the async copy tends to run lockstep waiting for the blitter, which is beyond my control. Perhaps ECS or 1.4 trackdisk might be better. Anyway, it would have been nice if an asynchronous copy could have done at the speed of a format, (i.e. about 50 seconds) but actual timings have always been between 83 and 84 seconds, which is still pretty good. Deven -- Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327 Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven Simple things should be simple and complex things should be possible.
mt87692@tut.fi (Mikko Tsokkinen) (04/13/90)
In article <DEVEN.90Apr13071330@netserv2.rpi.edu> deven@rpi.edu (Deven T. Corzine) writes: [ lot of program description deleted ] > Unfortunately, in practice, the blitter is a bottleneck in the I/O, > since the trackdisk.device uses the blitter for encoding, decoding and > shifting the tracks. Hence, the async copy tends to run lockstep > waiting for the blitter, which is beyond my control. Perhaps ECS or > 1.4 trackdisk might be better. Anyway, it would have been nice if an > asynchronous copy could have done at the speed of a format, (i.e. > about 50 seconds) but actual timings have always been between 83 and > 84 seconds, which is still pretty good. > Deven Can trackdisk.device read tracks without MFM-decoding? If it can't, don't use it, but instead take all disk-control for yourself (dunno how, never programmed anything with multitasking) and use direct IO-calls in hardware registers, so you don't have to decode data. There is no use to decode the data if you are just copying it. IMHO Why are you making this program since for example PCopy does all you want, only with two drives, but there are lot of one-drive copiers around. And they are as fast as the theoretical copying speed (NumberOfTracks(160)/ SpinsInSecond(5)*2(Both read and write(3 for verify))) which something like 64 sec. and with verify 96 sec. Thats because there is only one dma-slot for disk-drives. You can have multiple drives spinning but only one disk can be accessed at a time. MIT -- ----------------------------------------------------------------------- : Mikko Tsokkinen : I'm not a number ... I'm a free man : : Internet mt87692@tut.fi : UUCP tut!mt87692 : Bitnet mt87692@fintut : -----------------------------------------------------------------------
deven@rpi.edu (Deven T. Corzine) (04/14/90)
In article <DEVEN.90Apr13071330@netserv2.rpi.edu> I write:
[ lot of program description deleted ]
Deven> Unfortunately, in practice, the blitter is a bottleneck in the
Deven> I/O, since the trackdisk.device uses the blitter for encoding,
Deven> decoding and shifting the tracks. Hence, the async copy tends
Deven> to run lockstep waiting for the blitter, [...]
On 13 Apr 90 15:52:39 GMT, mt87692@tut.fi (Mikko Tsokkinen) said:
Mikko> Can trackdisk.device read tracks without MFM-decoding?
Yes. TD_RAWREAD and TD_RAWWRITE.
Mikko> If it can't, don't use it, but instead take all disk-control
Mikko> for yourself (dunno how, never programmed anything with
Mikko> multitasking) and use direct IO-calls in hardware registers, so
Mikko> you don't have to decode data.
Well, not exactly... I don't want to deal with the hardware directly.
No need to, no value in it. Trying raw reads and writes is a
possibility, but I don't know if it will work.
Mikko> There is no use to decode the data if you are just copying it.
Maybe, maybe not. See below.
Mikko> IMHO Why are you making this program since for example PCopy
Mikko> does all you want, only with two drives, but there are lot of
Mikko> one-drive copiers around.
Partly, I wanted to see if an asynchronous copy would really fly (as
it seemed it ought to) or not. It doesn't fly, but the speed isn't
awful.
Mikko> And they are as fast as the theoretical copying speed
Mikko> (NumberOfTracks(160)/ SpinsInSecond(5)*2(Both read and write(3
Mikko> for verify))) which something like 64 sec. and with verify 96
Mikko> sec.
You're not taking into account seek time...
Mikko> Thats because there is only one dma-slot for disk-drives. You
Mikko> can have multiple drives spinning but only one disk can be
Mikko> accessed at a time.
For actual data transfer, sure. But I expect of the time it takes to
transfer a track to memory, raw data transfer from the drive seems
unlikely to be more than 20% of the entire time -- the rest would be
the blitter decoding and aligning the track. I could be wrong here,
but decoding the MFM is rather a bit more complex a task than blasting
the data off the drive into memory.
Yes, the bus is still going to be locked for the blitter, but I don't
believe it's data transfer time -- just decoding time. (The shifting
operation can't be too hard; it probably takes an amount of time
similar to that of transfering the data from the drive.)
As for the idea of using raw reads and writes, it's a good thought,
but there are possible complications. Most importantly, it would NOT
work correctly to simply read a raw track and write it back out.
Okay, it might, but it's unlikely.
Consider how the trackdisk.device deals with the drive. To read a
track, it simply starts a DMA transfer from the drive from wherever it
may happen to be. It reads slightly MORE than a full track, likely 12
sectors' worth. (There being 11 sectors/track.) [12 sectors + track
gap length, that is.] {this is a guess.} <this is too many
parenthetical notes.> :-)
It then searches from the start of the read-in data for the start of a
new sector. It uses the next 11 sectors in the buffer as the track
read, using the blitter to shift the entire track buffer to start with
the new sector, and then it does another shift for the sectors in the
track buffer which are after the track gap, so the gap is moved to the
end of the buffer. Then it does a few tricky operations with the
blitter to decode the MFM into actual data. Maybe I missed something
in that description, but that's the basic idea.
Now, if I read a raw track, I don't think the trackdisk device will do
the shifts with the blitter to align to a sector start and move the
track gap. Perhaps it does; I'll make a point of checking next chance
I get.
Assuming it doesn't, I see a definite problem -- I read a raw track
and have data for a track which probably starts in the middle of the
sector. If I just write this as is on the destination drive, how much
would you care to bet that the alignment and speed of the drive is so
perfect that it finishes in the middle of that same sector such that
when read back in that sector can be decoded correctly?
Now, if the trackdisk device DOES do the shifts on a raw read, then it
should work fine; you're right that I don't need the MFM decoded
myself; I'm only copying it, and the encoding comes out to the same
thing. On the other hand, will a TD_RAWWRITE work correctly to an
unformatted disk? I would assume it should work if I write a full
track.
If for some reason I must use TD_FORMAT, then I'm stuck with decoding
and encoding again. [I don't have to do this, right?] I guess a
relevant question is: Is there a difference between a full-track write
with CMD_WRITE or TD_FORMAT?
If the trackdisk doesn't do the shifts, I could grab the blitter and
do it myself; it's just more work. But if I can do the copy without
decoding the MFM, it should speed things up considerably.
One important question -- is it possible that such a raw copy could
INCREASE the probability of an error on the copy? And if I do a
verification read on it, if the MFM-encoded data matches, am I clear,
or MUST I decode the MFM to be sure it's not garbage?
This is getting long again. *sigh*
Deven
--
Deven T. Corzine Internet: deven@rpi.edu, shadow@pawl.rpi.edu
Snail: 2151 12th St. Apt. 4, Troy, NY 12180 Phone: (518) 274-0327
Bitnet: deven@rpitsmts, userfxb6@rpitsmts UUCP: uunet!rpi!deven
Simple things should be simple and complex things should be possible.martint@altitude.CAM.ORG (Martin Taillefer) (04/14/90)
TD_RAWREAD/RAWWRITE do not work in Kickstart 1.3 and previous. So all that long discussion is pointless :-) -- ---------------------------------------- Martin Taillefer INTERNET: martin@pnt.CAM.ORG UUCP: uunet!philmtl!altitude!martint TEL: 514/640-5734 BIX: vertex