Subject: Re: Detecting cleared alarms

From: "Dave Shield" <[email-masked]>
Date: Thu, 9 Aug 2001 08:23:03 +0100 (BST)

> >   For the Retired table, assuming the indexes include some form of
> > timestamp, this is not possible.  The manager would not know when
> > the alarms would have been cleared, so could not generate the
> > necessary list of predecessors.

> The manager would only need to remember the date and time
> of the last entry in the table from the last time it checked
> the retired alarm table.

For the *first* one, sure - but how can it check all 200 in a single
GETNEXT request?   It doesn't know when the first alarm was cleared,
so it can't try to GETNEXT-retrieve the second alarm in the same PDU.
It inherently has to walk the column one entry at a time.  Thus
200 requests, and 200 replies - minimum (assuming all alarms have
actually been cleared).

The same approach can be used for the active table - walking it one
entry at a time - so you've potentially got the same 200+200 PDUs.
But the full details of the known alarms are already known (by
definition) - including the timestamps which are in fact part of
the indexing.
  So the manager can put all 200 varbinds into a single GETNEXT
request, and check them all in one go.  There's the same 400 varbinds
involved - but only 2 PDUs.  That's a saving (both in PDU cruft, and
latency) that simply isn't available when walking the Retired table.

Or am I missing something obvious?

Dave

---

From: "Dave Shield" <[email-masked]>
Date: Thu, 9 Aug 2001 13:56:51 +0100 (BST)

> GetBulk.

It's a v1-only agent :-)

But seriously - you're comparing apples and oranges.  You've got
to consider the same operations in order to get a fair comparison.
The next section of my original message compared GetBulk on the two
tables (also to the detriment of the Retired table IMO).

  But using a pure GetNext strategy, the active table has this
additional parallelisation strategy available, which is inherently
not possible when GetNext'ing the Retired table. 

> The maximum number of varbinds that most implementations will
> accept over a UDP transport is usually much less than 200.

So chunk it using something smaller.  Even querying two rows instead
of one could potentially halve the number of requests - something
that isn't possible with the retired table.

> The difference is that with a separate table of retired alarms,
> the retrieval cost is proportional to the number actually
> cleared since the table was last checked.

Agreed.

>                                            With the existing
> approach, the cost is proportional to the total number of
> active alarms at the time of the previous check of the active
> alarm table.

No.
The cost is proportional to the total number of those earlier
active alarms that are still current.
              ^^^^^^^^^^^^^^^^^^^^^^
The active table is still ordered by time, is it not?
So as soon as the manager retrieves the first entry that is
later than the last one it knows about, it can stop.  That
could easily be the first request it sends, if all the alarms
have since been cleared.
  (Chunking might mean that it actually requests more than
it needs - but only within that final PDU. It wouldn't need
to send any more separate requests).

  The Best Case and Worst Case costs are the same in both cases,
though the Best and Worst Case scenarios are mirrors of each other.

If the manager knows from the first request that all known alarms
have been cleared - whether this is one alarm or one million - how
is this O(N) ?

Dave

---

From: "Dave Shield" <[email-masked]>
Date: Thu, 9 Aug 2001 23:18:48 +0100 (BST)

> If the typical lifetime of an alarm is shorter than the
> poll cycle, we're better off without a cleared alarms table.

Without _using it_ for this particular case - yes.

> If the typical alarm stays active longer than the poll cycle,
> the cleared alarms table wins out.

Yup.
I've not been trying to suggest that a cleared alarm table is
not useful - simply that it isn't as one-sided as you originally
seemed to indicate.

> However, where the typical cost will tend is strongly
> affected by the typical active alarm lifetime.  My
> intuition is that very short-lived alarms are not
> particularly interesting.

This is indeed the crux of the matter - and I'm quite happy to
accept that your intuition is probably correct.

In practise, I'd be inclined to adopt a mixed strategy.
Something like

   GETNEXT 0.100 alarmActiveModelPointer alarmClearedModelPointer  

(or whatever the appropriate starting points might be)
In other words, get half the known alarms from the active table,
and half from the cleared table (assuming they have indeed been
cleared).  That way we'd be covered both ways.  Whatever the
situation, whether most alarms had been cleared or not, we'd
(probably) get enough information to tell the overall situation,
based on which table walk overran.
  (The short-lived alarm problem would still interfere with this,
but it would only be significant if the number of such alarms
was enough such that *neither* table overran).

My gut reaction (based on absolutely no data whatsoever!) is
that this is probably not too great a problem.  And if it bites,
then hey - we tried our best.  We can always send another request
to try and tidy up the remaining uncertainty.

The one disadvantage of this is that it pushes a certain amount
of complexity onto the manager (working out which table has
overrun, and what the implications are).  But I'm primarily an
agent implementor, so I can live with that :-)

Dave