process runtime, time and simulation in erlang
Sat Apr 15 00:13:39 CEST 2006
one way of doing it is using the trace functionality. Use
erlang:trace/3 to turn the 'running' 'timestamp' and 'cpu_timestamp'
flag on for all processes. You will the get 'in' and 'out' trace
messages for every process.
Look at erlang:trace/3 in the erlang module in kernel application
for more details.
Note cpu timestamp currently only works on Solaris as far as I know.
Lennart Ohman office : +46-8-587 623 27
Sjoland & Thyselius Telecom AB cellular: +46-70-552 67 35
Sehlstedtsgatan 6 fax : +46-8-667 82 30
SE-115 28, STOCKHOLM, SWEDEN email :
> -----Original Message-----
> From: [mailto:owner-erlang-
> ] On Behalf Of Erik Garrison
> Sent: Friday, April 14, 2006 8:53 PM
> Subject: process runtime, time and simulation in erlang
> Is there a way to obtain the total runtime of a process in Erlang? I'd
> like to use the information to create a metronome process which scales
> "time" in a simulated environment relative to system load. Scaled time
> will be used to throttle the rate at which requests to a simulated system
> occur relative to wallclock time.
> I can find the number of reductions completed by a process using
> process_info(Pid, reductions). Is there also a way to find out how much
> runtime a given process has? Is such a question meaningless when
> processes are scheduled based upon the number of reductions they make?
> For some background...
> I'm building a simulated environment using Erlang to test the efficacy of
> different distributed object caching and placement protocols.
> Generally, things have been wonderful. I *really* like Erlang and the
> manner in simplifies problems of distributed systems. The problem is that
> I'm not just working with a distributed system; I'm simulating one.
> Time is an important part of simulation, but when one system is emulating
> a dozen, or a hundred others, wallclock time loses meaning relative to the
> rate at which these processes operate. For instance, when a system runs
> one process continuously, it registers N reductions/millisecond, when it
> runs ten of the same process concurrently, they each run N/10 red/ms. If
> each new process is understood to be running on a distinct node, then
> in a real environment, each would run at the same rate relative to a
> wallclock as the first process did when it had full access to the
> resources of a single system.
> If I can solve this problem, then I can make it much easier to simulate an
> entire, concurrent, network environment on a single Erlang node. I can
> also rate-limit nodes, or build some conception of process "niceness"
> within Erlang. I fear that anything more than a simple hack to fix this
> will require a patch to Erlang/OTP itself.
More information about the erlang-questions