ERTS timeouts don't account for computer suspension

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

ERTS timeouts don't account for computer suspension

Guilherme Andrade
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.


--
Guilherme
Reply | Threaded
Open this post in threaded view
|

Re: ERTS timeouts don't account for computer suspension

Rickard Green-2
On Sun, May 10, 2020 at 9:20 PM Guilherme Andrade <[hidden email]> 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.


--
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
Reply | Threaded
Open this post in threaded view
|

Re: ERTS timeouts don't account for computer suspension

Rickard Green-2
On Sun, May 10, 2020 at 11:05 PM Rickard Green <[hidden email]> wrote:
On Sun, May 10, 2020 at 9:20 PM Guilherme Andrade <[hidden email]> 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.


--
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.

Regards,
Rickard
--
Rickard Green, Erlang/OTP, Ericsson AB
Reply | Threaded
Open this post in threaded view
|

Re: ERTS timeouts don't account for computer suspension

Guilherme Andrade


On Sun, 10 May 2020 at 23:27, Rickard Green <[hidden email]> wrote:
On Sun, May 10, 2020 at 11:05 PM Rickard Green <[hidden email]> wrote:
On Sun, May 10, 2020 at 9:20 PM Guilherme Andrade <[hidden email]> 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.


--
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