MPI_Wtick is not about the precision but about the resolution of the underlying timer (aka. the best you can hope to get). Thus, the measured time will certainly be larger, but, and this is almost a certainty, it will hardly be smaller. As a result, I am doubtful that an MPI implementation will provide an MPI_Wtime with a practical resolution smaller that whatever the corresponding MPI_Wtick returns.
George. On Fri, Apr 8, 2016 at 2:42 PM, Jeff Hammond <jeff.scie...@gmail.com> wrote: > 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/ > > _______________________________________________ > 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/28912.php >
