Comment 21 for bug 1861612

You'd have to ask me that question back in July 2012 for my thinking back then, 0.99999999 is probably the largest double that doesn't get rounded up to 1.0 by the compiler.

I tried changing the RTEMS version of epicsEventWaitWithTimeout() to add 0.99999999 before it casts the delay to an int number of ticks, but I still get one failure on most runs of the normal epicsEventTest program:

not ok 14 - epicsEventWaitWithTimeout(0.500000) delay error -0.000042 sec
not ok 14 - epicsEventWaitWithTimeout(0.500000) delay error -0.000004 sec
not ok 14 - epicsEventWaitWithTimeout(0.500000) delay error -0.000027 sec

The result is better though, previously I was getting a lot more:

ok 12 - epicsEventWaitWithTimeout(0.000000) delay error 0.000284 sec
not ok 13 - epicsEventWaitWithTimeout(1.000000) delay error -0.000013 sec
not ok 14 - epicsEventWaitWithTimeout(0.500000) delay error -0.000023 sec
not ok 15 - epicsEventWaitWithTimeout(0.250000) delay error -0.009993 sec
not ok 16 - epicsEventWaitWithTimeout(0.125000) delay error -0.004983 sec
not ok 17 - epicsEventWaitWithTimeout(0.062500) delay error -0.002499 sec
not ok 18 - epicsEventWaitWithTimeout(0.031250) delay error -0.011321 sec
ok 19 - epicsEventWaitWithTimeout(0.015625) delay error 0.004375 sec

The mean delay error is higher with that change as expected, by about 1 tick:

ok 33 - Mean delay error was 0.014291 sec
ok 33 - Mean delay error was 0.014293 sec
ok 33 - Mean delay error was 0.014296 sec

instead of

ok 33 - Mean delay error was 0.013231 sec
ok 33 - Mean delay error was 0.013224 sec

Requests of less than 1 tick generally insert a delay very close to 2 ticks (~0.019 seconds).

Note though that this test probably starts most of the delays shortly after the previous tick occurred; I wasn't using the busy-wait here that I described in
  https://bugs.launchpad.net/epics-base/+bug/1861612/comments/18