Need higher resolution times for linpack benchmark

[Colby Gutierrez-Kraybill]

On Dec 12, 2009, at 1:12 AM, N.M. Maclaren wrote:

> 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.
>

Sorry, I should have tied it back to the topic, which, has already  
been addressed by Steve Kargl.  Urban myth regarding the 60Hz mains  
clocking or not if your benchmark is running so quickly that you are  
running up against time-slicing quantization, such as process context  
switching, then your benchmark is probably worthless.

> 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 ....
>

Again, sorry, I didn't mean to imply that somehow the original 10ms is  
determined by UNIX or time-slicing, my point was about the  
quantization effects of the time-slicing.

> 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.
>

Many computing systems from the 70's era had their main clock tied to  
the update frequency of the video, aka NTSC, aka 59.95Hz, making it  
very easy for the computer logic to work well with the update rates of  
the video memory.  The frequency of NTSC being driven by... the mains  
cycling.  So, you're right, the mains power didn't drive the clocks  
directly, and, I'm right, the time-slicing was driven by the  
requirement to interface to 60Hz clock that came with the NTSC standard.

Cheers,
Colby