It has been said many bad words about QNX FS performance lately. Indeed,
in some cases performance was so bad that it could not be possibly
explained by any programming inefficiencies. So, I was determined to
figure the truth and after long painful investigation I have some
intersting and good news to tell.
I. SCSI write performance.
Read performance was good to begin with (20Mb/sec on Adaptec) so the
problem was with incredibly slow write (3Mb/sec) since Windows did much
better. Well, it turned out that the Evil OS has some way to control
on-drive write-behind buffers which are disabled by default. QNX drivers
can’t do that since it relies on SCSI BIOS entirely for chip
intialization, so write is unbuffered.
The good news is, latest version of Adaptec SCSI BIOS (2.57.2) allows
you to control those buffers from SCSI setup utility on per-drive basis.
Most 2940UW controllers were shipped with either 1.25 or 1.32 BIOS,
neither of which has that option so people simply are not aware of it.
If you’ve got one of those, go to Adaptec web site, download new BIOS,
reflash it, reboot and enter SCSI setup (Ctrl-A) and enable write-behind
buffer for your drives. Once that’s done QNX/RTP will give you 10+
MB/sec of sustained write speed on QNX filesystem. That’s very close to
Win2000 performance on the same hardware (it is almost the same on my
system).
Also keep in mind that you should not have non-ultra devices on ultra
bus, which is very likely to happen if you have anything else but hard
drives on your 2940UW.
II. EIDE and UDMA
There are 2 troubles here. First, they only support UDMA2, not UDMA4/5.
Second, that is worsened even more by common lack of knowledge about how
to set things up properly, so even UDMA2 often does not work even on
supported chipsets and you end up with pity 3Mb/sec again. Here are
common gotchas:
- Wrong cable. You need 80wire/40pin UDMA cable to use UDMA.
- Your chipset must support UDMA
- Your drive must support UDMA. Some drives (e.g. WD Caviar) may need
to be configured by DOS-based utility supplied with drive to support
UDMA. - You BIOS must initialize chipset into proper UDMA mode. Some BIOSes
(e.g., Award) will ask your drive about highest supported UDMA mode
(which will be 4 or 5 for modern drives) and attempt to initialize
chipset into those modes even if it only supports UDMA2 (e.g., Intel
82371AB aka PIIX4). That will fail and not even Evil OS will work in
UDMA mode afterwards. Yes, I’m lucky enough of own one of such boards. I
fixed it by disabling UDMA4 mode on the drive (using WD utility).
When all those issues are verified and everything is right, RTP will
give you about 10Mb/sec sustained read/write rate on modern hard drives
with Intel82371AB and SiS5513 chipsets I’ve tested. Windows may give you
more (30/read 20/write for 7200 Maxtor, 10/read 18/write for 5400 WD) on
a comparable benchmark (make sure to enable DMA on Windows, it is
disabled by default even there). Not sure why is that, may be there is
indeed some deficiency in EIDE driver, but that’s certainly is much
smaller gap now.
Keep in mind also that due to lack of unified FS/paging cache QNX can
not dynamically tune FS buffering parameters like most modern systems
do. I don’t know how much impact that has, but perhaps it has some.
III. Benchmarks.
That’s one biggest source for confusion. People keep comparing apples to
oranges. For my tests I used ‘cp -V huge_file /dev/null’ for read speed
and ‘cp -V /dev/shmem/huge_file /fs’ for write speed. Under Windows I
used ‘nbench’ utility which reads and writes sequential file of ‘huge’
size. I believe that’s very close to ‘cp’ and indeed I’ve got very close
values for SCSI performance on the same machine. Those values include FS
overhead and do not represent raw drive performance, but we don’t deal
with raw drives in real life anyway.
To summarize the above, there are no apparent bottlenecks in FS itself.
There may be some bottlenecks in EIDE driver, but may be not, this has
to be verified yet. There are unimplemented features like support for
UDMA4/5, UDMA on more modern chipsets and support for Sync/Wide SCSI
operations on all SCSI chipsets (like 53C875), but I believe that’s
being worked on and does not constitute ground for labeling system as
‘no-no’ for disk-intensive applications.
- igor
.
It was indeed quite a pain.