erlang:now() in erlang 4.9.1 on Linux

Ulf Wiger etxuwig@REDACTED
Wed Apr 19 11:43:35 CEST 2000

I don't know if this answers your questions, but it may provide some
background to erlang:now() issues.

At AXD 301, we've had some problems with the internal time
representation, as we've run some pretty abusive tests on the network
time synchronization mechanisms. We voiced the requirement that the
real-time clock must operate reliably regardless of the system time.

The specific problem is when you do stuff like "rdate" on a running
system, or someone manually alters the system clock. In previous
versions of Erlang/OTP, this was disastrous for the system, since
timeouts, and erlang:now(), were based on the system clock.
For example, if the system time was set back a couple of hours,
timeout activity in Erlang would basically stop until the system
clock "caught up" with the Erlang clock. This would throw our system
into some kind of undefined state.

In our current, patched version of OTP R5B01, we have a VM modified to
decouple the internal Erlang clock from the system clock, and then
checkpoint the two every once in a while. Should the clocks drift
apart, the internal Erlang clock will adjust itself (=< +-1%) to
slowly synchronize with the system clock.


On Wed, 19 Apr 2000 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).
>For example, calling gettimeofday() in Linux directly every ~7 
>microseconds also returns ~7 micro each time. 
>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?  
>If so, how is one to measure time in a way that avoids these "jumps"?  
>Write a linked in driver calling gettimeofday() directly etc..?
>Ideas, oppinions?

Ulf Wiger, Chief Designer AXD 301         <ulf.wiger@REDACTED>
Ericsson Telecom AB                          tfn: +46  8 719 81 95
Varuvägen 9, Älvsjö                          mob: +46 70 519 81 95
S-126 25 Stockholm, Sweden                   fax: +46  8 719 43 44

More information about the erlang-questions mailing list