Summary of Discussions about "ftimer.h"

[These comments were supplied by Baljinder Ghotra, who coordinated the PTR effort until Spring of 1996]


I am trying to summarize the results of the discussion about "ftimer.h" the Fortran header file for the Portable Timing Routines. I have to say that the response was very enthusiastic (over 25 messages in under 14 hours :). I hope the interest will continue.

There were a number of issues raised during the discussion. I will try to post some of the rationale behind some of the decisions that were made or at least my understanding of the issues. Please feel free to correct me.

My comments begin with a ">" mark.

Related to compliance with Standards/conventions...

  1. Prefix "PTR_" to the status codes. c *------------------------------------------------------------------*
    c * Status codes returned by the subroutines *
    c *------------------------------------------------------------------*
    parameter( NOT_AVAILABLE = -1)
    parameter( ROLLOVER_DETECTED = -2)
    parameter( CANNOT_CALIBRATE = -3)
    parameter( OTHER_ERROR = -4)

    > I think it would make all the definitions consistent. Thanks for pointing it out to me.

  2. Change REAL*8 to REAL or DOUBLE PRECISION.
    > The type will vary for each platform, depending on what is used to represent a 64-bit quantity. However this 64-bit value may not be appropriate for systems that only have 32-bit quantities. However, I agree with the use of the standard types. I will change it to DOUBLE PRECISION in the template version and the implementors can change it to whatever is most appropriate for their platform(s).

  3. Renaming "ftimer.h" to "FTIMER.INC".
    >I think the decision for this rests with the members of the group as a whole.

  4. Use of upper case "C" for comments and all caps for reserved words.
    > Sorry for my oversight, I will correct the problem.

    Other Issues

  5. Renaming of "PTR_INIT_???_TIMER" to PTR_???_TIMER_INIT (??? = WALL, USR or SYS)?
    > Again a decision for the group.

  6. Removal of PTR from the names?
    >From the discussion a number of people that responded said that having the "PTR_" prefix was a good idea. But if there are any compelling reasons that should be considered we can discuss it further.

  7. There were some questions about NOMINAL values, CALIBRATED values and the PTR_INIT_???_TIMER routines.

    > I think Mr. Kesavan gave a good explaination of where each would be useful.

    Here is my understanding of the situation. The NOMINAL values are supplied by the vendor. The CALIBRATED values are calculated at installation time, to account for any special configurations of the particular system. The PTR_INIT_???_TIMER routines are used to get the values at runtime. When using different machines that are binary compatible and access the same library these routines would let the user get the values for the particular machine that s/he is using. Also as pointed out in the discussion this would also be helpful in determining the values when other factors like system load are to be considered.

    ** An additional concern/question **

    In addition there are some platforms that require initialization of the timers before they can be read. How do we handle these cases.

    Here are some suggestions that Richard Frost had made (earlier). I don't think this was discussed over the reflector/mailing list.

    Here's the tradeoffs I see with respect to the timer initialization problem.

    1. We could require the users to call an initialization function. Some users will forget and receive anomalous results. Others will be annoyed.

    2. We could request/require the vendor to initialize the timer; e.g., the pre-processor would automatically insert this call for the user.

    3. We could maintain a static flag variable which determines the initialization state. The overhead of this approach has two effects: (a) the overhead of checking the flag must be subtracted -- along with the subtraction overhead -- from the timer output; and (b) the resolution of the clock will be slightly reduced, causing an increase in the indeterminancy.

    4. We could request that the timer be implemented as a global function pointer. For platforms requiring initialization, the initial value of this pointer calls the algorithm described in #3 and then resets the pointer to a streamlined function.

  8. Should we have PTR_CALIBRATED_TICK_PERIOD ? What about a nominal and calibrated value for the rest of the constants?

    > This is an interesting point. If we have a Nominal and Calibrated value for the Tick period, what about Nominal and Calibrated values for the rest of them.

    The reason as pointed out by Mr. Kesavan for this issue is about the correctness of the values. For example, if we have a nominal rollover period it is based on the nominal tick period: rollover period = tick period * no. of ticks that can be stored in the register

    So if the tick period changes the rollover period would change. Similarly if the Resolution for a particular machine may be 5 ticks, which would change with the tick period.

    ***** IMPORTANT *****

    Should we have both nominal and calibrated values for all the quantities? Should we have either Nominal or Callibrated values for all quantities? If we have just one kind, i.e., either nominal or calibrated, how do we convey this information to the user? Another Constant maybe... CALIBRATED ???

  9. What is the difference between PTR_WALL_NOM_TICK and PTR_WALL_RESOLUTION ?

    >Here is the definition of Resolution as presented in the PTR Overview.

    The minimal time unit that can be measured with confidence. It will be at least as coarse as the tick period, and probably coarser since many timers operate as step, rather than continuous functions. This value will be nominal (i.e., supplied by the vendor) indicating the number of bits that should be considered valid when calculating elapsed time.

  10. Is there any agreement on what the timer values should be if GET_*_TIME routines fail?

    > I don't think this has been discussed in too much detail by the group as a whole. It might be possible to initialize the variables that store the opaque values to a negative number. And if the number remains the same after the routine has executed we might be able to interpret that the value was not updated. But if the value is changed there is nothing to help us determine that the value returned is a valid one and not just garbage.

    I guess it might be possible to do some error checking but it would mean additional overhead. I guess if the user really wants to be sure that the calls are working they can initialize the variable as mentioned above and test the values that are returned. I would like to point out that the value will be meaningless (because these will be register contents). Also you could have multiple calls right after one another and check the values to see if the numbers returned are increasing steadily. But other than that I can't think of any error checking for the GET_*_TIME routines.

Post comments to the working group at ptools-ptr@ptools.org.