On 10/14/10 07:37, Jeff Squyres wrote:
On Oct 13, 2010, at 4:52 PM, Michael E. Thomadakis wrote:
Does MPI_Wtime of OMPI 1.4.3/1.5.0 rely on high resolution clocks (for Linux)
or does still rely on gettimeofday() ? How would one request at OMPI built time
to let it use high resolution clocks?
Check the man page for MPI_Wtime(3):
On POSIX platforms, this function may utilize a timer that is cheaper
to invoke than the gettimeofday() system call, but will fall back to
gettimeofday() if a cheap high-resolution timer is not available. The
ompi_info command can be consulted to see if Open MPI supports a native
high-resolution timer on your platform; see the value for "MPI_WTIME
support" (or "options:mpi-wtime" when viewing the parsable output). If
this value is "native", a method that is likely to be cheaper than get-
timeofday() will be used to obtain the time when MPI_Wtime is invoked.
IIRC, the problem on Linux is that the native x86 timers are a per-chip value
(e.g., on a multi-socket system, the value is different on each socket).
Hence, if you MPI_Wtime() while your MPI process is on socket A, but then the
OS moves it to socket B and you call MPI_Wtime() again, the two values are
completely unrelated.
That being said, I see clock_gettime() has CLOCK_REALTIME, which is supposed to
be system-wide. Is it cheaper and/or more accurate than gettimeofday? I see
that it has nanosecond precision in the man page, but what is it (typically)
actually implemented as?
In the POSIX compliant UNIX world clock_gettime() always had s 2-3
orders of magnitude better sampling resolution vs gettimeofday(). I know
that OMPI 1.4.2 is relying on gettimeofday() and I was wondering if this
changed with 1.4.3 and 1.5.0.
I just read on some Internet postings that stating with Linux kernel
2.6.18, gettimeofday() uses the
clock_gettime(CLOCK_REALTIME)
as source so things may not be as "ugly" any more when one samples the
gettimofday();
Additionally, I suppose that if a process is bound to a single native clock scope (I
don't know offhand if it's per socket or per core -- I said "socket" up above,
but that was a guess), we could make the *assumption* that the process will never move
and might be able to use the native x86 timer (there's some complications here, but we
might be able to figure it out). Bad Things could happen if the process ever moved,
though (e.g., if the application ever manually changed the binding).
This APIs were put together by the Real-Time work group of the POSIX
community to address exactly these issues of non-global clocks or of
clocks which back-step in time when NTP for instance adjusts the clock
(with CLOCK_MONOTONIC). So the question now is if OMPI relies on
gettimeofday() and if indeed Linux 2.6.18 uses as its time source the
clock_gettime(CLOCK_REALTIME) and if Linux complies with the glbal per
system CLOCK_REALTIME requirements. Another problem is when power
management adjusts the frequency of the CPU clock....
anyways thanks for the answer
Michael
