time syncronization in erlang cluster
Fri Jan 9 13:33:48 CET 2004
Of course there's a catch:
If the computer running the Erlang node is set for
any other timezone than Universal Time (UDT), the
system clock will make jumps that erlang:now() will
not be able to adjust to within reasonable time.
On Unix systems, one creative way of getting around
this (if, for any reason, you can't run the whole system
in UDT) is to use os:setenv/2 and set the TZ environment
variable to UDT inside the Erlang node.
Also, it's probably a good idea to have a background
process sampling erlang:now() and time(), comparing the
two. If the difference is too great (pick your definition
of "too great"), it might be wise to restart the node.
This is only really relevant if erlang:now() is ever used
to sample time, which it shouldn't be. But if hi-res time
is needed within Erlang, there is really no convenient
option other than erlang:now(). A flaw, in my opinion.
On Fri, 9 Jan 2004 10:51:07 +0200, Primanathan Reddy [ MTN - Innovation
Centre ] <> wrote:
> Thanks for the helpful info on now().
> I'm going to try NTP.
> Will keep the list updated on how it turns out.
> -----Original Message-----
> From: Ulf Wiger [mailto:]
> Sent: Thursday, 08 January 2004 8:09 PM
> To: WILLIAMS Dominic; Erlang (E-mail)
> Subject: Re: time syncronization in erlang cluster
> On Thu, 8 Jan 2004 14:19:46 +0100, WILLIAMS Dominic
> <> wrote:
>> Hi Pete,
>>> What is the platform? If you're using a flavour of UNIX, you
>>> may wish to use NTP (network time protocol RFC 1305) and
>>> bypass Erlang for synchronisation. I imagine there are NTP
>>> clients and servers implemented for most platforms.
>> Indeed, including Windows (just don't use Microsoft's built-in
>> version, which is simplified, if you want the features I
>> described in my previous post).
>> However, this doesn't work, at least for Erlang systems running
>> uninterruptedly, if the Erlang runtime only gets the system time
>> at start-up...
> This is how erlang:now() works.
> At startup, it samples the system time, and then it starts running
> loosely coupled to the system time. That is, it periodically samples
> the system time and makes small adjustments (+/- 1%) so that it
> will eventually converge with the actual system time ("eventually"
> may be an arbitrarily long time, depending on what happens to the
> system time.)
> So to answer your initial question: you cannot synchronize erlang:now(),
> since it is designed to adjust itself to e.g. NTP, while preserving the
> property that subsequent calls to erlang:now() should always return
> unique values in increasing order.
More information about the erlang-questions