I want to give a little background to the design I had for
intervalling.
- There was a requirement in the agent requirements spec at one stage
  for the intervals to be synchronised with the hour. On wednesday
  I found that that reference/requirement had gone. When that was in
  place there was a much stronger case.
- Also not the assumption in the MIB definition of the "current"
  counters. They are accumulated values from the start of the interval.
  They are presumed to be growing during the 15 minute current interval.
  So if you were to monitor "current" every minute for an hour, you
  would expect to see a sawtooh pattern.
  The 15 minute accumulation by the switch is leading to an up/down
  step pattern between the high points of the sawtooth.
  I have a worry here that a customer may ask for the MIB conventional view.

I am revising the design to overcome the problem of 2x15 intervalling
clocks being out of step.

The design below tries to fit a number of criteria
- syschronise intervalling periods of the agent MIB with 15 minute DSLs
  so that the last DSL value is seen for the whole (or very close to)
  15 minute current interval. (i.e. the customer doesn't see 0 for
  any period of the interval.
  This has the implication that each interface is running its own
  15 minute intervals, not all the interfaces synchronised as in the
  current proposal.
  (This has a side effect that if a customer were running load tests
  between 2 interfaces, and trying to correlate the counters over a period
  near 15 minutes, they would have difficulty).
- handle the possibility of the link going down between client and agent.
  we need to continue to have intervals marching on.
- Allow a switch to go down and up, and to resynchronise.
- Allow the agent to be shutdown, e.g. to run backups or preventative 
  maintenance, and to have intervals march on.
  (While it seems I am allowing a lot of gaps due to down time, I believe
  the actual situations will be infrequent. I just want to handle them).
- Allowing the DSL interval to be reduced to (say) 5 minutes to allow
  customer to see sawtooth behaviour. 
- Not be 100% reliant on the 15 minute DSLs being set properly. i.e.
  be tolerant of an operator typo. The agent has no control of the 
  15 minutes in the DSL, so the agent should be defensive.
- allow a little tolerance in the arrival times of DSLs (up to 1 min)

In the below, I am making simplifications for clarity.
- I am only referring to one config/current/total/96xInterval. Instead
  there are multiple, ds1, ds3, sonetSection, sonetLine, sonetPath...
- In the actual interval rollover code, I am only displaying one thing
  being totalled, one current being rolled into the interval. This happens
  individually for each attribute in the group.

Assume "now" is a time_t variable set immediately after the main select
loop timeout.

The algorithm:

config records (and there are ds1, ds3, sonetMedium) contain
a couple more internal use attributes:
- last_new_data, the time (now) that a DSL referring to this interface
  arrived
- last_intervalled - the time of the last occurrence of the current
  record being moved to the Interval table, causing a reaccumulation of
  the Total entry, and the zeroing of the current entry.
  (I think this is actually already in the MIB definition anyway).

Interval rollover processing (for a particular if type, e.g. ds3)

rollover( array_offset(AO), time_of_intervalling(TOF) )
/* note that the array offset is the same in the config, current and total
   tables, and 96*array_offset+interval number in the Interval table.
   refer to the current design for more detail on the rollover process*/

   total[AO] = total[AO] - Interval[AO][96]
   shift intervals 1-95 to 2-96, losing the 24 hour old value.
   this can be achieved without actually moving any data, see existing design
   Interval[AO][1] = current[AO]
   current[AO] = 0
   config[AO].last_intervalled = TOF


DSL processing:

for every DS in the DSL
    find the interface entry for this DS (CEN&counter id) in the
    appropriate config and current tables.
    if (now - config.last_new_data > 14 min) &&
       (now - config.last_intervalled > 1 min)
       rollover(interface entry, now)
    /* Normal processing is to just accumulate the counter */
    current.attribute_counter += DS.value
    config.last_new_data = now


Main loop interval processing for the handling of 
- startup
- down switches
- lost communications etc

time_t interval_processing_last_run = 0;    /* startup */

/* load all the config, current, total, interval tables from mib cache */

while (TRUE)    /* main select loop */
    select (wait_for(all SNMP or MNCS sockets, timeout = 1 sec)
    now = time(&now)
    /* Process SNMP requests */
    /* process MNCS messages */

    if (now - interval_processing_last_run >= 60) /* run each minute */
        interval_processing_last_run = now
        for all interfaces
            if (now - config.last_intervalled > 24 hours)
                /* long downtime, or bad initial value.
                   last_intervalled should be initialized to "now" */
                config.last_intervalled = now - 24 hours
            while (now - config.last_intervalled >= 15 mins)
                /* handle downtime with the while loop.
                   handle time slippage due to processing delays due to
                   lowest priority handling of intervalling in main loop
                   by using scheduling time instead. (maybe overkill ?) */
                rollover( interface entry, config.last_intervalled + 15min)


Sorry this all seems long winded. I think this is sufficiently complete
(and complex) to handle the problems in an even handed way. I also think
it is sufficiently simple to implement. (There exist more complex solutions).

I'll speak to you in a few hours.