Experimental Physics and
Industrial Control System

Michael Davidsaver via Core-talk <core-talk at aps.anl.gov> · Mon, 3 Aug 2020 16:53:16 -0700

On 8/3/20 4:02 PM, Johnson, Andrew N. via Core-talk wrote:
> On Aug 3, 2020, at 4:36 PM, APS Jenkins via Core-talk <core-talk at aps.anl.gov <mailto:core-talk at aps.anl.gov>> wrote:
>>
>> See <https://jenkins.aps.anl.gov/job/epics-7.0/OS=mac/245/display/redirect?page=changes>
> 
> So the change I committed earlier to Darwin's osdTimeGetCurrent() speeds it up significantly, but apparently at the expense of not giving nanosecond precision any more – I guess that’s probably not terribly surprising.

> All my wall-clock timestamps now have 000 in the nanoseconds part,

Do I read this correctly?  Effective time resolution would be limited to 1 second on Mac?

> although the monotonic clock isn’t affected as it uses a different kernel API.
> 
> The failures in the above Jenkins Mac build were these:
> 
>> simmTest.tap .............. 
>> not ok 136 - time stamp is recent
>> not ok 311 - time stamp is recent
>> not ok 435 - time stamp is recent
>> not ok 803 - time stamp is recent
>> not ok 996 - time stamp is recent
>> not ok 1171 - time stamp is recent
>> Failed 6/1176 subtests 
>> 	(42 TODO tests unexpectedly succeeded)
> 
> The problem is that in several places the test code is doing this:
> 
>> testOk(epicsTimeLessThan(&now, mytime), "time stamp is recent");
> 
> which fails when now and *mytime are identical. I am changing that code to:
> 
>> double diff = epicsTimeDiffInSeconds(mytime, &now);
>> testOk(diff >= 0.0, "time stamp is recent (%.9f sec)", diff);
> 
> Equality is now always allowed, and we get to see how different the timestamps actually are.
> 
> One of these (but not all) is inside a testTodoBegin("imprecise"); region.
> 
> - Andrew
> 
> -- 
> Complexity comes for free, simplicity you have to work for.
> 

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System