From: lupe@ukw.uucp (Lupe Christoph)
Newsgroups: comp.sys.sun.hardware
Subject: Re: dd/Exabyte weirdness [ broken DMA software/hardware ]
Keywords: exabyte dd
Date: 12 Apr 92 11:17:58 GMT
Organization: cic

olson@anchor.esd.sgi.com (Dave Olson) writes:

>In <1992Apr7.215023.18777@ukw.uucp> lupe@ukw.uucp (Lupe Christoph) writes:

>| john@aplcomm.JHUAPL.EDU (John Hayes) writes:
>| >I am trying to connect an Exabyte tape drive to an embedded computer
>| >via SCSI bus.  To learn how to control the tape with SCSI commands
>| >I hooked a SCSI bus analyzer between our Sun3 and its Exabyte.
>| >I used dd with several different block sizes to write a tape; 
>| >there were no surprises.  But when I use block sizes greater than or
>| >equal to 64k, something interesting happens.  For example,
>| >	dd obs=64k of=/dev/rst1
>| >produces a block of 65534 (64k - 2) bytes followed by a 2 byte block,
>| >followed by a 65534 byte block, etc.  If I do
>| >	dd obs=128k of=/dev/rst1
>| >two 65534 bytes blocks are produced followed by a 4 byte block, etc.
>| 
>| The DMA controller you have uses a 16 bit counter register. This limits
>| one transfer to 64 KBytes (65536). It also is not capable of using a
>| value of zero as meaning the full count. This leaves you at 65535
>| at most. And that controller is word-oriented (I believe, it's been
>| a long time). So you must round down to the next lower even count, 65534.

>Yes, but that is no excuse for not accepting larger transfer sizes, and
>simply reprogramming the DMA controller part way through the transfer
>(as many times as needed), along with setting up the SCSI chip to
>match.

I have no idea what kind of DMA controller you are using, but generally
I assume you can pause it in mid-transfer, bump the counter register
and continue it. If you can't pause it, the transfer count you
compute would be incorrect (race condition).

Or you have a DMA controller that gives you a chance to start another
block of data without terminating the transfer.

I have no data on the various DMA implementations Sun had in the past
and currently. And I don;t know which Sun model John Hayes uses.

There is also the mapping to be taken in account. For example the
Sun VMEbus implementation has a total of 1 MByte of DVMA space.
This is precious, to you incur the small overhead of breaking
up the transfer in smaller pieces to avoid congestion of
DVMA by large buffers.


>That is what SGI does (different models have different limits on their
>DMA hardware, from 64K to essentially unlimited, except by physical
>memory).  On all of these we do DMA's up to 4 Mbytes to SCS devices by
>default, and up to just about all of physical memory if you reconfigure
>the kernel to allow it.  Yes, it is a bit more programming, but
>that is no excuse for not doing it right.

Well, I don't have the details on your hardware, either.

And frankly, the overhead for additional SCSI commands is so small
compared to the transfer speed to the actual media, I don't care
too much.

>Creating tapes (in particular) with a different block size than
>requested is simply braindead.  Far better to simply disallow transfers
>above 65534(or 5) bytes, than to break it up that way.  You can waste
>tape that way also, as well as making it very difficult to read tapes
>on other systems without such silly limitations.

The only case I had problems with this was with seismic data tapes.
These tend to have *unlimited* blocksize. Even your entire main memory
may not be enough for a seismic data, so you will have to use
double buffering in the application to allow writing the data
to disk while more data is read.

BTW, inter record gaps can also be of unlimited length on these
tapes. The drives run in real time when recording is done.

Many tape drives use fixed length records these days. This
is especially true for QIC-type tapes and Exabytes (these can do
both, but record in fixed length blocks in any case). I don't
know about DAT tapes or 3480's.

You have a potential problem with the variable block length
1/2" tapes. But I've never seen a tape with more than 32KByte
blocks. But many with 80 Byte blocks.
-- 
| ...!unido!ukw!lupe  (German EUNet, "bang")     |  Disclaimer:            |
| lupe@ukw.UUCP       (German EUNet, domain)     |  As I am self-employed, |
| suninfo!alanya!lupe (Sun Germany)              |  this *is* the opinion  |
| Res non sunt complicanda praeter necessitatem. |  of my employer.        |