Dear QNX Masters, one question:
I have relative up-to-date PC HP (XY117EA) with fast industrial 32GB SLC SSD SATA HDD (innoDisk FiD 25000) with Fsys.atapi (heapsize memory -H disk100, IDE emulation in BIOS Setup of the PC).
When I am saving “picture” under Photon Application Builder (technological process scheme 1920x1200, hundreds of Widgets), mouse cursor “freezes” for long 6 seconds (as if the disk writing operation has very high priority and operation lasts so long time).
We have already made wide 1920x1200 schemes with hundreds of widgets and never noticed “freezing” of mouse cursor when saving. Even on SLC SSD disks (Intel X-25E, innoDisk, OCZ Vertex 2 EX…)
Is that some problem with newer Intel Chipsets and/or fast SATA disks with Fsys.atapi? Some parameters, buffers?
Did you anybody look behavior like that (6 seconds freezed mouse cursor while saving file with PhAB)?
Disk writing at a very high priority is unlikely to be the issue. Except for solid state devices, disk drivers spend most of their time waiting for a hardware interrupt. Even data transfer is usually off loaded to a DMA channel.
Well I think you are on to something here. Technically, Fsys.atapi does not support SATA (at least I don’t think it does). The way to get a SATA drive to work under QNX 4 is by using BIOS emulation. At that could well be the problem. For example, the driver would be in a hard loop waiting for a status that normally comes immediately, but in the emulation in your bios it might be waiting for the I/O to complete.
If this is the case, you might mitigate the problem by lowering Fsys’s priority, but that could cause other problems. You might find you are getting very slow disk response because the driver has to wait for other higher cpu bound processes to finish before even starting an I/O.
[/quote]
Under QNX 6.3.2 I have encountered some newer BIOS’s that even in IDE emulation mode don’t correctly handle the DMA requests from the QNX driver when it asks which DMA levels are supported. When this happens all my disk writes become CPU bound taking literally 100% of the CPU to do the writes because the driver thinks there is no DMA mode.
Sometimes I’ve been able to manually force a DMA mode using parameters to devb-eide. Not sure if you can do that in QNX4 Fsys.atapi but if that kind of option exists I’d try experimenting with it.
Worst case you’ll have to try other hardware. In one case I was only able to use the hardware with a QNX 6.5 devb-eide running under 6.3.2 (lucky it ran with no problems).
New info from the author of this topic:
The same 2,5" SATA SSD innoDisk FiD 25000 in another (new industrial PC with older Intel G41+ICH7R Chipset + Intel C2D E7600 CPU) works OK - fast machine with fast SSD.
So the problem with “freezing mouse cursor” for terrible 6 seconds while Generate/Make larger PhAB “picture” seems to have to do something with machine mainboard Chipset or BIOS or…, not (only) with the particular HDD.
Questions:
How to find out which Fsys (.eide or .atapi) is better for particular MB+HDD combination?
All my “Fsys.atapi atapi supported” “questions” on newer (SATA in generic IDE mode) machines answer:
No Adaptors Found!
How to find out what speed level (PIO, UDMA…) is currently used by Fsys.atapi?
How to force Fsys.atapi to communicate with HDD by DMA (or at least quickest possible way)?
What is the “generic” mode of communication to HDD if the HDD is unknown to Fsys.atapi?
Isn’t better to use some Fsys.eide mode (which parameters) than terrible “generic” mode of unknown HDD chipset of Fsys.atapi?
Has extremely long (2 minutes! HDD LED on as if QNX was scanning entire disk) QNX4 detection of large 500GB HDD (another my topic here) something to do with Fsys.atapi parameters too?
Not all large disks (500GB) on all machines are detected so a long time. Some older 500GB disk on older PC is detected OK with Fsys.atapi.
Seems that newer HDDs and/or newer MB (Chipsets, maybe Core i3,5,7?) cause the problem of extremely long QNX HDD detection time.
Please QNX masters, help if you have some working solutions.