From: Jan Simon on
Dear us,

> here's a bit of information...
> http://www.mathworks.com/access/helpdesk/help/techdoc/matlab_prog/f8-790895.html

Thanks for this hint.
It is clear and acceptable, that CPUTIME has limitations for measuring a period of time. TIC/TOC has severe problems also, if you run Matlab in a virtual machine - as any kind of internal speed measurement. Multi-, hyper-threading and machines with different speeds for multiple cores are simply not a good base for a physically meaningful definition of "tics per second".
Even the value of CLOCK is controlled by the OS, e.g. when an NTP server updates the internal clock. In consequence, the *relative* times measured by two calls of CLOCK have a limited meaning.

However, even the *absolute* value of the 1/1000 seconds replied by CLOCK and CPUTIME are dubious. (sorry for repeating myself again)

Jan
From: Greg Heath on
On Jun 25, 10:27 am, "Jan Simon" <matlab.THIS_Y...(a)nMINUSsimon.de>
wrote:
> Dear Matlab users,
>
> Obviously the precision of CPUTIME and and CLOCK is not so important for the members of this newsgroup. I'm going to ask the support for an explanation.
>
> Kind regards, Jan

I remember getting all timings as integer multiples of

1/60 = 1.6666666666666667e-2

Hope this helps.

Greg