Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider a faster clock #2

Open
ahacking opened this issue Oct 7, 2023 · 0 comments
Open

Consider a faster clock #2

ahacking opened this issue Oct 7, 2023 · 0 comments

Comments

@ahacking
Copy link

ahacking commented Oct 7, 2023

Consider use of clock_gettime(CLOCK_MONOTONIC_COARSE, &ns) which may provide a lower overhead clock vs gettimeofday().

This Stack overflow answer provides some indicative cycle counts:

gettimeofday (us) => 42 cycles

clock_gettime (ns) => 9 cycles
(CLOCK_MONOTONIC_COARSE)

The use of CLOCK_MONOTONIC_COARSE is supported on Linux and FreeBSD, but is an extension to POSIX from what I can tell with 1ms resolution and uses the VDSO library to avoid kernel calls.

Given the extension only needs millisecond resolution it doesn't diminish the accuracy using the faster coarse grained clock.

So a portability #ifndef will undoubtedly be required to fall back to CLOCK_MONOTIC on systems that don't define the coarse clock.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant