Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!ut-sally!utah-cs!utah-gr!stride!l5comp!scotty From: scotty@l5comp.UUCP (Scott Turner) Newsgroups: comp.sys.amiga Subject: Re: The LIVE Digitizer from A-Squared... Message-ID: <279@l5comp.UUCP> Date: Wed, 3-Jun-87 18:55:59 EDT Article-I.D.: l5comp.279 Posted: Wed Jun 3 18:55:59 1987 Date-Received: Tue, 9-Jun-87 01:54:37 EDT References: <8705290639.AA04316@ingres.Berkeley.EDU> Reply-To: scotty@l5comp.UUCP (Scott Turner) Distribution: world Organization: L5 Computing, Edmonds, WA Lines: 88 Keywords: LIVE scottdisk.device speed mount features Summary: LIVE E-Mail to me, and recent results from scottdisk.device work. In article <8705290639.AA04316@ingres.Berkeley.EDU> hatcher@INGRES.BERKELEY.EDU (Doug Merritt) writes: >It *cannot* work simultaneously with a hard disk. It takes over the machine >because there are just *exactly* enough memory cycles available to read in >the video data at the same time that the screen display is maintained. The A person at C-A wrote me an E-Mail pointing out the obvious (I really WAS dumb) I can't use my hard disk because I can't plug it in. :( LIVE takes over the expansion port thus I have to unplug my hard disk BEFORE I can plug in LIVE. And obviously, if my hard disk isn't plugged in I can't use it. Needless to say, the people at LIVE will have to pry my cold dead fingers from my hard disk. ;) Viva Digi-view. >And even if they did add a tightly coupled hard disk driver, supporting >a hard disk with very very lenient timing requirements, it wouldn't SCSI can be VERY tolerant of timing AFTER the initial connection. Once the command is started you can literally send 1 byte per HOUR and the controller will sit there quite patiently waiting for enough bytes to come in to form a block. On the OTHER end of the spectrum, the OMTI 5100 controller, and many others, are QUITE happy to have data sent to them at rates above 1 byte every 800ns. Using a interface that "auto-acks", like the C-Ltd, all it takes, after the command is setup, is a single move.b to send the byte along to the hard disk. >really help, because you wouldn't have the bandwidth to push the incoming >video out to disk. Hmmm...unless you turned off the screen display... On the bandwidth side of things... I've tuned scottdisk.device to where it does read at 42,500 bytes per second (diskperfa 32K buffer) but writes are still down at 17,500 bytes per second. Seems to be some heavy blockage in the write channel of amigadog. I think I've about reached the limits of what I can do with scottdisk.device and amigadog. I figure that "auto-ack" should allow scottdisk.device to punch up above 50,000 bytes per second on READ but it'll still be stuck down at 20,000 for writes. The figures given by diskperfa for VD0: are VERY enlightening if you know how to read them. VD0 was done as a device driver rather than as a HANDLER. Thus is has to go through ALL the same internal stuff that a hard disk driver has to go through. VD0 by it's very nature has no latency delays etc to slow it down. Thus it's timings reflect what amigadog is CAPABLE OF. ie we can't go any faster than VD0 thru the device interface. Thus VD0 sets an upper limit, like the speed of light, beyond which we can't go. Thus my challenge with scottdisk.device was to crowd the "Speed Of Dog" as closely as I could. I figured that VD0 was using a tightly coded move.B loop to move data to/from it. Thus to match the speed of VD0 I had to come as close to possible at matching this data movement rate. The biggest problem is drive rotational latency. Scottdisk.device was not being called often enough to read sequential sectors without getting caught by this dreaded delay. So I put in a track buffer. Bingo, I got a nice jump. Then I fiddled and found that a buffer size of 2k to 4k seemed about right. But now I was double handling the data. I have to move.B it from the hard disk and then move.B it from the track buffer when the dog wanted it. I couldn't do anything about the first move.B, not until I can get my first Excalibur built up that is :), but for the second I employed a little carnal dog knowledge. We all know how the dog LOVES keeping things on long word boundaries... Well it didn't let me down this time either. The buffer that the track buffer is moved in and out of is long word aligned. SO I used move.L for the track buffer movement. Ergo I'm now topped out at 42,500 for reads or about 2/3rds SOD. But I suspect that with my use of carnal knowledge I have just bumped SOD. ie VD0 could be recoded to use move.L's too. Arthur jr though is up above 100,000 bytes per second for BOTH read and write so there IS hope for high bandwidth hard disks. Even on slug four parallel port SCSI interfaces like I'm using to test bed all this. Some "features" I noticed with MOUNT as I worked on the above: 1. buffers=0 is a no-no for disk devices. The Amiga guru's with an addressing error at the first I/O request to the device. 2. buffers set to less than 5 is bad news too. Performance really takes a SERIOUS dive. To see what I mean try buffers=1. :) 3. MOUNT has no security check that the device loaded is the actual device. A quick example: if the named file in devs is called scottdisk.device but the name actually coded inside it is weirddisk.device MOUNT nor anything else will catch it. Result? Nasty system guru on first access to the device. Frankly I'm not all worked up over this one, but I thought I'd pass it along. Scott Turner -- L5 Computing, the home of Merlin, Arthur, Excalibur and the CRAM. GEnie: JST | UUCP: stride!l5comp!scotty | 12311 Maplewood Ave; Edmonds WA 98020 If Motorola had wanted us to use BPTR's they'd have built in shifts on A regs [ BCPL? Just say *NO*! ] (I don't smoke, send flames to /dev/null)