Garbage collector can add latency on the order of clock tick (usually
10ms, 2.5ms, or 1ms) to each run.
This is due to some runtime·usleep(1) and runtime·usleep(100) calls,
which get rounded up to clock period when HPETs are not used.
More details in this thread:
Linux uses HPETs by default, but most ARM machines don't have HPETs.
Solaris doesn't use HPETs by default, so this issue affects arm
machines and solaris.
I'm not sure if we need to do anything (maybe we can just assume
"fast" machines), I'm logging it so we can refer to it later.
The text was updated successfully, but these errors were encountered:
Yes, at the moment it gets rounded up to 10ms on Solaris. I haven't measured on
linux/arm, I expect it to be 2.5ms.
For Solaris, I'll change the runtime to use HPETs (although that has other issues), for
linux/arm we can't do this because there are no HPETs.
Here are some sample numbers for the observed delay of usleep(1)
% uname -a
Linux lucky 3.11.0-19-generic #33-Ubuntu SMP Tue Mar 11 18:48:34 UTC 2014 x86_64 x86_64
% cc time.c && ./a.out
usleep(1) took 72298 ns
panda(~) % uname -a
Linux panda 3.7.10-x13 #1 SMP Wed Jun 26 07:33:15 UTC 2013 armv7l GNU/Linux
panda(~) % cc time.c && ./a.out
usleep(1) took 122070 ns
In both cases these represent the best results I have seen, during some runs I have seen
the arm numbers spike to 150us and the amd64 numbers spike to 140us
> runtime·usleep(1) and runtime·usleep(100) are really intended to be more
> like scheduler yields, rather than sleeps if the system can't handle them,
> it can just do scheduler yield
Indeed, replacing sleeps with yields solves the problem: