erlang:now() in erlang 4.9.1 on Linux
Wed Apr 19 11:46:09 CEST 2000
Sorry, I meant to cancel this post, but my fingers tricked me.
I've read erl_time_sup.c and have nothing really intelligent to
contribute at the moment.
On Wed, 19 Apr 2000, Ulf Wiger wrote:
>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 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..?
Ulf Wiger, Chief Designer AXD 301 <>
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