Woodchuck wrote:
> I. The system call clock_getres(2) and clock_gettime(2) show strange
> results.
>
> Consider this small program and its output on OpenBSD 5.0, amd64:
>
> #include <stdio.h>
> #include <sys/time.h>
>
> main()
> {
> struct timespec tp;
> int i;
>
> clock_getres(CLOCK_REALTIME, &tp);
> printf("Resolution: %lu %lu\n", tp.tv_sec, tp.tv_nsec);
> for (i = 0; i < 10; i++) {
> clock_gettime(CLOCK_REALTIME, &tp);
> printf("Performance: %lu %lu\n", tp.tv_sec, tp.tv_nsec);
> }
> return 0;
> }
>
> Resolution: 0 10000000
> Performance: 1331012858 566149475
> Performance: 1331012858 566158834
> Performance: 1331012858 566164422
> Performance: 1331012858 566169031
> Performance: 1331012858 566173152
> Performance: 1331012858 566177202
> Performance: 1331012858 566181253
> Performance: 1331012858 566189075
> Performance: 1331012858 566195570
> Performance: 1331012858 566219945
>
> Surely the clock is resolving better than 10 milliseconds?
>
I encounter a similar limit trying to send uncompressed audio over the
network using SIGALRM. (over UDP, I can't really make packets small enough
to fit them into the network MTU and get them delivered in time)
I vaguely remembered reading about a 10 ms limit somewhere. Don't know for
sure this relates to your "problem" since I'm taking this out of the
context of setitimer(2), which says:
"Time values smaller than the resolution of the system clock are rounded
up to this resolution (typically 10 milliseconds)."
Don't want to pretend to know what I'm talking about but this thread
suggests to me that OpenBSD potentially has this limitation inside its CPU
scheduler. (http://marc.info/?l=openbsd-tech&m=131842430012097&w=2)
