Rp07 performance query.

[Steve Glaser]

In article <2726 at watvlsi.UUCP> ksbszabo at watvlsi.UUCP (Kevin Szabo) writes:
>
>We have been experiencing performance problems with our vax 11/780.  It
>is running bsd4.2 and has two RP07's for the filesystem.  We have been
>guessing a lot, trying to figure out what is causing the lack-luster
>performance.  The current guess is that one of our RP07's is on the
>blink.  The program MON shows that one of the rp07's has a average seek
>time of 29ms, wereas the other is consistently 0.0ms.  All the other
>machines that we have looked at (using MON) show average seek times of
>0.0ms.


It's been a while since I looked at the Massbus code for 4.x BSD, but
4.1 did some cute optimization to avoid extra interrupts.  This has
the effect of disabling the seek time measurements if you have only one
drive on a given massbus.

Each disk drive has a work queue (sorted in seek order) that feeds into
a per massbus "data transfer queue".  If you have more than one driver
on the massbus, a transfer is started by taking the first request of
the work queue and issuing a seek.  When the seek completes, the
request is moved to the transfer queue.  If the massbuss is not doing a
transfer, the read/write command is then issued, otherwise the transfer
request stays in the transfer request queue until it can be executed.
This in this situation, every transfer is 2 interrupts (seek complete
and transfer complete).

Since the DEC drives have an implied seek in the transfer command set,
if you only have one drive on the massbus (noticed at autoconfig) they
don't issue the seek command and let the transfer command do it.  This
ties up the DMA channel of that massbus during the seek, but since
there's nothing else that could use it, it doesn't matter.

The effect this has is that the seek times will show as zero since
there are no seek commands to time.