George: Indeed, MPI_Wtick is not always a good measure of the precision of MPI_Wtime. The way I would measure resolution is to call MPI_Wtime a few million times.
For example, on Blue Gene/Q, MPI_Wtime was ~220 cycles per call. I don't remember what MPI_Wtick returned, but I guess it was 1./1.6e9, which of course is ~200 times smaller. On the other hand, an implementation based on gettimeofday might claim a resolution of 1.e-6 in MPI_Wtick, but could take an arbitrarily long time, depending on how the OS chooses to implement this system call. Jeff On Fri, Apr 8, 2016 at 7:26 AM, Gilles Gouaillardet < gilles.gouaillar...@gmail.com> wrote: > Dave, > > gettimeofday() uses (seconds, microseconds) to represent the time, and > hence, the resolution is hardcoded to 1 microsecond > clock_gettine() uses (seconds, nanoseconds) and hence the resolution is > hard coded to 1 nanosecond. > this is the max resolution, and it could be lower than that depending on > what gettimeofday() does under the hood. > /* I remember there was an issue with the first software stack of MPSS, > the Xeon phi o/s, and once in a while, the effective time resolution > dropped to 100 Hz, and the MPI application has no way to be made aware of > that */ > > bottom line, in OpenMPI, you should not expect a resolution higher than > MPI_Wtick(), > and yes, it might be (way) worst than that > > Cheers, > > Gilles > > On Friday, April 8, 2016, Dave Love <d.l...@liverpool.ac.uk> wrote: > >> George Bosilca <bosi...@icl.utk.edu> writes: >> >> >> Other implementations of MPI have very accurate counters. >> >> >> > >> > This might be a discutable topic. A quick survey of some of the MPI >> > libraries available on a Linux cluster give the following precision for >> > MPI_Wtime implementation : >> > >> > mpich-3.1.4: wtick = 1.000000e-06 >> > Intel(R) MPI Library 5.1.1 for Linux*: wtick = 1.000000e-06 >> > ompi-1.10.2: wtick = 1.000000e-06 >> > ompi-master: wtick = 1.000000e-09 >> >> Can you trust wtick anyhow? OMPI 1.10 says it's always 10⁻⁶, which >> isn't necessarily realistic even if it uses gettimeofday with a nominal >> 1μs resolution. At least with some (older?) Linuxes, and possibly other >> kernels, gettimeofday is limited to the kernel tick rate -- a few 100 Hz >> if I recall correctly. I'd need convincing about 1ns generally for the >> real time clock too. >> >> Anyhow, experimentally, RHEL6-packaged mpich 3.1's wtime calls >> gettimeofday and not clock_gettime; likewise impi 4.1. >> >> Thanks for fixing ompi, by the way. >> _______________________________________________ >> users mailing list >> us...@open-mpi.org >> Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users >> Link to this post: >> http://www.open-mpi.org/community/lists/users/2016/04/28910.php > > > _______________________________________________ > users mailing list > us...@open-mpi.org > Subscription: http://www.open-mpi.org/mailman/listinfo.cgi/users > Link to this post: > http://www.open-mpi.org/community/lists/users/2016/04/28911.php > -- Jeff Hammond jeff.scie...@gmail.com http://jeffhammond.github.io/
