David Gibbs <firstname.lastname@example.org> wrote in message
David Kuechenmeister <> email@example.com> > wrote:
You want 10 million pulses? Whoa…I think you are going to pay a big
performance penalty for that. As an example, I had set up a 50 Hz timer
up to send pulses, then I quit using it. Unfortunately, I didn’t get rid
the timer, just the MsgRecvPulse function. The pulses, identical I
queued up in the kernel. After serveral hours of operation, the system
wasn’t usable. That was reflected in the non-deterministic way
were handled. I think the kernel must try and deliver each pulse in the
queue on every tick. Hopefully, I have misunderstood your intent.
Not quite – on each tick, it en-queues the new pulse, and it walks the
queue to find the end where it can enqueue the pulse. It is this walking
of an unbounded queue which is getting in your way.
On the other hand, if all your pulse are the same, kernel “compress” by
increase an count on the queued entry, so there is no walk of the queue,
the the “deliever speed” is bounded on how soon your application could
come back do another MsgRecvPulse().
The problem start from sending “different pulse” in 50Hz frequency.
There is an open problem report (PR) against this.
“Robert Krten” <> firstname.lastname@example.org> > wrote in message
news:b76c9q$lkg$> email@example.com> …
Lewis Donzis <> firstname.lastname@example.org> > wrote:
David Gibbs wrote:
As others have said, this is dynamic.
If you want a very rough idea – look at the size of a
struct _pulse(). This is what is queued. (Though, there
are some optimisations, up to (I think) 255 pulses can
take one queue entry of size struct _pulse in many cases.)
Look at free memory available, divide free memory by
sizeof( struct _pulse) and you have a very rough idea.
Thanks, David – that’s what I was really looking for, i.e., that it
consume all available free memory.
So if a struct _pulse is ~20 bytes, and we have 200MB of free memory,
that means we could have roughly ten million queued pulses? OK, that
should be enough! >
Potencially way more – the kernel (last I heard) does pulse
so that if you receive the same pulse over and over it will simply
a count >
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training, Consulting and Software Products at > www.parse.com> .
QNX Training Services
Please followup in this newsgroup if you have further questions.