MPI_T High Resolution Timer

[kathrynmohror]

We want to introduce a new, high resolution timer for tools into MPI. The problem with MPI_Wtime is that the resolution is generally too low to be useful for tools that measure fine-grained activities.

We want to define the timer (and associated "tick" routine to get resolution) such that resolution provided is the highest available on the platform.

[jsquyres]

Isn't this just a quality of implementation issue?

[jsquyres]

Per discussion on the 2016-04-14 teleconf:

• @mahermanns pointed out that a double might be problematic in terms of precision down to the nanosecond level if the number of seconds is very large (e.g., number of seconds from the epoch)
• If there's an interest in returning 2 64-bit integer values, that could be interesting (and in-line with other modern clock APIs)
• Additionally, @kathrynmohror, are you proposing other more interesting topics with regard to time -- e.g. being able to ask for multiple different flavors of time (a la clock_gettime(3)), or provide some level of information about the local / global time synchronization is between MPI processes, or ...?
• How will this affect the MPI_WTIME_IS_GLOBAL attribute on MPI_COMM_WORLD? (which is super-poorly defined, anyway)

[mahermanns]

What if an implementation would return an id that is unique for each independent time source?

This way, a tool could query such id on every process/thread and later check how many independent clock were used and even group processes according to the same clock source. If all processes retrieved the same id there is only one time source in the system, i.e., the time is global.

[mahermanns]

Another thing that arose from the discussion is whether such a new timer would live in the MPIT namespace or should rather be within the MPI namespace to replace MPI_Wtime. Maybe

MPI_Clock_get_time();
MPI_Clock_get_tick();
MPI_Clock_get_id();

[mahermanns]

Chicago meeting notes

Current state of proposal:

MPI_Ticks MPI_Wclock_ticks();
MPI_Ticks MPI_Wclock_ticks_per_second();

with MPI_Ticks being a 64-bit integer.

Straw vote on "Should we pursue this approach"?

• Yes - 15
• No - 0
• Abstain - 12

Rolf pointed out that this timer should be an interface to the same time source as MPI_Wtime().

[jsquyres]

Is there a summary of your presentation about these interfaces that I can read?

My immediate questions to reading this ticket (which you may have covered in person):

• Ticks since when?
• Is ticks guaranteed to be monotonic (I'm specifically thinking of process migration scenarios -- even as simple as migrating to a different processor in the same host)?
• What does ticks_per_second() return if the processor scales its frequency depending on usage?

I suggest having a look at POSIX clock_gettime() for inspiration. Time is not simple. 😦

[mahermanns]

Let's see if I can come to some immediate answers on the current state of the proposal

Ticks since when? Some time in the past. The wording would be kept similar to the one for MPI_Wtime().

Are ticks guaranteed to be monotonic? The current proposal would explicitly require the ticks to be monotonic. Actually, @RolfRabenseifner suggested to even have these new calls actually use the same timer that MPI_Wtime() uses. This would imply, through transitivity that the time reported by MPI_Wtime() would be required to be monotonic. @hjelmn pointed out that users actually expect this behavior. The requirement for MPI_Wtime() to return monotonic time would be part of a different ticket, though.

Are ticks_per_second() constant? My understanding at the meeting was that there is consensus on this being true. Also, @hjelmn argued that any reasonably new TSC-based timer is independent of the state of frequency scaling in the processor and will provide constant ticks. We may certainly need to discuss what choices implementations have when such a TSC-based timer is not available.