We are moving some code onto a dual Xeon processor machine on QNX 6.21, in a really short timeframe, not enough to rearchitect the threading or smp settings. To best take advantage of multiple processors, what QNX settings should be changed from the default install? This is scientific code that will run on this system for about a week for high performance calculations, then go back to the single processor system.
Only think to do OS wise is swith to SMP kernel. Unless your system use multiple process or thread that do want/can run concurantly you should see only very small difference.
However if possible you could start two instances of the applications and have them work on different set of data.
Personal opinion; for scientific stuff look at other OSes. Some offer better compiler; Intel compiler is freely available for non commercial purposes on Windows and I beleive Linux. Some will also make use of NEMA architecture which can yied improve performance for high memory bandwidth application.
If I split the software into two or more processes - how will QNX schedule these processes amongst the processors? (this is possible although we wouldn’t have time to do it on the thread level) Thanks for the tip…
I tried to enable smp support by using the following command, but this causes the system to lock up in the “hit esc for altboot” screen. Is there any other way to enable smp that will not cause it to lock?
cp /boot/fs/qnxbasesmp.ifs /.boot
I tried to enable smp by copying the file (below), but this locks up the system in the altboot screen. Is there any other way to enable smp that will not cause the system to lock? The processors at the 3.4Ghz Xeon Noconas.
cp /boot/fs/qnxbasesmp.ifs /.boot
With SMP, CPU becomes a resources the OS will try to make best use of. Hence it will assign a process to run on an available CPU, being a thread or a process. A process is in fact a program with a single thread
As for not booting. The motherboard must support SMP version 1.2 I think. Aside from that I don’t really have an idea. Try pressing space to go in verbose mode to try to figure out what is wrong. I beleive there was some bug in 6.2.1 concerning SMP and certain hardware config.
The boot get as far as showing a bunch of periods … to the end of the screen before it feezes, so it doesn’t get far enough for the space bar F6 verbose option.
I found a post from jjpedroza with a similar smp boot freeze, although his system went a further to the login screen -
I am using the vesa video driver, with 6.2.1B.
I tried disabling hyperthreading in the bios, and experimented with turning off other cpu options. I thought maybe I could find something in the bios to trick QNX into thinking this is an older machine.
The motherboard and CPUs are the latest available so they should have good support for SMP.
I dug this up from the release notes for 6.2.1B:
If you try to use the VESA driver on an SMP machine, your machine might spontaneously reboot.
This might not occur on all SMP boxes.(Ref# 15928, 16009)
As a workaround:
Make sure you’re using the proper video driver for your card.
If the problem persists, run the non-SMP version of procnto.
This was fixed in 6.3.0. I hope this helps.
The onboard chip is Rage, so I changed the video to Rage and it still hangs on smp boot. I wonder what the OS is doing at the time right after it says hit esc for .altboot…
Probably 6.2.1 does not like this motherboard/chip combination.
In verbose mode, right before freeze the following is displayed:
system page at
starting next program at vf000ef08
header size 0x009c
total size 0x0978
#cpu = 4 (disabling hyperthreading in bios shows 2)
type = 0
I doubt the video driver makes any difference as I don’t beleive the boot process even makes it there.
I seem to remember Rage/SMP/QNX6.2x has frequent lockups. Can you try to use the non-SMP image or try 6.3? Other people has SMP problems that got resolved by QNX 6.3.
I installed the 6.3 eval, and now SMP is working. I see the extra processors in the performance monitor. Thanks for the tips. I think that the hardware is newer than what 6.2.1 will handle.