FlashDisk access slow under QNX6

Hi all,

does anyone know how to improve the flash disk write times under QNX6
on a FlashDisk IDE Drive?

Under QNX4, I get write times close to the max write speed of the
drive; it copies 10MB on the drive in about 14secs. Under QNX6, on the
same hardware, the same tasks uses about 90 Seconds (!!!)

Why is the QNX6 access so much slower, since it uses the same
Filesystem (QNX4)? Are there any options to improve the speed (don’t
suggest cache sizes of 10 MB :wink:?

Any help is appreciated.

Greetins, Sven


Sven Fischer – DEUTA-Werke GmbH, Abteilung EIT
Dipl.-Phys. Paffrather Str. 140, 51465 Bergisch Gladbach, Germany
Tel.: +49-(0)2202-958-216 Fax.: +49-(0)2202-958-145
Please note the disclaimer: http://www.deutaeit.de/disclaimer.html

Sven Fischer <fischer@deutaeit.de> wrote:

does anyone know how to improve the flash disk write times under QNX6
on a FlashDisk IDE Drive?

You could try passing the options “lock,noatime” when you mount it
(this will stop it trying to periodically re-verify the removable
media but you’ll have to umount it yourself if you change it, and
won’t try and write back access times for file reading). If you
will be writing many large files you could also try “overalloc”.
Faking the medias as locked/non-removable will also allow a more
aggressive bitmap caching strategy (“rmvbmap” otherwise) and more
relaxed delayed writing (“blk rmvto=”). All these options are
described in the usage message of the relevant *.so libraries.

Under QNX4, I get write times close to the max write speed of the
drive; it copies 10MB on the drive in about 14secs. Under QNX6, on the
same hardware, the same tasks uses about 90 Seconds (!!!)

I’ve never seen writes to a flash device that fast (despite some
claims of around 1MB/sec I typically see half that - SanDisk quote
that DRQ may take 20ms to be asserted in the case of write with no
block reassignments, which is only 25KB/sec worst-case, or if
WRITE_MULTIPLE is supported for 16 blocks, then 400KB/sec), so I suspect
that your QNX4 data is still cached … did you use O_SYNC? That
said, although 14 secs seems “too fast”, 90 secs does seem “too slow”;
the math above would calculate 26 seconds to perform physical access.

If you invoke the devb-eide driver in verbose mode (“eide verbose=4”)
what does it claim to be using for transfer mode / max blocks / etc?

John Garvey <jgarvey@qnx.com> writes:

does anyone know how to improve the flash disk write times under QNX6
on a FlashDisk IDE Drive?

You could try passing the options “lock,noatime” when you mount it
(this will stop it trying to periodically re-verify the removable
media but you’ll have to umount it yourself if you change it, and
won’t try and write back access times for file reading). If you
will be writing many large files you could also try “overalloc”.
Faking the medias as locked/non-removable will also allow a more
aggressive bitmap caching strategy (“rmvbmap” otherwise) and more
relaxed delayed writing (“blk rmvto=”). All these options are
described in the usage message of the relevant *.so libraries.

It is no removable media, though. So I don’t think this helps much…

Under QNX4, I get write times close to the max write speed of the
drive; it copies 10MB on the drive in about 14secs. Under QNX6, on the
same hardware, the same tasks uses about 90 Seconds (!!!)

I’ve never seen writes to a flash device that fast (despite some
claims of around 1MB/sec I typically see half that - SanDisk quote
that DRQ may take 20ms to be asserted in the case of write with no
block reassignments, which is only 25KB/sec worst-case, or if
WRITE_MULTIPLE is supported for 16 blocks, then 400KB/sec), so I suspect
that your QNX4 data is still cached … did you use O_SYNC? That
said, although 14 secs seems “too fast”, 90 secs does seem “too slow”;
the math above would calculate 26 seconds to perform physical access.

Okay, your point. I indeed forgot the O_SYNC. So I get the same times
(90secs) under QNX4. Since it is a SiliconTech Disk (2.5" FlashDisk,
96Mb), is this a slow one?

If you invoke the devb-eide driver in verbose mode (“eide verbose=4”)
what does it claim to be using for transfer mode / max blocks / etc?

Transfer mode is PIO1 (urghs), is autodetected in BIOS. Even if I
change this to DMA1, devb-eide uses PIO1 (dma option is on).

Other parameters are

low 56320 / high 2 (what’s this?)
Multimode Blocks/Interrupt 1

The geometrical parameters are okay…

Thanks for the help, Sven


Sven Fischer – DEUTA-Werke GmbH, Abteilung EIT
Dipl.-Phys. Paffrather Str. 140, 51465 Bergisch Gladbach, Germany
Tel.: +49-(0)2202-958-216 Fax.: +49-(0)2202-958-145
Please note the disclaimer: http://www.deutaeit.de/disclaimer.html

Sven Fischer <fischer@deutaeit.de> wrote:

John Garvey <> jgarvey@qnx.com> > writes:

You could try passing the options “lock,noatime” when you mount it
(this will stop it trying to periodically re-verify the removable
It is no removable media, though. So I don’t think this helps much…

You mean because it is internal/on-the-board and not in a PCMCIA slot?
It doesn’t matter, the IDE controller on the flash card will be
reporting itself as a removable media regardless. This is the ideal
situation for the “lock” keyword (it will issue a SC_REMOVAL command,
which will be ignored by the driver, but which will then allow the
filesystem to use a different set of caching strategies, knowing
that the card is safe from unexpected ejection).

Under QNX4, I get write times close to the max write speed of the
drive; it copies 10MB on the drive in about 14secs. Under QNX6, on
the same hardware, the same tasks uses about 90 Seconds (!!!)
I’ve never seen writes to a flash device that fast (despite some
Okay, your point. I indeed forgot the O_SYNC. So I get the same times
(90secs) under QNX4. Since it is a SiliconTech Disk (2.5" FlashDisk,
96Mb), is this a slow one?

My point was that I didn’t think it was physically possible to get data
onto a flash card at that rate under either OS! As to how you want to
set up your application (“commit=none…high”, O_SYNC, fsync, nothing)
will depend on your performance/robustness requirements.

If you invoke the devb-eide driver in verbose mode (“eide verbose=4”)
what does it claim to be using for transfer mode / max blocks / etc?
Transfer mode is PIO1 (urghs), is autodetected in BIOS. Even if I
change this to DMA1, devb-eide uses PIO1 (dma option is on).
Multimode Blocks/Interrupt 1

I’m not aware of any flash disk cards that support DMA. Most are PIO 1,
1 blk/interrupt. The driver will use the WRITE_SECTORS command to set up
to transfer multiple blocks but will have to take an interrupt each block.
Flash disks are just not high-performance media.

Thanks for the help, Sven

As I posted first, the “lock,noatime” options should help.

John Garvey <jgarvey@qnx.com> writes:

Sven Fischer <> fischer@deutaeit.de> > wrote:
John Garvey <> jgarvey@qnx.com> > writes:

You could try passing the options “lock,noatime” when you mount it
(this will stop it trying to periodically re-verify the removable
It is no removable media, though. So I don’t think this helps much…

You mean because it is internal/on-the-board and not in a PCMCIA slot?
It doesn’t matter, the IDE controller on the flash card will be
reporting itself as a removable media regardless. This is the ideal
situation for the “lock” keyword (it will issue a SC_REMOVAL command,
which will be ignored by the driver, but which will then allow the
filesystem to use a different set of caching strategies, knowing
that the card is safe from unexpected ejection).

Maybe, but this doesn’t improve write speed since I don’t want caching
at all (secure data writing with O_SYNC). I have tested it though and
I got the same write times (around 90 secs).

My point was that I didn’t think it was physically possible to get data
onto a flash card at that rate under either OS! As to how you want to
set up your application (“commit=none…high”, O_SYNC, fsync, nothing)
will depend on your performance/robustness requirements.

Yes, but just getting a little more than 100 kB/sec seems to be very
slow. I am not possible to test it with others OSs right, but more
than 100 kB/sec should be possible…

I’m not aware of any flash disk cards that support DMA. Most are PIO 1,
1 blk/interrupt. The driver will use the WRITE_SECTORS command to set up
to transfer multiple blocks but will have to take an interrupt each block.
Flash disks are just not high-performance media.

Very helpful informationm, nevertheless.

Sven


Sven Fischer – DEUTA-Werke GmbH, Abteilung EIT
Dipl.-Phys. Paffrather Str. 140, 51465 Bergisch Gladbach, Germany
Tel.: +49-(0)2202-958-216 Fax.: +49-(0)2202-958-145
Please note the disclaimer: http://www.deutaeit.de/disclaimer.html

Sven Fischer <fischer@deutaeit.de> wrote:

Maybe, but this doesn’t improve write speed since I don’t want caching
at all (secure data writing with O_SYNC).

Yes, in normal situations these will help, but O_SYNC dominates everything
and negates all performance optimisations. Are you really sure you need
this level? There will be no block over-allocation and a synchronous
bitmap and inode update for every write() call, so if you are doing 4k
writes that is a 20% metadata overhead (8 blocks user data, 1 block
bitmap, 1 block inode) and your 10MB is effectively 12MB to write.
Larger writes (say 16-32k) will help this ratio. Or is it acceptable
for you to exploit some write-behind-merging by periodically (or just
before the close()) calling fsync() to force the data out to flash?

My point was that I didn’t think it was physically possible to get data
onto a flash card at that rate under either OS! As to how you want to
Yes, but just getting a little more than 100 kB/sec seems to be very

Well, with O_SYNC you may actually be writing 12MB, so this gives you
140 Kb/sec, which seems ballpark for a lot of single-block writes to
flash. If that’s with O_SYNC, then it is actually quite impressive.
I think if you were to try without O_SYNC but with a trailing fsync()
you would see this improve, and would be a worthwhile experiment …

Something else to remember is that different media behave very different.
I got 25kbyte/s from a IDE form factor flash drive and 165kbyte/s
from a CF connected via IDE.
Not sure if it’s possible for you to try, but FWIW…

John Garvey <jgarvey@qnx.com> wrote:

Transfer mode is PIO1 (urghs), is autodetected in BIOS. Even if I
change this to DMA1, devb-eide uses PIO1 (dma option is on).
Multimode Blocks/Interrupt 1
I’m not aware of any flash disk cards that support DMA. Most are PIO 1,
1 blk/interrupt. The driver will use the WRITE_SECTORS command to set up
to transfer multiple blocks but will have to take an interrupt each block.

For any others following this thread, as I was just reminded, in pre-6.2
devb-eide drivers the processing of multiple blocks (despite the drive
claims to only support 1 blk/interrupt) occurs only in “safe” mode,
otherwise the driver will do only single block operations to support
legacy controllers. So the “eide safe” option will also be needed to
see reasonable multi-blk performance; this option does not exist (is the
default) in QNX6.2 devb-eide drivers.