Idleness Signal

[Wiger Ulf]

You could also look at run_queue, which should normally be quite small.
Of course, if you have one process doing tons of work, reductions will give
you a better indicator. A combination of indicators is usually needed to get
a good reading on processor load. In an I/O-bound system, run_queue is
pretty good. In a CPU-bound system, reductions may work.

But I would not go as far as waiting for reductions to be unchanged for one
second. That may never happen. I think you should track these indicators for
a while and try to determine what thresholds seem sensible.

cpu_sup.erl may also be used for some perfmeter-like load measurements.

/Uffe


----- Original Message -----
From: "Eric Newhuis" <enewhuis@REDACTED>
To: <erlang-questions@REDACTED>
Sent: den 29 maj 2003 19:17
Subject: Idleness Signal


> I have a "time trial" test whereby I cram a bunch of data into a
> multi-process single-node Erlang application and then wait for things to
> "settle down".
>
> The application has a lot of messaging and I do not wish to intrude on
> the messaging pipeline to determine an exact event-driven completion
> signal.  My goal is to determine the total cost of processing my batch
> of input messages and to compare the various run times among different
> algorithms, data structures, optimizations, etc.
>
> I also intend to use eprof to investigate with finer granularity to help
> explain differences in "time trial" results.  So I am not seeking a
> substitute for eprof.  I love eprof.  I am building a complimentary tool.
>
> Can anyone suggest alternatives for raising a signal that says that an
> Erlang node is idle?
>
> I am currently entertaining the thought of polling the total REDS, as
> seen in erl's i() output and terminating my test when the REDS is
> unchanged for 1 second.  Since I think I am all CPU bound during this
> test I think this will work.  (I/O-bound conditions may effect false
> triggers.)
>
> Is there a more clever way to raise such a signal?  ...more clever than
> polling REDS?  I don't need precision beyond 1 second; my time trial is
> expected to run for several minutes to an hour.
>
> Sincerely,
> Eric Newhuis
>
>