Summary, was Re: Every time ..., was Re: General formula

[Ed Gerck <egerck@xxxxxxxxxxxxxxxxxxxxxx>]

Alan Lloyd wrote:

>  For my three bobs worth, the fundamental issue is that a complex
> problem like the lifetime of a lump of data cannot be solved by a simple
> (or lightweight) solution or formula

Alan:

I feel that a summary is in order -- too many subjects and topics
on this issue ... we need to see the forest in spite of the trees.
I also include some comments to other msgs and will try to
synthezise list arguments so far.

1. never say never -- I mean, we don't have a dogma here, do we?

2. The more you say it is impossible, the happier I feel ;-)

3. As I commented before, I am thankful for your doubts -- they
have helped me bring to the forefront issues such as Poisson and Erlang
statistics. Even though I may not have been 100% successfull (it seems)
to convince everyone, if my private mailbox can be proof then I have
been at least partially successfull in pointing out that modelling is much,
much better than guessing ;-)

4. But, I also do not want to impose upon this list a course on poisson
statistics modelling  -- just using the results is usually fine for all engineering
purposes. Further, I take that current doubts from Tom and others can be
solved by resorting to  textbooks, so I am trying to wait and see what
happens in time on this regard.  Again, the equation does not have to be
deduced before it is used ;-) It is already there and those that may feel
more confortable with examples will be able to verify that it works; again,
in their own due time and there is no pressure.

5. If you don't trust the equation, then I suggest you *first* do the only
thing available today -- wild guess the result. Then, I suggest you do
calculate it. Then, I suggest you use whatever you feel is better  -- the
"wild guess" or the "wild calculation" ;-) (as you may call it). Then, I
further suggest you wait out and check what happens in the practice.
With all due respect to theory, this is IMO a far more significat test
than pages and pages of equations -- paper is too flexible and,
bytes too easily changed, as we all know ;-)

6. If you do want to "wild calculate" then please do read the inlined
reference [1] in my original posting -- it explains the modelling phase that
*must* precede any lifetime calculation using that equation. As it was very
timely remarked here yesterday by Andrew Probert:

"However for this, or any capacity planning exercise, real-world data and
assumptions are input to the model."

Thus, slightly paraphrasing Andrew's following text, I may say:

"Gerck's certificate lifetime equation requires the user to input their
assumptions on each presented attribute validity lifetime (an average)
of a *given* certificate, when a single exponential decay is assumed for
each attribute validity.  When this is not true for an attribute (eg, in the
case of a square-function validty) but the attribute can be described
by a piecewise exponential decay (as it generally can, at least
approximately) then the user must define and assume enough delayed
sub-attributes to that attribute so that the each sub-attribute validity
function is given by a single exponential decay in its time slot *and*
the user must also consider the resulting piecewise application of the
certificate lifetime equation -- so that in each time slot, all attributes
and sub-attributes are given by single exponential decays.
Alternatively, the user can input what certificate lifetime is desired,
for a given set of operational conditions, to derive a maximum number
of attributes of equal lifetime or a mix of attributes of different lifetimes.
The user does not need to make any assumption about attribute
dependency besides the trivial case of not using fully redundant
(whatever this may mean in the operational context) attributes; such
as repeatingly using the same attribute lifetime in the equation if the
attribute happens to repeated verbatim in the certificate -- since the
attribute is essentially "one" if simply repeated."

Hope it is clearer.

Cheers,

Ed Gerck