I''m using the following tick probe in a script to limit the run to 10
secs and noticed the run time fluctuates quite a bit. Why is that? This
system is under medium load - CPU & disk are around ~50% and ~70% busy
respectively.
...
tick-10sec
{
exit(0);
}
...
# time ./pg_lwlock.d <pid>
Run #1
real 0m24.763s
user 0m0.589s
sys 0m1.371s
Run #2
real 0m6.844s
user 0m0.349s
sys 0m0.157s
Run #3
real 0m10.547s
user 0m0.335s
sys 0m0.149s
Run #4
real 0m4.622s
user 0m0.343s
sys 0m0.152s
Run #5
real 0m1.564s
user 0m0.328s
sys 0m0.147s
Thanks,
-Robert
Robert Lor wrote:> > I''m using the following tick probe in a script to limit the run to 10 > secs and noticed the run time fluctuates quite a bit. Why is that? This > system is under medium load - CPU & disk are around ~50% and ~70% busy > respectively. > > ... > > tick-10sec > { > exit(0); > }At the first firing, exit. Fire once every 10 seconds.... if the system isn''t busy. So, busy system => more than 10 seconds realtime. Idle system => some time between zero and ten seconds. Possibly you want to count ten one-sec ticks? - Jeremy
On Tue, Jul 11, 2006 at 07:13:18AM -0700, Robert Lor wrote:> > I''m using the following tick probe in a script to limit the run to 10 > secs and noticed the run time fluctuates quite a bit. Why is that? This > system is under medium load - CPU & disk are around ~50% and ~70% busy > respectively. > > ... > > tick-10sec > { > exit(0); > } > ...First off, the tick-10sec probe will fire once every 10 seconds; the phase is not necessarily matched up with when your process starts, especially if someone else is using the tick-10sec probe concurrently. If you want to end after a precise amount of time, something like: BEGIN { end = timestamp + 10 * 1000000000ull } tick-1sec /timestamp >= end/ { exit(0); } (lower 1sec if you want to be closer to the real time) is more reliable. Note that there is processing before the probes are actually enabled and after they are disabled; that may throw off your numbers, as well. Cheers, - jonathan> # time ./pg_lwlock.d <pid> > > Run #1 > real 0m24.763s > user 0m0.589s > sys 0m1.371s > > Run #2 > real 0m6.844s > user 0m0.349s > sys 0m0.157s > > Run #3 > real 0m10.547s > user 0m0.335s > sys 0m0.149s > > Run #4 > real 0m4.622s > user 0m0.343s > sys 0m0.152s > > Run #5 > real 0m1.564s > user 0m0.328s > sys 0m0.147s > > > Thanks, > -Robert > > _______________________________________________ > dtrace-discuss mailing list > dtrace-discuss at opensolaris.org-- Jonathan Adams, Solaris Kernel Development
Jonathan & Jeremy, Thanks for the solution. -Robert Jonathan Adams wrote:>On Tue, Jul 11, 2006 at 07:13:18AM -0700, Robert Lor wrote: > > >>I''m using the following tick probe in a script to limit the run to 10 >>secs and noticed the run time fluctuates quite a bit. Why is that? This >>system is under medium load - CPU & disk are around ~50% and ~70% busy >>respectively. >> >>... >> >>tick-10sec >>{ >> exit(0); >>} >>... >> >> > >First off, the tick-10sec probe will fire once every 10 seconds; the phase >is not necessarily matched up with when your process starts, especially if >someone else is using the tick-10sec probe concurrently. > >If you want to end after a precise amount of time, something like: > >BEGIN { end = timestamp + 10 * 1000000000ull } >tick-1sec /timestamp >= end/ { exit(0); } > >(lower 1sec if you want to be closer to the real time) is more reliable. > > >Note that there is processing before the probes are actually enabled and after >they are disabled; that may throw off your numbers, as well. > >Cheers, >- jonathan > > > >># time ./pg_lwlock.d <pid> >> >>Run #1 >>real 0m24.763s >>user 0m0.589s >>sys 0m1.371s >> >>Run #2 >>real 0m6.844s >>user 0m0.349s >>sys 0m0.157s >> >>Run #3 >>real 0m10.547s >>user 0m0.335s >>sys 0m0.149s >> >>Run #4 >>real 0m4.622s >>user 0m0.343s >>sys 0m0.152s >> >>Run #5 >>real 0m1.564s >>user 0m0.328s >>sys 0m0.147s >> >> >>Thanks, >>-Robert >> >>_______________________________________________ >>dtrace-discuss mailing list >>dtrace-discuss at opensolaris.org >> >> > > >