Is std.time.Timer realtime safe?

nat3Github · March 9, 2025, 4:48pm

Is std.time.Timer suitable for use in realtime applications?

specifically my application would be audio processing.
with suitable this is meant:

time cost is always under 500 micro seconds (upper bound for worse case performance)
no blocking
no underlying os calls that may block
no allocation (im guessin thats the case as allocations are explicit in std)
suitable on all platforms where it is supported

kj4tmp · March 9, 2025, 7:27pm

Last time I looked at the source code, it will use Linux CLOCK_BOOTTIME, which should be your highest quality monotonic clock source.

I woundnt be concerned about the time required for the syscall.

There was a recent issue on windows that it wasn’t using the highest resolution clock available, but I believe that was resolved.

You must query the OS to get the time. The OS is your mediator to the outside world (IO).

If you need true realtime processing, I would avoid windows and use Linux with PREEMPT_RT patch or figure out how to get the most recent kernel (I haven’t figured that out yet).

squeek502 · March 9, 2025, 7:37pm

If you have specific requirements in mind, the best advice is to read the source code. Pretty much all of the standard library is extremely readable.

The most relevant function for your questions is Instant.now:

github.com

ziglang/zig/blob/master/lib/std/time.zig#L134-L168


      
          pub fn now() error{Unsupported}!Instant {
              const clock_id = switch (builtin.os.tag) {
                  .windows => {
                      // QPC on windows doesn't fail on >= XP/2000 and includes time suspended.
                      return .{ .timestamp = windows.QueryPerformanceCounter() };
                  },
                  .wasi => {
                      var ns: std.os.wasi.timestamp_t = undefined;
                      const rc = std.os.wasi.clock_time_get(.MONOTONIC, 1, &ns);
                      if (rc != .SUCCESS) return error.Unsupported;
                      return .{ .timestamp = ns };
                  },
                  .uefi => {
                      var value: std.os.uefi.Time = undefined;
                      const status = std.os.uefi.system_table.runtime_services.getTime(&value, null);
                      if (status != .success) return error.Unsupported;
                      return .{ .timestamp = value.toEpoch() };
                  },
                  // On darwin, use UPTIME_RAW instead of MONOTONIC as it ticks while
                  // suspended.

This file has been truncated. show original

FObersteiner · March 10, 2025, 7:08am

maybe also interesting in this context: What is the resolution of std.time.Timer and is it good enough?

My experience from benchmarking on Linux is that you end up with an uncertainty in the 10-100 ns range; this is highly context-dependent, i.e. what other stuff the OS is doing, and what is prioritized.