Can we get a rough idea of the maximum number of queued pulses, e.g., as
referred to in the MsgSendPulse() documentation? It specifies that
there is a limit, and EAGAIN will be returned if the limit is exceeded,
but there is no indication of what that limit might be.
Thanks,
lew
Lewis Donzis <lew@nospam.donzis.com> wrote:
Can we get a rough idea of the maximum number of queued pulses, e.g., as
referred to in the MsgSendPulse() documentation? It specifies that
there is a limit, and EAGAIN will be returned if the limit is exceeded,
but there is no indication of what that limit might be.
There’s no hard limit - EAGAIN appears when there’s no more memory
to store the pulse data.
We currently have a problem where lots of pulses/messages pending on a
channel causes latency issues in the kernel - it’s in the queue to be
fixed for the next release.
–
Brian Stecher (bstecher@qnx.com) QNX Software Systems, Ltd.
phone: +1 (613) 591-0931 (voice) 175 Terence Matthews Cr.
+1 (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8
Might we also get a QNX4 CReceive() like function to dequeue specific pulses
without blocking?
“Brian Stecher” <bstecher@qnx.com> wrote in message
news:b718jf$df8$1@nntp.qnx.com…
Lewis Donzis <> lew@nospam.donzis.com> > wrote:
Can we get a rough idea of the maximum number of queued pulses, e.g., as
referred to in the MsgSendPulse() documentation? It specifies that
there is a limit, and EAGAIN will be returned if the limit is exceeded,
but there is no indication of what that limit might be.There’s no hard limit - EAGAIN appears when there’s no more memory
to store the pulse data.We currently have a problem where lots of pulses/messages pending on a
channel causes latency issues in the kernel - it’s in the queue to be
fixed for the next release.–
Brian Stecher (> bstecher@qnx.com> ) QNX Software Systems, Ltd.
phone: +1 (613) 591-0931 (voice) 175 Terence Matthews Cr.
+1 (613) 591-3579 (fax) Kanata, Ontario, Canada K2M
1W8
Brown, Richard brownr_aecl_ca@127.0.0.1 wrote:
Might we also get a QNX4 CReceive() like function to dequeue specific pulses
without blocking?
Specific pulses? No. You can get some of the functionality right now
by using TimerTimeout() with a zero length relative timeout to get the
non-blocking aspect, and MsgReceivePulse() to get the receive only
pulses behaviour.
Just thinking about it, you can get the specific pulses in a grotty
manner by creating multiple channels and sending the pulses on them
individually…
–
Brian Stecher (bstecher@qnx.com) QNX Software Systems, Ltd.
phone: +1 (613) 591-0931 (voice) 175 Terence Matthews Cr.
+1 (613) 591-3579 (fax) Kanata, Ontario, Canada K2M 1W8
Lewis Donzis <lew@nospam.donzis.com> wrote:
Can we get a rough idea of the maximum number of queued pulses, e.g., as
referred to in the MsgSendPulse() documentation? It specifies that
there is a limit, and EAGAIN will be returned if the limit is exceeded,
but there is no indication of what that limit might be.
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.
QNX Training Services
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
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 can
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! 
Thanks,
lew
Lewis Donzis <lew@nospam.donzis.com> 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 can
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 compression,
so that if you receive the same pulse over and over it will simply increment
a count 
Cheers,
-RK
–
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.
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 set
up to send pulses, then I quit using it. Unfortunately, I didn’t get rid of
the timer, just the MsgRecvPulse function. The pulses, identical I believe,
queued up in the kernel. After serveral hours of operation, the system just
wasn’t usable. That was reflected in the non-deterministic way interrupts
were handled. I think the kernel must try and deliver each pulse in the
queue on every tick. Hopefully, I have misunderstood your intent.
Regards,
David Kuechenmeister
“Robert Krten” <rk@parse.com> wrote in message
news:b76c9q$lkg$1@inn.qnx.com…
Lewis Donzis <> lew@nospam.donzis.com> > 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 can
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 compression,
so that if you receive the same pulse over and over it will simply
increment
a count >Cheers,
-RK–
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> .
David Kuechenmeister <david.kuechenmeister@viasat.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 set
up to send pulses, then I quit using it. Unfortunately, I didn’t get rid of
the timer, just the MsgRecvPulse function. The pulses, identical I believe,
queued up in the kernel. After serveral hours of operation, the system just
wasn’t usable. That was reflected in the non-deterministic way interrupts
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.
There is an open problem report (PR) against this.
-David
Regards,
David Kuechenmeister“Robert Krten” <> rk@parse.com> > wrote in message
news:b76c9q$lkg$> 1@inn.qnx.com> …
Lewis Donzis <> lew@nospam.donzis.com> > 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 can
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 compression,
so that if you receive the same pulse over and over it will simply
increment
a count >Cheers,
-RK–
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
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.
“David Kuechenmeister” <david.kuechenmeister@viasat.com> wrote in message
news:b776v3$l5v$1@inn.qnx.com…
Hopefully, I have misunderstood your intent.
Certainly. We don’t really want to have millions of unserviced pulses! A
few dozen seems like plenty.
lew
David Gibbs <dagibbs@qnx.com> wrote in message
news:b77a39$ens$1@nntp.qnx.com…
David Kuechenmeister <> david.kuechenmeister@viasat.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
set
up to send pulses, then I quit using it. Unfortunately, I didn’t get rid
of
the timer, just the MsgRecvPulse function. The pulses, identical I
believe,
queued up in the kernel. After serveral hours of operation, the system
just
wasn’t usable. That was reflected in the non-deterministic way
interrupts
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.
-xtang
There is an open problem report (PR) against this.
-David
Regards,
David Kuechenmeister“Robert Krten” <> rk@parse.com> > wrote in message
news:b76c9q$lkg$> 1@inn.qnx.com> …
Lewis Donzis <> lew@nospam.donzis.com> > 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
can
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
compression,
so that if you receive the same pulse over and over it will simply
increment
a count >Cheers,
-RK–
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
http://www.qnx.com/support/training/
Please followup in this newsgroup if you have further questions.