Scheduling overhead in RTP 6.1

I have a question regarding the scheduler. I have a process with about 350
threads. Of these threads only about 15 are actively communicating reading
data from a server via IPC and relaying that message to a client on a TCP
socket. The others are waiting for messages from another process via IPC to
send this data to the same client via TCP socket. The memory utilization is
near 75% when viewed by spin. It appears that procnto (the kernel?) is
using 45% of the CPU time.

Can anyone tell me if the scheduling overhead is proportional to the number
of threads?
Is there anything that can be done to decrease the impact of having this
many threads in the system?

Thanks in advance.

Tim

“Tim Bochenek” <tim.bochenek@bepco.com> wrote in
news:a6nrmk$ea9$1@inn.qnx.com:

I have a question regarding the scheduler. I have a process with about
350 threads. Of these threads only about 15 are actively communicating
reading data from a server via IPC and relaying that message to a
client on a TCP socket. The others are waiting for messages from
another process via IPC to send this data to the same client via TCP
socket. The memory utilization is near 75% when viewed by spin. It
appears that procnto (the kernel?) is using 45% of the CPU time.

Can anyone tell me if the scheduling overhead is proportional to the
number of threads?
Is there anything that can be done to decrease the impact of having
this many threads in the system?

Please don’t cross post, thanks.

-Adam

I believe the spin output would be a little misleading since spin must be
constantly asking procnto for the information and therefore causing procnto
to take up much more cpu time than it would during normal use.

“Tim Bochenek” <tim.bochenek@bepco.com> wrote in message
news:a6nrmk$ea9$1@inn.qnx.com

I have a question regarding the scheduler. I have a process with about
350
threads. Of these threads only about 15 are actively communicating
reading
data from a server via IPC and relaying that message to a client on a TCP
socket. The others are waiting for messages from another process via IPC
to
send this data to the same client via TCP socket. The memory utilization
is
near 75% when viewed by spin. It appears that procnto (the kernel?) is
using 45% of the CPU time.

Can anyone tell me if the scheduling overhead is proportional to the
number
of threads?
Is there anything that can be done to decrease the impact of having this
many threads in the system?

Thanks in advance.

Tim

spin takes about 1% of cpu time. There appears to be a direct relationship
between the number of threads (95% blocked) and message latency. I have a
performance decrease of a factor of 2.65 when there are 200 blocked threads
waiting for data to come in on an IPC channel over the case where I do not
have these extra threads. It appears that relationship is also exponential
when comparing 0, 50, 100, and 200 idle threads. So when if I have 300 idle
I may pay the price with a factor of 5 or 6? I hope I am missing something
and that the scheduler is not punishing my system because I have a server
with so many blocked threads.

“Dwayne Nelson” <nelsond@intgame.com> wrote in message
news:a6qq1f$ju5$1@inn.qnx.com

I believe the spin output would be a little misleading since spin must be
constantly asking procnto for the information and therefore causing
procnto
to take up much more cpu time than it would during normal use.

“Tim Bochenek” <> tim.bochenek@bepco.com> > wrote in message
news:a6nrmk$ea9$> 1@inn.qnx.com> …
I have a question regarding the scheduler. I have a process with about
350
threads. Of these threads only about 15 are actively communicating
reading
data from a server via IPC and relaying that message to a client on a
TCP
socket. The others are waiting for messages from another process via
IPC
to
send this data to the same client via TCP socket. The memory
utilization
is
near 75% when viewed by spin. It appears that procnto (the kernel?) is
using 45% of the CPU time.

Can anyone tell me if the scheduling overhead is proportional to the
number
of threads?
Is there anything that can be done to decrease the impact of having this
many threads in the system?

Thanks in advance.

Tim
\

2 things come to mind. First, I believe spin will show idle time as time
spent in procnto. If your threads are all receive blocked, the idle time
must be consumed. That could account for the percentage. I would also
point out that while spin may only be taking 1% of the time, it could be
causing procnto to be taking more time.

“Tim Bochenek” <tim.bochenek@bepco.com> wrote in message
news:a6qtu0$mlq$1@inn.qnx.com

spin takes about 1% of cpu time. There appears to be a direct
relationship
between the number of threads (95% blocked) and message latency. I have a
performance decrease of a factor of 2.65 when there are 200 blocked
threads
waiting for data to come in on an IPC channel over the case where I do not
have these extra threads. It appears that relationship is also
exponential
when comparing 0, 50, 100, and 200 idle threads. So when if I have 300
idle
I may pay the price with a factor of 5 or 6? I hope I am missing
something
and that the scheduler is not punishing my system because I have a server
with so many blocked threads.

“Dwayne Nelson” <> nelsond@intgame.com> > wrote in message
news:a6qq1f$ju5$> 1@inn.qnx.com> …
I believe the spin output would be a little misleading since spin must
be
constantly asking procnto for the information and therefore causing
procnto
to take up much more cpu time than it would during normal use.

“Tim Bochenek” <> tim.bochenek@bepco.com> > wrote in message
news:a6nrmk$ea9$> 1@inn.qnx.com> …
I have a question regarding the scheduler. I have a process with
about
350
threads. Of these threads only about 15 are actively communicating
reading
data from a server via IPC and relaying that message to a client on a
TCP
socket. The others are waiting for messages from another process via
IPC
to
send this data to the same client via TCP socket. The memory
utilization
is
near 75% when viewed by spin. It appears that procnto (the kernel?)
is
using 45% of the CPU time.

Can anyone tell me if the scheduling overhead is proportional to the
number
of threads?
Is there anything that can be done to decrease the impact of having
this
many threads in the system?

Thanks in advance.

Tim


\

Yes, spin does tax the system quite a bit (I have some speed optimisations
in mind btw). With default refresh rate its impact is reasonably small,
usually like few percent. That should not make the load average figure very
inaccurate though. That figure includes overhead of spin and you can see
that very easily if you increase the refresh rate.

Returnnig to subject, I believe the independent report mentioned on QNX home
page included analysis on the impact of number of scheduled objects on
scheduling latency. AFAIR, they did not find anything like that and rather
praised QNX for being very good in that area.

  • igor

“Dwayne Nelson” <nelsond@intgame.com> wrote in message
news:a6r87b$65$1@inn.qnx.com

2 things come to mind. First, I believe spin will show idle time as time
spent in procnto. If your threads are all receive blocked, the idle time
must be consumed. That could account for the percentage. I would also
point out that while spin may only be taking 1% of the time, it could be
causing procnto to be taking more time.

“Tim Bochenek” <> tim.bochenek@bepco.com> > wrote in message
news:a6qtu0$mlq$> 1@inn.qnx.com> …
spin takes about 1% of cpu time. There appears to be a direct
relationship
between the number of threads (95% blocked) and message latency. I have
a
performance decrease of a factor of 2.65 when there are 200 blocked
threads
waiting for data to come in on an IPC channel over the case where I do
not
have these extra threads. It appears that relationship is also
exponential
when comparing 0, 50, 100, and 200 idle threads. So when if I have 300
idle
I may pay the price with a factor of 5 or 6? I hope I am missing
something
and that the scheduler is not punishing my system because I have a
server
with so many blocked threads.

“Dwayne Nelson” <> nelsond@intgame.com> > wrote in message
news:a6qq1f$ju5$> 1@inn.qnx.com> …
I believe the spin output would be a little misleading since spin must
be
constantly asking procnto for the information and therefore causing
procnto
to take up much more cpu time than it would during normal use.

“Tim Bochenek” <> tim.bochenek@bepco.com> > wrote in message
news:a6nrmk$ea9$> 1@inn.qnx.com> …
I have a question regarding the scheduler. I have a process with
about
350
threads. Of these threads only about 15 are actively communicating
reading
data from a server via IPC and relaying that message to a client on
a
TCP
socket. The others are waiting for messages from another process
via
IPC
to
send this data to the same client via TCP socket. The memory
utilization
is
near 75% when viewed by spin. It appears that procnto (the kernel?)
is
using 45% of the CPU time.

Can anyone tell me if the scheduling overhead is proportional to the
number
of threads?
Is there anything that can be done to decrease the impact of having
this
many threads in the system?

Thanks in advance.

Tim




\

“Igor Kovalenko” <kovalenko@home.com> wrote in message news:a6s8q5$l6q$1@inn.qnx.com

Yes, spin does tax the system quite a bit (I have some speed optimisations
in mind btw). With default refresh rate its impact is reasonably small,
usually like few percent. That should not make the load average figure very
inaccurate though. That figure includes overhead of spin and you can see
that very easily if you increase the refresh rate.

Returnnig to subject, I believe the independent report mentioned on QNX home
page included analysis on the impact of number of scheduled objects on
scheduling latency. AFAIR, they did not find anything like that and rather
praised QNX for being very good in that area.

  • igor

Igor- how do I obtain ‘spin’? The link you specify in previous posts doesnt work anymore,
and your
personal email address is an old “@home.com” address.

“Art Hays” <avhays@nih.gov> wrote in message
news:a6sg3n$qup$1@inn.qnx.com

“Igor Kovalenko” <> kovalenko@home.com> > wrote in message
news:a6s8q5$l6q$> 1@inn.qnx.com> …
Yes, spin does tax the system quite a bit (I have some speed
optimisations
in mind btw). With default refresh rate its impact is reasonably small,
usually like few percent. That should not make the load average figure
very
inaccurate though. That figure includes overhead of spin and you can see
that very easily if you increase the refresh rate.

Returnnig to subject, I believe the independent report mentioned on QNX
home
page included analysis on the impact of number of scheduled objects on
scheduling latency. AFAIR, they did not find anything like that and
rather
praised QNX for being very good in that area.

  • igor

Igor- how do I obtain ‘spin’? The link you specify in previous posts
doesnt work anymore,
and your
personal email address is an old “@home.com” address.

Ahh, dammit! Forgot to change properties on this account :wink:
Just change @home to @attbi - that’s what it became. Likewise, the URL for
SPIN home page is http://home.attbi.com/~kovalenko/qnx/spin. It is now even
linked on QNXZONE page (last in the list of QNX sites).

– igor

“Igor Kovalenko” <kovalenko@attbi.com> wrote in message news:a6t2l6$b9d$1@inn.qnx.com

Igor- how do I obtain ‘spin’? The link you specify in previous posts
doesnt work anymore,
and your
personal email address is an old “@home.com” address.


Ahh, dammit! Forgot to change properties on this account > :wink:
Just change @home to @attbi - that’s what it became. Likewise, the URL for
SPIN home page is > http://home.attbi.com/~kovalenko/qnx/spin> . It is now even
linked on QNXZONE page (last in the list of QNX sites).

– igor

Thanks! (I hope you are running faster on your new attbi.com than I am on my new
comcast.net :slight_smile:)