erlang:now() in erlang 4.9.1 on Linux

[Geoff Wong]

> Per writes:
> 
>  > 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. 
> 
> Careful! "monotonic" doesn't mean what you use it to mean, I think. (*)
> 
> The authors of the standard erlang spec write:
> 
>     A 3-tuple of integers is returned that is guaranteed to be
>     different for each invocation on a node.
>     [...]
>     Two calls of the BIF now() by a processes residing on the same
>     node can never return the same term.
>     [...]
>     (footnote)However, the time might be inaccurate if several calls
>     are made within a microsecond.	
> 
> The behaviour Pekka is seeing is wrong, though I think that the
> uniqueness requirement on now() should be removed. If you want
> something unique, use make_ref(). If you want to know the time, call
> now() (or time()).

Sub-microsecond timing isn't currently our problem. But as Per (I think)
demonstrated timing is all "jumpy" when sub < 100 us.

We originally noticed the problem when I was timing "HEAD /" requests
off web servers. I was getting utterly bizarre timings off
our fast machines (1 us for web page delivery - wow - I wish :),
I spent ages trying to work out what was wrong with my code
before i realised it was the timer.

Obviously sub-microsecond execution might be an issue someday soon
(but even an optimised C loop that does a system call like fprintf()
is unlikely to go below a 1 us). Anyway, the current erlang:now() 
(for Linux) is seriously flawed and should be fixed (and or eradicated;
perhaps a different fix should be implemented for system time changes). 

It was probably a plot by FreeBSD guys somewhere in the development
process to discredit Linux :-)

Geoff