popelka@tank.uchicago.edu (Glenn Popelka) (10/12/89)
I have been benchmarking the HP7980A tape drive (a 125ips streamer) on a HP9000 model 835. I have noticed some peculiar results, and I have an idea that I'd like to get some comments on. The benchmark program opens the tape drive (/dev/rmt/0hn) and goes into a loop writing records to tape until EOT is reached. I tried this with record sizes of 1536, 10240, 20480, and 30720 bytes. For small record sizes, the tape drive writes a bit, stops, backs up to the point it would have stopped at if it were a stop/start drive, writes, backs up, etc. It takes about 10 minutes to fill up a tape this way. Once the record size reaches a certian threshhold, (somewhere between 10240 and 20480 bytes) the tape drive streams, that is, it doesn't stop, backup, write some more, etc. With the larger record sizes, it takes about 4 minutes to fill the tape; close to the theoretical maximum for a 125ips, 6250bpi drive. Here's what I think is happening; Under unix, a buffer is allocated for I/O; when this buffer fills up, unix gives the process another buffer to write into, and the previous buffer is asynchronously written to the device. I think that when the buffer gets a complete record, another buffer has to be allocated, even though the previous buffer is not full, in order to have the end of record mark properly placed on the tape. For small record sizes, these buffers are filled so fast that unix runs out of buffers to give to the process, and it has to wait until some writes to the device are finished so more buffers can be given to the process. For larger record sizes, it takes longer to fill the buffers, so that there is always a buffer ready when the process needs it and the tape doesn't have to stop and wait. I think that a solution to this would be to increase the number of buffers available to a process. I think this would involve changing a parameter in the kernel. Everyone I've talked to thinks the problem is in the tape drive itself, but I'm not sure about this, because an unnamed competitor running the HP7980A can fill a tape faster at small record sizes than the HP9000 can. I think the default number of buffers for that system must be larger than HP/UX. So, the question is, how can you change the default number of IO buffers available to a process? I'd like to give this a try, even if it only proves I have no idea what I'm talking about. Or, is there another way to increase performance on this drive. It is important for us to keep the record structure on the tape. Thanks for bearing with me, I'm a relative greenhorn.(if you didn't pick that up already!) -- glenn popelka university of chicago laboratory for astrophysics and space research popelka@tank.uchicago.edu
rjn@hpfcso.HP.COM (Bob Niland) (10/13/89)
re: "I have been benchmarking the HP7980A tape drive (a 125ips streamer) on a
HP9000 model 835. I have noticed some peculiar results..."
> The benchmark program opens the tape drive (/dev/rmt/0hn) ...
> For small record sizes, the tape drive writes a bit, stops, backs up to
> the point it would have stopped at if it were a stop/start drive, writes,
> backs up, etc.
Do you have bit 21 (IR Inh) clear in the /dev file minor number?
If this bit is set, each write request cannot complete in the host until
the data is actually on the tape, which usually leds to thrashing on small
record sizes.
IR = Immediate Report, which allows the drive to return a status of "write
complete" as soon as the data is read into the drive's cache, but before
it is written to tape.
With IR enabled, the drive should stream as long as you can send data at an
aggregate rate of 781 Kbytes/sec (at 6250 cpi). Since the maximum HP-IB bus
rate is 1.2 Mbytes/sec., the overhead of short records could prevent
reaching 781 average.
Regards, Hewlett-Packard
Bob Niland rjn%hpfcrjn@hplabs.HP.COM 3404 East Harmony Road
[hplabs|hpu...!hpfcse]!rjn Ft Collins CO 80525-9599