Is there any way to get an accurate count of the number of CPU cycles spent
idling? I have a task that interrupts every milli-second so I’m not certain
the ‘pidin tt’ values are giving me totally accurate values. How is the
‘pidin tt’ time accounted? If the system has many threads that each run for
a fraction of the time quantum every quantum, how are they accounted?
Thanks,
Shaun
I would try writing a program that runs just above idle. Let it just count.
Make your system as idle as possible and see how fast it counts in a period
of time. Then run your system fully loaded and see how fast the counting
program runs. Divide and you have your duty cycle.
“Shaun Jackman” <sjackman@nospam.vortek.com> wrote in message
news:ak37dn$3pm$1@inn.qnx.com…
Is there any way to get an accurate count of the number of CPU cycles
spent
idling? I have a task that interrupts every milli-second so I’m not
certain
the ‘pidin tt’ values are giving me totally accurate values. How is the
‘pidin tt’ time accounted? If the system has many threads that each run
for
a fraction of the time quantum every quantum, how are they accounted?Thanks,
Shaun
Bill Caroselli (Q-TPS) <QTPS@EarthLink.net> wrote in message
news:ak3cij$77a$1@inn.qnx.com…
I would try writing a program that runs just above idle. Let it just
count.Make your system as idle as possible and see how fast it counts in a
period
of time. Then run your system fully loaded and see how fast the counting
program runs. Divide and you have your duty cycle.
Cheers,
Adam
With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
You could use ClockId() to get an accounting timer for the idle thread and
the system as a whole and compare them.
Shaun Jackman <sjackman@nospam.vortek.com> wrote:
Is there any way to get an accurate count of the number of CPU cycles spent
idling? I have a task that interrupts every milli-second so I’m not certain
the ‘pidin tt’ values are giving me totally accurate values. How is the
‘pidin tt’ time accounted? If the system has many threads that each run for
a fraction of the time quantum every quantum, how are they accounted?Thanks,
Shaun
–
cburgess@qnx.com
Shaun Jackman <sjackman@nospam.vortek.com> wrote:
Is there any way to get an accurate count of the number of CPU cycles spent
idling? I have a task that interrupts every milli-second so I’m not certain
the ‘pidin tt’ values are giving me totally accurate values. How is the
‘pidin tt’ time accounted? If the system has many threads that each run for
a fraction of the time quantum every quantum, how are they accounted?
http://qnx.wox.org/qnx/sources/load-src.tar.gz
It queries the idle thread for the amount of time it is has spent running
and comapres that to the time elapsed to generate a CPU load. Easily
changed to get any other calculation of information you want.
chris
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Shaun Jackman wrote:
Is there any way to get an accurate count of the number of CPU cycles spent
idling? I have a task that interrupts every milli-second so I’m not certain
the ‘pidin tt’ values are giving me totally accurate values. How is the
‘pidin tt’ time accounted? If the system has many threads that each run for
a fraction of the time quantum every quantum, how are they accounted?
Back in the days I programmed under the RMX RTOS, our system had a rather simple
non-invasive and mostly system independent method for measuring CPU load:
You create a procces/thread with the lowest possible priority [1], that does
nothing except sleep for the size of the system time-slice, and then measure how
much time actually passed since last interation of the loop.
The system load is the log() of the actual interval compared to the expected
interval: If you set the interval to 100ms, and this in the interval you get, then
your system is doing nothing else.
Shmuel Kahn
Hoping I remember all the details correctly 
[1] It is important that NOTHING else run at this lowest priority.
John A. Murphy <murf@perftech.com> wrote:
Fascinating code! It seems to “know” that the process manager is always pid 1,
and that the first N tids in that process are the idle threads for the N CPUs in
the system. Is that knowledge reflected in a header file, or in some other form
of documentation somewhere, or do you just have to “know”?
Process manager is always pid 1; that’s a “well known fact”, and is relied
upon by a lot of stuff…
I’d volunteer that you could just look at the priorities of all tids of pid 1,
anything that has a priority of zero is an idle thread, 'cuz nothing else is
allowed to run at priority zero
Cheers,
-RK
Murf
Chris McKillop wrote:
Shaun Jackman <> sjackman@nospam.vortek.com> > wrote:
Is there any way to get an accurate count of the number of CPU cycles spent
idling? I have a task that interrupts every milli-second so I’m not certain
the ‘pidin tt’ values are giving me totally accurate values. How is the
‘pidin tt’ time accounted? If the system has many threads that each run for
a fraction of the time quantum every quantum, how are they accounted?
http://qnx.wox.org/qnx/sources/load-src.tar.gzIt queries the idle thread for the amount of time it is has spent running
and comapres that to the time elapsed to generate a CPU load. Easily
changed to get any other calculation of information you want.chris
–
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at www.parse.com.
Email my initials at parse dot com.
Fascinating code! It seems to “know” that the process manager is always pid 1,
and that the first N tids in that process are the idle threads for the N CPUs in
the system. Is that knowledge reflected in a header file, or in some other form
of documentation somewhere, or do you just have to “know”?
Murf
Chris McKillop wrote:
Shaun Jackman <> sjackman@nospam.vortek.com> > wrote:
Is there any way to get an accurate count of the number of CPU cycles spent
idling? I have a task that interrupts every milli-second so I’m not certain
the ‘pidin tt’ values are giving me totally accurate values. How is the
‘pidin tt’ time accounted? If the system has many threads that each run for
a fraction of the time quantum every quantum, how are they accounted?
http://qnx.wox.org/qnx/sources/load-src.tar.gzIt queries the idle thread for the amount of time it is has spent running
and comapres that to the time elapsed to generate a CPU load. Easily
changed to get any other calculation of information you want.chris
–
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
But, as has been repeatedly pointed out in this very forum, there is a big difference
between “observed” behavior and “documented” behavior; finding the “well know facts”
in print leads one to believe that the observed behavior is unlikely to change in a
future version, whereas being unable to find them in print leaving one wondering
Murf
Robert Krten wrote:
John A. Murphy <> murf@perftech.com> > wrote:
Fascinating code! It seems to “know” that the process manager is always pid 1,
and that the first N tids in that process are the idle threads for the N CPUs in
the system. Is that knowledge reflected in a header file, or in some other form
of documentation somewhere, or do you just have to “know”?Process manager is always pid 1; that’s a “well known fact”, and is relied
upon by a lot of stuff…I’d volunteer that you could just look at the priorities of all tids of pid 1,
anything that has a priority of zero is an idle thread, 'cuz nothing else is
allowed to run at priority zero >Cheers,
-RKMurf
Chris McKillop wrote:
Shaun Jackman <> sjackman@nospam.vortek.com> > wrote:
Is there any way to get an accurate count of the number of CPU cycles spent
idling? I have a task that interrupts every milli-second so I’m not certain
the ‘pidin tt’ values are giving me totally accurate values. How is the
‘pidin tt’ time accounted? If the system has many threads that each run for
a fraction of the time quantum every quantum, how are they accounted?
http://qnx.wox.org/qnx/sources/load-src.tar.gzIt queries the idle thread for the amount of time it is has spent running
and comapres that to the time elapsed to generate a CPU load. Easily
changed to get any other calculation of information you want.chris
–
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/–
Robert Krten, PARSE Software Devices +1 613 599 8316.
Realtime Systems Architecture, Books, Video-based and Instructor-led
Training and Consulting at > www.parse.com> .
Email my initials at parse dot com.
Yep, PID 1 will be the process manager. If you like, just do an open() of
the /proc directory and check the server info of the fd if you want to write
code to get the PID. Or you can use the #define in sys/neutrino.h for
SYSMGR_PID. But it won’t change, proc is the first thing in the system to
run and will naturally have pid 1.
This is the same for the idle threads - in order for an OS to start running
it’s scheduler the idle thread(s) or processes need be created first. So
the first N threads in proc will have to be the idle threads for each of
the N CPUs in the system.
chris
John A. Murphy <murf@perftech.com> wrote:
Fascinating code! It seems to “know” that the process manager is always pid 1,
and that the first N tids in that process are the idle threads for the N CPUs in
the system. Is that knowledge reflected in a header file, or in some other form
of documentation somewhere, or do you just have to “know”?Murf
Chris McKillop wrote:
Shaun Jackman <> sjackman@nospam.vortek.com> > wrote:
Is there any way to get an accurate count of the number of CPU cycles spent
idling? I have a task that interrupts every milli-second so I’m not certain
the ‘pidin tt’ values are giving me totally accurate values. How is the
‘pidin tt’ time accounted? If the system has many threads that each run for
a fraction of the time quantum every quantum, how are they accounted?
http://qnx.wox.org/qnx/sources/load-src.tar.gzIt queries the idle thread for the amount of time it is has spent running
and comapres that to the time elapsed to generate a CPU load. Easily
changed to get any other calculation of information you want.chris
–
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Cool! SYSMGR_PID is the sort of thing I was looking for. Actually, that one is
fairly obvious (although seeing it documented is always nice!). The idle threads,
however, are not quite that intuitive (at least not to ME). The real point of all
this, however, is that it’s pretty difficult to ferret out this kind of information
unless you have some sort of clue as to the whereabouts of “well known facts.” I
guess that’s one of the huge advantages of sample code…
Murf
Chris McKillop wrote:
Yep, PID 1 will be the process manager. If you like, just do an open() of
the /proc directory and check the server info of the fd if you want to write
code to get the PID. Or you can use the #define in sys/neutrino.h for
SYSMGR_PID. But it won’t change, proc is the first thing in the system to
run and will naturally have pid 1.This is the same for the idle threads - in order for an OS to start running
it’s scheduler the idle thread(s) or processes need be created first. So
the first N threads in proc will have to be the idle threads for each of
the N CPUs in the system.chris
John A. Murphy <> murf@perftech.com> > wrote:
Fascinating code! It seems to “know” that the process manager is always pid 1,
and that the first N tids in that process are the idle threads for the N CPUs in
the system. Is that knowledge reflected in a header file, or in some other form
of documentation somewhere, or do you just have to “know”?Murf
Chris McKillop wrote:
Shaun Jackman <> sjackman@nospam.vortek.com> > wrote:
Is there any way to get an accurate count of the number of CPU cycles spent
idling? I have a task that interrupts every milli-second so I’m not certain
the ‘pidin tt’ values are giving me totally accurate values. How is the
‘pidin tt’ time accounted? If the system has many threads that each run for
a fraction of the time quantum every quantum, how are they accounted?
http://qnx.wox.org/qnx/sources/load-src.tar.gzIt queries the idle thread for the amount of time it is has spent running
and comapres that to the time elapsed to generate a CPU load. Easily
changed to get any other calculation of information you want.chris
–
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
\Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
That is why we have newsgroups with developers answering questions and
providing example source! 
chris
John A. Murphy <murf@perftech.com> wrote:
Cool! SYSMGR_PID is the sort of thing I was looking for. Actually, that one is
fairly obvious (although seeing it documented is always nice!). The idle threads,
however, are not quite that intuitive (at least not to ME). The real point of all
this, however, is that it’s pretty difficult to ferret out this kind of information
unless you have some sort of clue as to the whereabouts of “well known facts.” I
guess that’s one of the huge advantages of sample code…Murf
Chris McKillop wrote:
Yep, PID 1 will be the process manager. If you like, just do an open() of
the /proc directory and check the server info of the fd if you want to write
code to get the PID. Or you can use the #define in sys/neutrino.h for
SYSMGR_PID. But it won’t change, proc is the first thing in the system to
run and will naturally have pid 1.This is the same for the idle threads - in order for an OS to start running
it’s scheduler the idle thread(s) or processes need be created first. So
the first N threads in proc will have to be the idle threads for each of
the N CPUs in the system.chris
John A. Murphy <> murf@perftech.com> > wrote:
Fascinating code! It seems to “know” that the process manager is always pid 1,
and that the first N tids in that process are the idle threads for the N CPUs in
the system. Is that knowledge reflected in a header file, or in some other form
of documentation somewhere, or do you just have to “know”?Murf
Chris McKillop wrote:
Shaun Jackman <> sjackman@nospam.vortek.com> > wrote:
Is there any way to get an accurate count of the number of CPU cycles spent
idling? I have a task that interrupts every milli-second so I’m not certain
the ‘pidin tt’ values are giving me totally accurate values. How is the
‘pidin tt’ time accounted? If the system has many threads that each run for
a fraction of the time quantum every quantum, how are they accounted?
http://qnx.wox.org/qnx/sources/load-src.tar.gzIt queries the idle thread for the amount of time it is has spent running
and comapres that to the time elapsed to generate a CPU load. Easily
changed to get any other calculation of information you want.chris
–
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
\Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
–
Chris McKillop <cdm@qnx.com> “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
And we DO appreciate that!!!
Murf
Chris McKillop wrote:
That is why we have newsgroups with developers answering questions and
providing example source! >chris
John A. Murphy <> murf@perftech.com> > wrote:
Cool! SYSMGR_PID is the sort of thing I was looking for. Actually, that one is
fairly obvious (although seeing it documented is always nice!). The idle threads,
however, are not quite that intuitive (at least not to ME). The real point of all
this, however, is that it’s pretty difficult to ferret out this kind of information
unless you have some sort of clue as to the whereabouts of “well known facts.” I
guess that’s one of the huge advantages of sample code…Murf
Chris McKillop wrote:
Yep, PID 1 will be the process manager. If you like, just do an open() of
the /proc directory and check the server info of the fd if you want to write
code to get the PID. Or you can use the #define in sys/neutrino.h for
SYSMGR_PID. But it won’t change, proc is the first thing in the system to
run and will naturally have pid 1.This is the same for the idle threads - in order for an OS to start running
it’s scheduler the idle thread(s) or processes need be created first. So
the first N threads in proc will have to be the idle threads for each of
the N CPUs in the system.chris
John A. Murphy <> murf@perftech.com> > wrote:
Fascinating code! It seems to “know” that the process manager is always pid 1,
and that the first N tids in that process are the idle threads for the N CPUs in
the system. Is that knowledge reflected in a header file, or in some other form
of documentation somewhere, or do you just have to “know”?Murf
Chris McKillop wrote:
Shaun Jackman <> sjackman@nospam.vortek.com> > wrote:
Is there any way to get an accurate count of the number of CPU cycles spent
idling? I have a task that interrupts every milli-second so I’m not certain
the ‘pidin tt’ values are giving me totally accurate values. How is the
‘pidin tt’ time accounted? If the system has many threads that each run for
a fraction of the time quantum every quantum, how are they accounted?
http://qnx.wox.org/qnx/sources/load-src.tar.gzIt queries the idle thread for the amount of time it is has spent running
and comapres that to the time elapsed to generate a CPU load. Easily
changed to get any other calculation of information you want.chris
–
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
\Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
\Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
John A. Murphy <murf@perftech.com> wrote:
Cool! SYSMGR_PID is the sort of thing I was looking for. Actually, that one is
fairly obvious (although seeing it documented is always nice!). The idle threads,
however, are not quite that intuitive (at least not to ME). The real point of all
this, however, is that it’s pretty difficult to ferret out this kind of information
unless you have some sort of clue as to the whereabouts of “well known facts.” I
guess that’s one of the huge advantages of sample code…
Em, I would suggest avoid SYSMGR_PID, but use name space (open("/",
O_RDWR)) instead.
Direct using SYSMGR_PID, breaks everything over QNET
(Well I realized QNET is no use here, but this is just in general).
-xtang
Murf
Chris McKillop wrote:
Yep, PID 1 will be the process manager. If you like, just do an open() of
the /proc directory and check the server info of the fd if you want to write
code to get the PID. Or you can use the #define in sys/neutrino.h for
SYSMGR_PID. But it won’t change, proc is the first thing in the system to
run and will naturally have pid 1.This is the same for the idle threads - in order for an OS to start running
it’s scheduler the idle thread(s) or processes need be created first. So
the first N threads in proc will have to be the idle threads for each of
the N CPUs in the system.chris
John A. Murphy <> murf@perftech.com> > wrote:
Fascinating code! It seems to “know” that the process manager is always pid 1,
and that the first N tids in that process are the idle threads for the N CPUs in
the system. Is that knowledge reflected in a header file, or in some other form
of documentation somewhere, or do you just have to “know”?Murf
Chris McKillop wrote:
Shaun Jackman <> sjackman@nospam.vortek.com> > wrote:
Is there any way to get an accurate count of the number of CPU cycles spent
idling? I have a task that interrupts every milli-second so I’m not certain
the ‘pidin tt’ values are giving me totally accurate values. How is the
‘pidin tt’ time accounted? If the system has many threads that each run for
a fraction of the time quantum every quantum, how are they accounted?
http://qnx.wox.org/qnx/sources/load-src.tar.gzIt queries the idle thread for the amount of time it is has spent running
and comapres that to the time elapsed to generate a CPU load. Easily
changed to get any other calculation of information you want.chris
–
Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
\Chris McKillop <> cdm@qnx.com> > “The faster I go, the behinder I get.”
Software Engineer, QSSL – Lewis Carroll –
http://qnx.wox.org/
Xiaodan Tang <xtang@qnx.com> wrote:
Em, I would suggest avoid SYSMGR_PID, but use name space (open("/",
O_RDWR)) instead.
I would feel very uncomfortable doing that, all sorts of things union-
mount at “/”, no guarantee you’ll hit proc (and assuming that proc
has a name server at “/” is probably just as big an assumption anyway;
there is PATHMGR_PID which happens to also be SYSMGR_PID). The libc
is packed with such references, so you’re probably fairly safe.
Direct using SYSMGR_PID, breaks everything over QNET >
Go for ConnectAttach(node, SYSMGR_PID, SYSMGR_CHID …) then.