“Bill Caroselli (Q-TPS)” wrote:
Hi Phil
My guess is that something isn’t right or . . . .
Given the hardware that you are talking about it should be fairly easy to
get the sustained transfer rates you need, if everything were configured
correctly.But, and here’s your big BUT!
As Rennie said, what else is going on in the system? This falls into two
specific areas.
What other disk IO is going on at the same time? If the disk needs to
move that head to do an IO to/from another cylinder on the disk that will
slaughter your IO throughput. Of a slightly lesser consequence is what
other IO is going on on the SCSI cable? Even if your app is the only app
IOing to the disk in question, if you need to share bandwidth with another
device, then that will cost you. If that is the case consider adding a
second SCSI adapter to the system and have one dedicated to the app that
requires the fast throughput. Also, if there are other devices on the SCSI
bus, then the bus could concievibly slow down to the rate of the slowest
device.What, if anything, is running at a higher priority than the Fsys.scsi??
driver? (Note: the priority of Fsys doesn’t matter, I think it priority
floats.) A very poorly written device driver or other app that grabs the
CPU for long periods of time at a priority above Fsys.scsi?? will kill the
disk IO throughput. Or, even worse, a driver that turns off interrupts for
long periods of time will kill disk performance.I think it is well worth the time to write a quick benchmark that runs in an
otherwise idle system to test what your sustained throughput really is.
This will tell you if you are up against hardware misconfigurations or
limits, OR a poorly configured system WRT priorities and interrupts. Also,
play with your Fsys cache options and rerun the tests.But don’t look for answers to a specific question by running your whole
application. You’ll end up chasing you own tail.Bill Caroselli
Thanks Bill -
-
This (10,000 rpm Cheetah) is the only drive on the 68 pin internal bus,
although there is a Zip drive on the 50 pin bus.
Perhaps I should remove it for a test…no huge loss, anyway, it’s too small for
our data files! We use the regular IDE drive for program and file data storage,
so it’s idle during data acquisition… -
These results are from a small test program. Nothing but Photon is running.
(This is why I am so worried!)
First I allocate a huge 512 by 513 byte buffer. Then I fopen a block device
and sit in a loop writing out the buffer for 30 (fr/sec) times the number of
seconds I want to try out, usually 10 to 50. Writing out the buffer is itself a
loop, since MAX_BLOCK_OPS is 127. Then I fclose the device. Then I immediately
open( … , WRONLY) the device and try again. Since I noticed a difference in
the two times, I then do another fopen and do it all over again for a third
time. The results:
The first fopen, for a 10 second try (300 frames), it takes about 8
seconds, the open takes 12 seconds, and the next fopen also takes 12 seconds.
For more frames, the first fopen is about 4 to 5 seconds faster than the later
opens; the transfer rate decreases toward the 6.2 MB/sec that the later two
writes achieve. I conclude that there is a cache that holds about five seconds
worth of data, and my long continuous writes overwhelm it - no surprise. But, of
course, I’d save time if I could bypass the cache completely.
I will try DSYNC on my open, it can’t hurt, since all my other (real app)
activity is in other tasks. I’m not sure which Fsys cache options might be
applied to a single device. And I have yet to get any aha8scsi option accepted;
did the format change between aha7scsi and aha8scsi?
Thanks -
Phil Olynyk