erlang:now() in erlang 4.9.1 on Linux
Sat Apr 22 05:43:51 CEST 2000
> 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 :-)
More information about the erlang-questions