Need higher resolution times for linpack benchmark

[Colby Gutierrez-Kraybill]

On Dec 11, 2009, at 2:49 PM, N.M. Maclaren wrote:

> On Dec 11 2009, Tim Prince wrote:
>> Not to be confused with high precision timer implemented in some  
>> cases on Windows, this should be capable of resolution within a  
>> microsecond on linux. OpenMP omp_get_wtime() is likely to be  
>> implemented similar to this.
>
> Dittor MPI_Wtime.  It needs only a POSIX interface, but I have no idea
> whether that is available on Microsoft systems.
>
>> cpu_time still has only 10 millisecond resolution on common  
>> systems, and usually measures total cpu time of all threads,  
>> skipping idle periods, so in general it is a completely different  
>> measurement from elapsed time.
>
> Yes.  If you can explain why CPU time is STILL measured in 10  
> millisecond
> units, 40+ years after that unit was introduced, I should be  
> fascinated
> to hear.  The utterly ridiculous thing is that many systems use a  
> much more
> precise timer to calculate it, and often even store it in more  
> precision,
> yet reduce the accuracy when returning the result to the application.
>
> It's demented.  Just like the way that shifts use only some bits of  
> the
> shift length, 50+ years after the last discrete logic computer was  
> sold.
>

If you're not running a real-time kernel, you will have a quantization  
of times generated because of the time slicing nature of the OS (this  
is not confined to just UNIX systems), an exhaustive explanation can  
be found here: http://en.wikipedia.org/wiki/Preemption_%28computing%29#Time_slice 
  and here: http://oreilly.com/catalog/linuxkernel/chapter/ch10.html

By default, the Linux kernel slices at 100Hz, aka 10ms granularity.   
The current kernel can be reconfigured to slice at 250Hz or 1000Hz,  
giving you quantization of 4ms and 1ms respectively.  While the actual  
time might be printable down to a much higher resolution, if you're  
timing your application via sampling or by software that involves  
using delays measured in milliseconds, you cannot narrow down the  
sampling/delays without fiddling with the kernel.

The original UNIX Kernels started with a 50Hz and 60Hz slice rate  
because of... the power grids and the system clock was taking its beat  
from the power line.

> Regards,
> Nick Maclaren.
>
>