On Sat, 2007-04-07 at 15:37 -0300, Rodrigo Barbosa wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Sat, Apr 07, 2007 at 02:03:10PM -0400, William L. Maltby wrote:
> > > <snip>
> > > You mean like using libfam/gamin to monitor that file ? It _could_ work,
> > > but we have no way to garantee that will be always the case.
> >
> > Ummm... I would use the plain old "test" command or bash's "if [ -f ..."
> > stuff. In a small loop with something like "sleep 1". Of course, the
> > bash "-s" or a read of a few bytes from the known file followed by a
> > test using -N might do the job. Again, in an appropriate loop. It all is
> > dependent on knowing what the target process is going to do and what
> > leeway we have, such as erasing/removing some file beforehand. If we can
> > do that, I'm sure some "while... sleep ..; if [ -{s|N}} <file> ] ;
> > then ..." construct would do admirably.
>
> Your solution would have a precision of 5 to 10 seconds, I estimate.
> If that is good enough, it is a simple way to do it. That should give
> higher than 95% precision, usually higher than 98%. Not bad for a
> small script.
5 - 10 seconds =:-O I think it would be better than that... If we have
the right "trigger". Knowing, for instance, that the last "setup" issue
would be some distinct event (like opening a new output file, probably
not /var/pid because that should be early) would then allow us to
consider all remaining activities to be "processing". Then, if wall
clock was the only criteria, we s/b pretty accurate. Naturally, on
heavily loaded servers, some other mile-marker, like user CPU time,
would be better. But on single-user workstations, the simple remedies we
have touched on will certainly do better than and 8 to ten second
window. That's betting user doesn't run the stuff during his nightly
full-copy-backup operation.
> <snip>
> It IS overkill :) I'm just considering a generic implementation, not
> the need of OP. Actually, I'm considering creating a small GPLed
> program to do this, so I have to cover as many situations as possible.
>
> I think you misunderstood me, when you say the target has to have this
> facility. I was talking about a callibration child, not the exec() one.
Yes, I misunderstood. But along that vein, it seems to me than that the
calibration should be a concurrent process so that it can determine in
"real time" when enough "wall clock" time has passed. As long as wall
clock is the criteria, we get stuck with using any pre-acquired
benchmarks as reference data only. The current processing
environment/load would need to be blended in *throughout* the life of
the target application and the "calibrator" when then decide in real-
time that mayhem was due.
If we get to that point, it *seems* to me that the only reliable metric
becomes the user CPU time and/or I/O completions, depending on the
applications profile.
And that would tend to indicate that relatively high-precision (I hope
my understanding of your concept of that is "good enough") can only be
approached (ignoring real-time acquisition of the target's accounting,
I/O, CPU, ...) by the calibrator running concurrently and seeing the
current deviation from the database of captured test runs of the past.
> <snip>
> > I enjoy this sort of stuff. Don't get to do it often enough. And in the
> > last upmteen years, haven't kept my shell/C skills up-to-snuff.
> > Essentially retired from the race after enough decades of it.
>
> I second that. Since I started my own company, the business side of
> it is taking so much time I'm getting really rusty on shell/C skills.
Ditto when I had my own biz. Plus, I found I didn't like "managing"
others. They weren't enough like me! =:O
> <snip>
> Well, it IS possible to run the target a few times, and gather the
> information either using times(2) (in C) or time(1) (in a shell).
> That would give us the values we need. It would be kind of precise,
> too, since we could look past all those I/O and scheduller issues.
>
> Which might be exactly what the OP needs.
>
> I imagine a callibration loop, where we would run the program a few
> times, with different (...)& alarms and maybe a few "ulimit -t" passes,
> gathering time(1) values.
>
> Then, with that data in hand, we could save that value inside a
> cache/db for further uses. From that point on, the script would only
> need to check that database for the appropriate value when executing
> a given program.
> <snip sig stuff>
--
Bill
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
