Function thread_sleep_quantum 

pub fn thread_sleep_quantum() -> f64

The OS clock-tick period, in seconds — C epicsThreadSleepQuantum().

posix (libcom/src/osi/os/posix/osdThread.c:1108-1116):

double epicsThreadSleepQuantum(void)
{
    double hz = sysconf(_SC_CLK_TCK);
    if (hz <= 0) return 0.0;
    return 1.0 / hz;
}

Records use it to round a delay field to a whole number of ticks — e.g. sseqRecord.c:197-200 quantizes every DLYn at init. Returns 0.0 when the tick rate is unavailable, exactly as C does; callers must treat that as “no quantization” rather than dividing by it.

Why this asks instead of stating

The tick rate is not ours to declare. On RTEMS it is set by CONFIGURE_MICROSECONDS_PER_TICK in epics-rtems-boot’s csrc/rtems_config.c, which is deliberately #ifndef-overridable from the build so a timing experiment needs no source edit. A Rust constant here would be a second copy of that number, silently wrong the first time anyone overrides it — with nothing checking the two agree.

So the unix arm asks, and the answer comes from the same define:

sysconf(_SC_CLK_TCK)
  -> rtems_clock_get_ticks_per_second()      cpukit/posix/src/sysconf.c:60-61
  -> _Watchdog_Ticks_per_second              rtems/rtems/clock.h:871
   = 1000000 / CONFIGURE_MICROSECONDS_PER_TICK   confdefs/clock.h:100-101

This is also what C itself does on RTEMS — RTEMS-score/osdThread.c:860-865 returns 1.0 / rtemsTicksPerSecond_double rather than a constant — so the port matches C’s behaviour on the target, not just on posix.

The non-unix (Windows) arm keeps a constant. _SC_CLK_TCK is 100 on Linux and macOS, and 100 Hz is the historical default this port shipped; it restates no #define of ours. It is not C parity: WIN32/osdThread.c:906-932 asks GetSystemTimeAdjustment and returns 0.0 on failure. Closing that gap needs a Windows syscall dependency this crate does not have, and is a separate change from the RTEMS one.