Notes 2016 04 14

Participants

• Jean-Baptiste Besnard
• James Custer
• Jeff Squyres
• Marc-Andre Hermanns
• Nathan Hjelm
• Michael Knobloch
• Soren Rasmussen
• khaled (?)

Topics

• Updates to high-res timer ticket
  • double return value may be problematic for precision if the number of seconds is large.
  • UNIX calls such as clock_gettime() use two 64-bit integers
  • Should a new call use MPI_ or MPI_T_ namespace?
  • Would it be beneficial if one could query a unique id per clock source to identify those processes/threads that share the same clock?
• MPI_T Events
  • Separate clock source
    • As long as tools can obtain timestamps from the timer used by the internal measurement system, it should not be a problem to merge events from different clock sources
    • Clock needs to provide a constant frequency
    • Clock must not pause
  • Callbacks are very limited in their capabilities (no memory allocation, no syscalls, ...). Would this be enough for current measurement systems? Sampling-based measurement systems should already deal with this. What about the others?
  • If events cannot be triggered on the thread/process where they were registered, it should be possible to trigger them on a consistent location with a separate event buffer.
  • If events are triggered one-by-one, the tool can provide the timestamp
  • If infrastructure provides buffer with multiple events those need to be timestamped by the infrastructure and in chronological order
  • If events are distributed between different buffers, how can we ensure chronological order? Do we need to? What would be the use-case for distributing events to different queues?
  • Are callbacks triggered sequentially (one at a time) or in parallel?