Mitchell Schoenbrun wrote:
There are some interesting questions at hand here.
First my recollection of async mode is that with 8bit
transfers, it is only 2.5MB/sec maximum. I’ve never heard
of doing a 16bit async transfer, though it is possible that
it exists, but even so you would then only see 5.0MB/sec.
Hmm, it is a 68 pin cable, so it never occurred to me that it wouldn’t do 16
I’d hate to have to actually read the real scsi spec, but all my scsi books
are older than UW…
A common misconception people of about the maximum transfer
rates is that they are at all related to the sustained rate.
The sustained rate is typically limited by the rotational speed
and the bit density. I don’t know what the latest technology is
doing, but it is possible for the bit density to vary from cylinder
to cylinder. I mean that in the most perverse manner, in which
the linear bit density doesn’t change, but the number of sectors
gets less toward the center of the disk. With any logically
addressed device, it is chancy to predict where a specific
sector actually is.
Perhaps I should do the math on the internal bit rate; I think it is in the
All that said, I think that 6MB/sec seems a little
pokey. Is the Cheetah a 10,000rpm drive? If not, then I
doubt it would reach the 15MB/sec stratosphere of hard
drives. I’ve seen close to 12MB/sec on a 7200rpm drive.
It is 10,000 rpm… gee, 15MB/sec would be nice!
One possibility is that you have a cabling problem. To get the
Ultra transfer rate of 20hz, your cables have to be very good
quality, and the length is limited. You also want to be choosy
about the termination.
And if too long, they shouldn’t be coiled up, I’ll bet! I’d better check that!
Termination is supposed to be internal on the Cheetah drives, so presumably
not a problem…
You didn’t mention the speed of your processor. If you
are using something below a 200Mhz P1, you might be running
into an Fsys overhead problem. An interesting test might be
to pre-allocate a very large file, and then re-do your
experiment overlaying the file.
It’s a 233Mhz P2. Maybe I’m on the ragged edge?
Can I bypass Fsys overhead with a blockwrite???
I tried the pre-allocation, it actually seemed to slow things down
Previously, Phil Olynyk wrote in qdn.public.qnx4.devtools:
I am working on a project which involves saving video to a UW scsi
drive - the AHA2940UW controller and the Cheetah drive both claim to be
capable of 40Mb/sec in sync mode. I’m using blockwrite() in a loop to
write out 513 blocks, 127 at a time. I need to do this for more than a
minute or two… So far my sustained rate over 20 to 40 seconds is 6.2
Mb/sec, which is the async transfer rate, as far as I can tell from the
Using the latest ( 6 Feb 01 ) Fsys.aha8scsi, I have been trying to
force sync, wide, and ultra using -S 1 -W 1 -U 1 after the aha8scsi
option - but I get an error message about processing options for the
aha8scsi module — it won’t even take a -v or -vvv to tell me what it
thought it was doing! When I use Fsys.aha7scsi and its options, they are
accepted, and nothing changes >
SO… can anyone tell me how to set options for Fsys.aha8scsi so that
I can get a transfer rate of at least 10 or 15 Mb/sec?
And/Or how to use open() and blockwrite() to bypass a driver cache
and DMA straight from my buffer out to the drive?
Or any other useful ideas? ioctl()s for the driver ?? new in 4.25E
includes maybe ( I only picked up the scsi driver )
OBT Software Corp.
Mitchell Schoenbrun --------- > firstname.lastname@example.org