ERTS timeouts don't account for computer suspension

Guilherme Andrade g@REDACTED
Mon May 11 11:45:14 CEST 2020


On Sun, 10 May 2020 at 23:27, Rickard Green <rickard@REDACTED> wrote:

> On Sun, May 10, 2020 at 11:05 PM Rickard Green <rickard@REDACTED> wrote:
>
>> On Sun, May 10, 2020 at 9:20 PM Guilherme Andrade <g@REDACTED> wrote:
>>
>>> Hello list,
>>>
>>> I've recently run into an unexpected behaviour of erlcron[1] - it
>>> doesn't account for any time period the computer spends suspended -
>>> scheduled events get delayed by equal amounts.
>>>
>>> This is because it leverages gen_server timeouts which, in turn, use
>>> bog-standard VM timeouts, which behave in the way I described. I've
>>> confirmed[2] their behaviour by comparing time elapsed until timeout
>>> according to erlang:monotonic_time/1 vs. os:system_time/1.
>>>
>>> After delving into the Erlang/OTP source code for a while I realized
>>> there are two configuration options[3] that appear to control the
>>> unexpected behaviour: "--enable-prefer-elapsed-monotonic-time-during-suspend"
>>> and "--disable-prefer-elapsed-monotonic-time-during-suspend",
>>> introduced[4] in OTP 18.0.2.
>>>
>>> The default value of the setting configured by either of those two
>>> options is "no"[5] - that is, elapsed monotonic time during suspend is not
>>> prefered.
>>>
>>> I would like to know the rationale for this. Is it for:
>>> - performance reasons? (say, because it's faster and server hardware
>>> rarely suspends, if at all)
>>> - intended behaviour? (contrary to my expectations)
>>>
>>> I'd be thankful for your thoughts on this matter and whether you think
>>> the default behaviour should be changed.
>>>
>>> [1]: https://github.com/erlware/erlcron
>>> [2]: https://gist.github.com/g-andrade/508c779a931dde14c22c6e96319caa24
>>> [3]:
>>> http://erlang.org/documentation/doc-10.5/doc/installation_guide/INSTALL.html#configuring
>>> [4]:
>>> https://github.com/erlang/otp/commit/4a864c1cbe16a42f3f5190881187e3c9849e985f
>>> [5]:
>>> https://github.com/erlang/otp/blob/OTP-22.3.4/erts/aclocal.m4#L2355-L2358
>>>
>>> <https://github.com/erlang/otp/blob/OTP-22.3.4/erts/aclocal.m4#L2355-L2358>
>>>
>>> --
>>> Guilherme
>>>
>>
>> Yes, for performance reasons. See release note from OTP 18.0.2 <
>> http://erlang.org/download/OTP-18.0.2.README>:
>>
>>   OTP-12895    Application(s): erts
>>
>>                *** POTENTIAL INCOMPATIBILITY ***
>>
>>                Changed default OS monotonic clock source chosen at
>>                build time. This in order to improve performance. The
>>                behavior will now on most systems be that (both OS and
>>                Erlang) monotonic time stops when the system is
>>                suspended.
>>
>>                If you prefer that monotonic time elapse during suspend
>>                of the machine, you can pass the command line argument
>>                --enable-prefer-elapsed-monotonic-time-during-suspend
>>                to configure when building Erlang/OTP. The
>>                configuration stage will try to find such a clock
>>                source, but might not be able to find it. Note that
>>                there might be a performance penalty associated with
>>                such a clock source.
>>
>>
>>
>> Regards,
>> Rickard
>> --
>> Rickard Green, Erlang/OTP, Ericsson AB
>>
>
>
> I missed this part:
>
> > I'd be thankful for your thoughts on this matter and whether you think
> the default behaviour should be changed.
>
> I do *not* think the default should be changed. I would be very surprised
> if it is more than a very small minority of users that are interested in
> elapsed time during OS suspend. More or less everyone would have to take
> this performance penalty without any benefit. I don't remember any figures
> since this was 5 years ago, but I remember that the performance penalty was
> quite substantial.
>

OK, crystal clear - that makes perfect sense.

Thanks!


>
> Regards,
> Rickard
> --
> Rickard Green, Erlang/OTP, Ericsson AB
>


-- 
Guilherme
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20200511/39df889d/attachment.htm>


More information about the erlang-questions mailing list