[Octave-bug-tracker] [bug #52858] Consider using C gnulib clock_gettime() for Octave cputime()

[Michael Godfrey]

Follow-up Comment #7, bug #52858 (project octave):

The "resolution" of the time function is not the problem.
If it were, just running the test longer would fix it.

The problem is that, from the very beginning of UNIX days,
kernel processes are NOT interruptible. Therefore any
user process may take any amount of real-time. And,
the attempts measure and make available cpu-time are
affected in the same way. There is no predictable time
lapse in gaining access to the kernel time data.

The answer is the make multiple runs of the same (fairly
long) test and then choose a suitable "average." It can
be argued that the "best" choice is the minimum reported value.
This one will have been least affected by delays during
kernel processes. Keep in mind that read/write to I/O
devices are kernel processes so quite a few seconds can elapse
before anything else can happen to timing calls or anything
else.

This choice was made by the original Bell Labs UNIX folks
when they thought that what they were doing was building a
convenient, single-user, report writing system. The rest is
history...

Even running Linux as a virtual system under a controlling
system which does not use uninterruptible calls does not
fix the problem because the Linux call still has to block until
its results are returned. System efficiency is improved by
this choice, but it does not change the behavior of client
systems.

So, any of the timing routines can be chosen. 

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?52858>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/