Need higher resolution times for linpack benchmark

[N.M. Maclaren]

On Dec 11 2009, Colby Gutierrez-Kraybill wrote:
>>
>>> 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.

This is rather off-topic, so I won't continue after this, but I am afraid
those are entirely post-hoc justifications and are largely established
urban myths.

The 10 millisecond resolution predates Unix by a decade, and even predates
time-slicing.  Yes, really.  It was certainly the case on IBM MFT and, if
I recall, ICL George 2 and others.  But my memory of the details of 1960s
operating systems is fading ....

Also, you have missed the point that the system is internally measuring
the time much more precisely, and the reduction to 10 milliseconds is
SEPARATE from the time-slicing interval, though it is sometimes linked
by parameterisation of the supervisor (the old term) or kernel.  If you
poke at the kernel control structures, you can often get at the REAL
measurement, which is often in microseconds.

That assertion about the mains frequency has been common for decades, but
I enquired further in the early 1970s and could find nobody who could
think of any system that had actually used a mains clock!  And their
knowledge dated back to the 1940s!  I am pretty sure that that is an
urban myth, that gives a plausible but erroneous explanation.

Last, I overstated the case with shifts.  Integrated circuits didn't
replace discrete logic until the early 1960s, so it's only 45+ years :-)


Regards,
Nick Maclaren.