Need more than 6.2Mb/sec from UW scsi

QNX Newsgroups (Archives) qdn.public.qnx4.devtools
1

Hi all -
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
Seagate doc.
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 :frowning:

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 )

Thanks -
Phil Olynyk
OBT Software Corp.

2

What if you open() with various flag to disable caching.
don’t remember the flag by heart.

What if you write directly to a reserved partition:
open ( “/dev/hd0.079”, …) , never tried it myself.

3

Phil,

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.

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.

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.

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.

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.


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
Seagate doc.
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 > :frowning:

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 )

Thanks -
Phil Olynyk
OBT Software Corp.

–
Mitchell Schoenbrun --------- maschoen@pobox.com

4

Mitchell Schoenbrun wrote:

Phil,

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
bit async.
I’d hate to have to actually read the real scsi spec, but all my scsi books
are older than UW…:slight_smile:

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
Cheetah spec…

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 :frowning:

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
Seagate doc.
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 > :frowning:

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 )

Thanks -
Phil Olynyk
OBT Software Corp.


\

Mitchell Schoenbrun --------- > maschoen@pobox.com

5

all -
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
Seagate doc.

You don’t give any details about the rest of your application.

Where are you getting the data to copy to the drive, and what DTR is
that capable of ?
Are you doing any manipulation (i.e. copies in your code) ?
What speed is your processor ?
What speed is your PCI bus, and can both the frame grabber and the
2940UW make full use of that bandwidth ?
Have you checked the latency timers on other PCI boards on the bus ?
Are you setting the sync flag on the fd ?

My guess is that 15 MB/sec should be possible if the hardware is
capable of 40MB/sec and there are no copies occuring in your code. This
means that your code would have to DMA from frame grabber into buffer,
and then block_write that buffer (without any intervening copies)
directly to disk. In fact, there is one copy occuring here since the
kernel copies the block_write message from your process space to Fsys’s
cache where the driver DMA’s it from. I have heard rumours of an ioctl
where the caller provides the physical address, and length of a buffer
and the driver DMA’s from there, but it may just be a rumour. QSSL
would be the only ones to answer this.

Rennie

6

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.

  1. 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.

  2. 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

7

What if you open() with various flag to disable caching.

As Harold Ramis said in Ghostbusters… “That would be bad”.

There is no advantage to disabling caching (from a performance P.O.V.)
when you are doing a copy anyway (might as well get the performance
advantage of gather(ed) DMA to the media - better blocking - if you’ve
already paid the price by doing the copy into cache), and if you could
use some sort of an ioctl to the driver, to DMA directly to the drive,
then your obviously not using the cache anyway (you wouldn’t be using
any part of Fsys at all).

Rennie “don’t cross the streams” Allen

8

Mario Charest wrote:

What if you open() with various flag to disable caching.
don’t remember the flag by heart.

What if you write directly to a reserved partition:
open ( “/dev/hd0.079”, …) , never tried it myself.

Thanks Mario -
I just double-checked <fcntl.h>, <ioctl.h>, <sys/disk.h>,
<sys/fsys.h>,
<sys/ioctl.h>, and <sys/qioctl.h> - I don’t see anything
promising…documented, anyway…

Actually, I use “/dev/hd2.0t10”, but I could use “/dev/hd2.0” in a
pinch, if it would make a difference.

Phil Olynyk

9

“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.

  1. 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.

  2. 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 -

  1. 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…

  2. 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

10

Rennie Allen wrote:

all -
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
Seagate doc.

You don’t give any details about the rest of your application.

This part is just a tiny test, no useless application overhead :slight_smile:
besides I’m not sure the client wants too much detail published just yet :slight_smile:

Where are you getting the data to copy to the drive, and what DTR is
that capable of ? It’s a Matrox Genesis LC frame grabber in the app, but
just a big empty buffer for the test.

Are you doing any manipulation (i.e. copies in your code) ? Not here.

What speed is your processor ? P2 233MHz

What speed is your PCI bus, and can both the frame grabber and the
2940UW make full use of that bandwidth ? 33MHz, 32 bits, and AFAIK, yes


Have you checked the latency timers on other PCI boards on the bus ?
Are you setting the sync flag on the fd ? I’ll try the D_SYNC flag on the
open() tomorrow…

My guess is that 15 MB/sec should be possible if the hardware is
capable of 40MB/sec and there are no copies occuring in your code. This
means that your code would have to DMA from frame grabber into buffer,
and then block_write that buffer (without any intervening copies)
directly to disk. In fact, there is one copy occuring here since the
kernel copies the block_write message from your process space to Fsys’s
cache where the driver DMA’s it from. I have heard rumours of an ioctl
where the caller provides the physical address, and length of a buffer
and the driver DMA’s from there, but it may just be a rumour. QSSL
would be the only ones to answer this.

Yep, I keep hoping to hear from them here!

Rennie

Thanks, Rennie -
Phil Olynyk

11

Hi Phil

Try open() and read()/write() instead of fopen() and fread()/fwrite().

  1. Yes, definitely don’t use both busses (on the same controller) at the
    same time for performance testing.

  2. With QNX’s Fsys cacheing the stream buffereing of the f*() functions
    won’t buy you anything and may actually cost you slightly. But I wouldn’t
    have thought that much.

Bill Caroselli


“Phil Olynyk” <pholynyk@home.com> wrote in message
news:3B79A040.49392CE5@home.com…

  1. 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…

  2. 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

12

Previously, Phil Olynyk wrote in qdn.public.qnx4.devtools:

Hmm, it is a 68 pin cable, so it never occurred to me that it wouldn’t do 16
bit async.
I’d hate to have to actually read the real scsi spec, but all my scsi books
are older than UW…> :slight_smile:

SCSI works on the basis of a backward compatibility. The
default transfer mode is Async 8bit. Then you usually go to
a SYNC transfer which can go up to 5Mhz. The next step up
is called Fast, which runs up to 10Mhz for Sync transfers.
The next step is to either go Fast Wide which is 16bit
wide, or to Ultra at 8bit. Both of these have a 20MByte
maximum throughput. The final step, Ultra and Wide gives
you the 40Mbyte mentioned with the drive.

It is 10,000 rpm… gee, 15MB/sec would be nice!

15MByte or more is what you should expect with this drive.

And if too long, they shouldn’t be coiled up, I’ll bet! I’d better check that!

I don’t think it matters. Interestingly I think that they can’t be too short
either. I recall three feet or something being a lower limit, however that
was back in the days when 10Mhz was the max speed.

Termination is supposed to be internal on the Cheetah drives, so presumably
not a problem…

Hmmmmm, well there is a really weird and strange problem
that I read about on Iomega’s board once. Take the rest of
what I’m saying with a pile of salt, but I think that there
was a problem with Ultra 2 drives. Here’s the idea. Ultra
2 drives have something special about them, maybe they are
differential. There’s something called LVD which you might
want to search for on the web. Anyway, I think that there
was a backward compatibility problem with LVD or U2 drives.
This problem was solved, but the result was that if you don’t
terminate properly, you might be running at a much slower rate.
Check it out.

It’s a 233Mhz P2. Maybe I’m on the ragged edge?
Can I bypass Fsys overhead with a blockwrite???

You could run using Blkfsys. This is tricky if you don’t
have a network. There are ways to run both Blkfsys and
Fsys, although this usually precludes the use of the SCSI
adapter for QNX file systems. That is you’d probably need
to boot off of an EIDE.

I’d be surprised if the 233Mhz P2 was the bottleneck, but you
aught to be able to eliminate this with a test.

I’m still betting on the cables and termination being the problem.

Mitchell Schoenbrun --------- maschoen@pobox.com

13

Hello Kevin Chiles

Are you reading this?

“Phil Olynyk” <pholynyk@home.com> wrote in message
news:3B79A30F.62F086DA@home.com…

Rennie Allen wrote:
My guess is that 15 MB/sec should be possible if the hardware is
capable of 40MB/sec and there are no copies occuring in your code. This
means that your code would have to DMA from frame grabber into buffer,
and then block_write that buffer (without any intervening copies)
directly to disk. In fact, there is one copy occuring here since the
kernel copies the block_write message from your process space to Fsys’s
cache where the driver DMA’s it from. I have heard rumours of an ioctl
where the caller provides the physical address, and length of a buffer
and the driver DMA’s from there, but it may just be a rumour. QSSL
would be the only ones to answer this.

Yep, I keep hoping to hear from them here!

14

previously, Phil Olynyk wrote in qdn.public.qnx4.devtools:

  1. 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…

Ok, so here there is plenty of room for trouble. First, if
this is the same card that I have, there are three
connectors, a 68pin external, a 68pin internal, and a 50pin
internal. Since it is all one bus, you can only use two at
a time. To use the 50pin and the 68pin I believe that you need
to have partial termination turned on in the card. This may
happen automatically. You also need termination on the Zip
turned on. Even so, I would test with the Zip removed.

I will try DSYNC on my open, it can’t hurt, since all my other (real app)
activity is in other tasks.

I suspect that DSYNC will hurt performance, not help it.

Mitchell Schoenbrun --------- maschoen@pobox.com

15

Does the SCSI driver offer DMA?
I know that for QNX4 the IDE driver does not use DMA, hence it’s
processor bound. There was a discussion around this issue
some time ago either here or on comp.os.qnx.


On Tue, 14 Aug 2001 18:15:43 -0400, Phil Olynyk <pholynyk@home.com> wrote:

Rennie Allen wrote:

all -
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
Seagate doc.

You don’t give any details about the rest of your application.

This part is just a tiny test, no useless application overhead > :slight_smile:
besides I’m not sure the client wants too much detail published just yet > :slight_smile:



Where are you getting the data to copy to the drive, and what DTR is
that capable of ? It’s a Matrox Genesis LC frame grabber in the app, but
just a big empty buffer for the test.

Are you doing any manipulation (i.e. copies in your code) ? Not here.

What speed is your processor ? P2 233MHz

What speed is your PCI bus, and can both the frame grabber and the
2940UW make full use of that bandwidth ? 33MHz, 32 bits, and AFAIK, yes


Have you checked the latency timers on other PCI boards on the bus ?
Are you setting the sync flag on the fd ? I’ll try the D_SYNC flag on the
open() tomorrow…

My guess is that 15 MB/sec should be possible if the hardware is
capable of 40MB/sec and there are no copies occuring in your code. This
means that your code would have to DMA from frame grabber into buffer,
and then block_write that buffer (without any intervening copies)
directly to disk. In fact, there is one copy occuring here since the
kernel copies the block_write message from your process space to Fsys’s
cache where the driver DMA’s it from. I have heard rumours of an ioctl
where the caller provides the physical address, and length of a buffer
and the driver DMA’s from there, but it may just be a rumour. QSSL
would be the only ones to answer this.

Yep, I keep hoping to hear from them here!



Rennie

Thanks, Rennie -
Phil Olynyk

16

Previously, Alex Cellarius wrote in qdn.public.qnx4.devtools:

Does the SCSI driver offer DMA?
I know that for QNX4 the IDE driver does not use DMA, hence it’s
processor bound. There was a discussion around this issue
some time ago either here or on comp.os.qnx.

The 2940 series of Adaptec cards all do DMA bus mastering.
There is no PIO option.

Mitchell Schoenbrun --------- maschoen@pobox.com

17

Hi Phil,

What happens if you specify -F 1

Could you post the output of cp -V to and from either /dev/shmem
or a ram disk?

Thanks

Erick.

Phil Olynyk <pholynyk@home.com> wrote:

Hi all -
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
Seagate doc.
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 > :frowning:

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 )

Thanks -
Phil Olynyk
OBT Software Corp.

18

Hi Erick -
Sorry this has been delayed, I got sidetracked by some other suggestions.

Trying to specify -F 1 gives me the same result as trying any other
aha8scsi option:
Error processing arguments for ‘aha8scsi’ module

So, clearly, I don’t know how to specify options! And no one has given any
suggestions that amplify on the documentation…

Since there seems to be a huge cache on a 256Mbyte system, I will write a
simple program to make a big /dev/shmem/foobar.dat, since I don’t really want
to build a new .boot file for a big ramdisk. I think I will need to make my
foobar.dat about 80Mb large. I will try various sizes to see if I can
determine a lower bound on long transfers. This will have to wait until I get
back to the client site, probably tomorrow.

Thanks - Phil Olynyk

Hardware Support Account wrote:

Hi Phil,

What happens if you specify -F 1

Could you post the output of cp -V to and from either /dev/shmem
or a ram disk?

Thanks

Erick.

Phil Olynyk <> pholynyk@home.com> > wrote:
Hi all -
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
Seagate doc.
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 > :frowning:

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 )

Thanks -
Phil Olynyk
OBT Software Corp.

19

Hi Phil

If you need a large ramdisk on the fly look at the vdir utility in the
latest distribution of QNX.

Bill Caroselli

“Phil Olynyk” <pholynyk@home.com> wrote in message
news:3B83BDB1.68A6B16B@home.com…

Hi Erick -
Sorry this has been delayed, I got sidetracked by some other
suggestions.

Trying to specify -F 1 gives me the same result as trying any other
aha8scsi option:
Error processing arguments for ‘aha8scsi’ module

So, clearly, I don’t know how to specify options! And no one has given any
suggestions that amplify on the documentation…

Since there seems to be a huge cache on a 256Mbyte system, I will write a
simple program to make a big /dev/shmem/foobar.dat, since I don’t really
want
to build a new .boot file for a big ramdisk. I think I will need to make
my
foobar.dat about 80Mb large. I will try various sizes to see if I can
determine a lower bound on long transfers. This will have to wait until I
get
back to the client site, probably tomorrow.

Thanks - Phil Olynyk

Hardware Support Account wrote:

Hi Phil,

What happens if you specify -F 1

Could you post the output of cp -V to and from either /dev/shmem
or a ram disk?

Thanks

Erick.

Phil Olynyk <> pholynyk@home.com> > wrote:
Hi all -
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
Seagate doc.
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 > :frowning:

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 )

Thanks -
Phil Olynyk
OBT Software Corp.

20

Or as we do (without rebuilding a boot image)

Fsys -c4k -r16M -NFSYS2 &
dinit /dev/ram
mount /dev/ram /ram
touch /ram/.boot /ram/.altboot

This will create it “on the fly” without running into anything else and
handles the issue
with older fsys’s that reserved the first 4 entries.

Jay

“Bill Caroselli (Q-TPS)” <qtps@earthlink.net> wrote in message
news:9m0foo$jci$1@inn.qnx.com…

Hi Phil

If you need a large ramdisk on the fly look at the vdir utility in the
latest distribution of QNX.

Bill Caroselli

“Phil Olynyk” <> pholynyk@home.com> > wrote in message
news:> 3B83BDB1.68A6B16B@home.com> …
Hi Erick -
Sorry this has been delayed, I got sidetracked by some other
suggestions.

Trying to specify -F 1 gives me the same result as trying any other
aha8scsi option:
Error processing arguments for ‘aha8scsi’ module

So, clearly, I don’t know how to specify options! And no one has given
any
suggestions that amplify on the documentation…

Since there seems to be a huge cache on a 256Mbyte system, I will write
a
simple program to make a big /dev/shmem/foobar.dat, since I don’t really
want
to build a new .boot file for a big ramdisk. I think I will need to make
my
foobar.dat about 80Mb large. I will try various sizes to see if I can
determine a lower bound on long transfers. This will have to wait until
I
get
back to the client site, probably tomorrow.

Thanks - Phil Olynyk

Hardware Support Account wrote:

Hi Phil,

What happens if you specify -F 1

Could you post the output of cp -V to and from either /dev/shmem
or a ram disk?

Thanks

Erick.

Phil Olynyk <> pholynyk@home.com> > wrote:
Hi all -
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
Seagate doc.
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 > :frowning:

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 )

Thanks -
Phil Olynyk
OBT Software Corp.