“AGB” <agb32@nospam.remove.this.cam.ac.uk> wrote in message
news:3F85819C.8030801@nospam.remove.this.cam.ac.uk…
Thanks for patience! I’ve tried both of these… at >21 it still has
the same problem.
If I run the save data process without saving, it works perfectly.
Actually, I run it just saving a time stamp, and not the data, and the
timestamp is then always incremented at the correct amount between
frames… So it could be the shared memory access locks, but I would
have thought that on a strict real time system the high priority process
should always be able to run? If it is the problem with shared memory
access, how can I get around then? Maybe by writing smaller chunks of
data at a time? (currently 65536 bytes at a time)
First make sure the data is properly aligned when you sent it.
Watch for processes that may change priority. For example if your grabbing
process runs at prio 63 and send a message to “saving” program, it will
process the message at priority 63. If the program does a write() the
filesystem will process that message at priority 63 as well.
Grabber and harddisk both are PCI master device (DMA), they can hold the PCI
bus while transfering data. I’m not familiar enough with your hardware (or
the PCI spec for that matter) to determine if HD DMA activity can lock the
grabber, maybe you could try running the HD in NON DMA just to investigate
that avenue (you may have problem writting at 3M with non DMA)
Thanks.
Jens H Jorgensen wrote:
Well - it is a little hard to say what is going on.I think I would try to perform following experiements:
- Raise the priority of the capture thread/process beyond devb-eide (21)
- Run the save data process run but without writing to the disk to see
if
any shared memory access locks are holding up the capture process.
–
Jens
“AGB” <> agb32@nospam.remove.this.cam.ac.uk> > wrote in message
news:> 3F8578CD.2020305@nospam.remove.this.cam.ac.uk> …Hmm, well I’ve now successfully managed to change some of the harddrive
parameters using the script from Eduard – thanks – but it hasn’t
helped my application!I have a high priority process which is a frame grabber, grabbing data
into shared memory - which another lower priority process then writes to
disk when it has time (it doesn’t necessarily save the newest grabbed
data, ie a backlog can build up). However, I find that for some reason
the writing to disk slows down the higher priority process, and so
frames are missed - which is very bad news!!!I had thought that qnx would allow a higher priority process to have
priority, but it seems that the hardware (ie hard disk) is stopping the
grabbing process from writing to memory for a bit or something… and so
causing the grabbing process to skip frames.Comments?
Thanks.
Jens H Jorgensen wrote:
It is probably because you have the NC version.
I am not sure what you can do to solve this with the NC version -
anybody?
–
Jens
“AGB” <> agb32@nospam.remove.this.cam.ac.uk> > wrote in message
news:> 3F851A85.307@nospam.remove.this.cam.ac.uk> …
I had thought of doing this, but my 6.2.1 system doesn’t have a
/boot/build directory - the only things in /boot/ are sys/ and fs/.I had assumed that this was because the need for this had been removed
for 6.2.1 or something. Is there anywhere I can obtain a sample build
script which would be correct for my current install? (default 6.2.1
NC
install).Thanks.
Jens H Jorgensen wrote:
You would have to build a custom kernel image. Look in /boot/build for
sample build scripts.mkifs is used to compile these build scripts into kernel image files
(such
as .boot and .altboot)
Replace .altboot with the new kernel boot image and it ESC when boot
process
allows to boot alternative image.Jens
“AGB” <> agb32@nospam.remove.this.cam.ac.uk> > wrote in message
news:> 3F844B8B.1000609@nospam.remove.this.cam.ac.uk> …Thanks - where can I set these parameters? ie where is devb-eide
started?
Presumably, I cant stop and restart it (if I turn off the filesystem,
if
can’t load itself), so will have to reboot each time?Thanks.
Jens H Jorgensen wrote:
You can try to adjust some of the cache and commit parameters for
devb-eide.
For details go to:
http://www.qnx.com/developer/docs/momentics621_docs/neutrino/utilities/d/devb-eide.htmland
http://www.qnx.com/developer/docs/momentics621_docs/neutrino/utilities/i/io-blk.so.htmlParameters tgat you want to look at are:
cache=2m,noatime,delwri=0,commit=high
–
Jens
AGB wrote:
Hi,
I have an application which requires me to write about 3MB/s to disk
continuously. I have a modern harddrive, and am told the max data
rate
is over 100MB/s, so in theory I should have no problems. However, I
find that QNX seems to be writing data in clumps, ie very low cpu
activity for a few seconds, followed by high activity while writing
is
done. This high activity then causes problems as it slows down some
of
my processes. Is there any way to get QNX to write data regularly at
the (slow) 3MB/s rate as it is ready?Thanks.
\