erlang:now() in erlang 4.9.1 on Linux

[Per Hedeland]

Pekka.Hedqvist@REDACTED wrote:
>When trying to measure time we get really weird values from the
>'erlang:now()' when two successive calls to it are done with less than
>100 microseconds between the two calls. The values are far too low; 0,
>1 microseconds are reported even when maybe 60-80 has passed. If the
>calls are made further apart timewise they suddenly jump up to
>reasonable represent the passed time (when > ~100 micro has passed).

Do you really ever see a difference of 0 microseconds? That would be a
serious bug, monotonically increasing values is just about the only
thing erlang:now() *really* promises to produce. I can't reproduce
*that* even by calling it several thousand times in a tight loop (on
RedHat 6.1).

I do however see jumps along the lines of what you describe,
specifically when doing the above tight-loop calls it increases by 1
microsecond on each call for several hundred calls, then makes a jump of
8000-9000 microseconds, then 40-50 "reasonable" increments, and then
back to 1 microsecond increments again.

>Looking at the erl_time_sup.c one sees that it builds without
>gethrtime() (since its not available in plain Linux) and with the
>'CORRECT_USING_TIMES' defined. 'erlang:now()' results in a call to
>get_tolerant_timeofday(void) which does a number of things, some
>regarding internal erlang timing etc.
>
>I asume (hopefully) that the get_tolerant_timeofday(void) does the
>right things regarding Erlangs internal view of time, but is its
>side-effect on functions like erlang:now() really desirable?  

Well, it has to affect erlang:now() (see Ulf's message for why these
corrections are done at all), but it shouldn't have *this* effect - in
fact unless you keep changing the system time, it shouldn't have any
effect at all. It seems clear that the reason is that the 10-ms
resolution of times() is incorrectly affecting the results, and indeed
it goes away if you recompile without CORRECT_USING_TIMES defined - so
doing that is at least a workaround for now (at least for the problem
I'm seeing). 

Incidentally, Linux is currently the only OS that CORRECT_USING_TIMES
gets defined on - I don't know how many besides Solaris that have
gethrtime().

--Per Hedeland
per@REDACTED