Experimental Physics and
Industrial Control System

On 8/4/20 9:09 AM, Johnson, Andrew N. wrote:

On Aug 3, 2020, at 9:37 PM, Michael Davidsaver <mdavidsaver at gmail.com <mailto:mdavidsaver at gmail.com>> wrote:

On 8/3/20 6:07 PM, Johnson, Andrew N. wrote:

No. I get non-zero milli- and microseconds in my time stamps now, but (counting after the decimal point) digits 7 through 9 of a %.9f seconds value are always zero.

Ok, then this seems likely to be no worse that Windows.
Out of curiosity, have you checked (eg. with epicsTimerTest)
to see what the minimum delta actually is?

In the Github issue yesterday I explained that on my laptop reading the time using the Mach clock_get_time() API takes about 1.6 microseconds and gives nanosecond precision, whereas using clock_gettime() takes only about 58 nanoseconds but gives microsecond precision (as averaged over 100000 readings by epicsTimeTest). Which is better?

I was referring to the smallest non-zero delta in the time
values returned by consecutive calls.  aka. is it really
microsecond precision?

I don’t see where epicsTimerTest is measuring that at all. There is something like that in epicsTimeTest for characterizing the monotonic time routines but not for the wall-clock time (and the calculations in the crossCheck() measurements are a bit strange).

All the time-stamps I now see from the IOC have 6 varying digits after the decimal point, then 3 zeros. The code in database/test/std/rec/simmTest now displays time-stamp differences to 9 decimal places and the last 3 of those are always 0; the smallest non-zero value I can find in those differences is 0.000001000 sec, so yes I believe it is really giving clock times with microsecond resolution.

- Andrew