Experimental Physics and
Industrial Control System

mdavidsaver via Core-talk <core-talk at aps.anl.gov> · Thu, 09 Apr 2020 16:56:29 -0000

I'll try to summarize some thoughts and discussions of the past 2 days or so.
Some of this is (I think) reiterating what Andrew has written.  I'm repeating
it to hopefully demonstrate that I understand it.

1. epicsEventWaitWithTimeout() doesn't function as specified on RTEMS,
vxWorks, or Windows.

With RTEMS and vxWorks I think this can be understood if the integer delay N underlying primitives
rtems_semaphore_obtain() or semTake() block until the Nth tick of timer (interrupt).  So a call with delay of one may timeout almost immediately if made just before a tick.

So a timeout of N may result in times between T*(N-1) and T*N where T is
the tick timer interval.

This functions like a truncation, but is separate, and cumulative to the
truncation/rounding done in epicsEventWaitWithTimeout() converting
floating point seconds to ticks.

So the minimal change to ensure epicsEventWaitWithTimeout() behaves as
specified (timeout after >=delay) involves a float to int conversion
like:

> double delay = ...;
> unsigned ticks = tickRate * delay;
> ticks += 2;

2. There may be more than one issue involved.

epicsEventWaitWithTimeout() was not affected by 4f2228fb1d7527fb5ebc8b2d747c309f1dd7698d.
The effect of this commit on the timer queue which Mark reports is (I think) in changing the delay values passed to epicsEventWaitWithTimeout().  It is not known whether these delay values would produce the correct behavior if epicsEventWaitWithTimeout() functioned as specified.

I think this question could be answered using an RT linux or RTEMS5
system with a software DAC and an oscilloscope.

3. Windows is peculiar

The Windows impl. uses WaitForSingleObject() which takes a timeout in milli-seconds,
but seems to behave as if it were internally doing a similar truncation.
The delays I've observed seem to be round down to multiples of epicsThreadSleepQuantum().

4. Quantization of monotonic time effecting epicsEventTest

epicsEventTest on Windows is sometimes reporting measured delays of exactly zero.
I think this is due to effective delays being less than the monotonic time quantum,
which is reported as 1ms for the appveyor builds.  epicsEventTest tries to test down
to the 10's of microseconds.

-- 
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Base.
Matching subscriptions: epics-core-list-subscription
https://bugs.launchpad.net/bugs/1861612

Title:
  callbackRequestDelay not waiting for 1/60 sec on vxWorks

Status in EPICS Base:
  Triaged

Bug description:
  The problem is documented in this tech-talk thread:
  https://epics.anl.gov/tech-talk/2020/msg00308.php

  In 7.0.3.1, but not in 7.0.3, callbackRequestDelay(1/60) results in
  100% CPU time, most of the time in cbHigh.

  This happens on vxWorks 6.9.4.1 and was first seen with the scaler
  record with multiple types of scaler hardware and device support.

To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1861612/+subscriptions

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System