I need some help in understanging what can cause a behaviour described below:
(udp_spray@MacBook-Pro-2)270> uptime().
32 days, 17 hours, 44 minutes and 35 seconds
ok
(udp_spray@MacBook-Pro-2)271> erlang:system_info(os_monotonic_time_source).
[{function,clock_get_time},
{clock_id,'SYSTEM_CLOCK'},
{resolution,10000000},
{extended,no},
{parallel,yes},
{time,4421528901334153}]
(udp_spray@MacBook-Pro-2)272>
(udp_spray@MacBook-Pro-2)272> erlang:system_info(time_correction).
true
(udp_spray@MacBook-Pro-2)273>
(udp_spray@MacBook-Pro-2)273> f(A), f(B), A=os:system_time( second ), B=erlang:system_time( second ), A-B.
985614
(udp_spray@MacBook-Pro-2)274>
Any idea what could cause this discrepancy between values returned by os:system_time/1 and erlang:system_time/1.
When I run the above command (273) on a production server running Linux, the difference is 0.
So, my guess is that this has something to do with me running this on a laptop’s energy saving.
But then again, time_correcton flag is on, so it’s clearly something that I do not understand here.
Anyone interested in providing a comment?
If the Erlang VM has been alive while your system has been suspended, this is most likely the reason as you guessed.
By default the VM use a monotonic time source that stops during suspends. This due to performance reasons. Time sources that don’t stop during suspend were typically more expensive the last time I checked (which was quite a while ago, though). It is possible to configure the VM to use a monotonic time source that doesn’t stop on suspend when building OTP if such a time source is available on the system. This is done by passing the --enable-prefer-elapsed-monotonic-time-during-suspend command line argument to configure. Your system time source is clock_get_time() which has not been used by us for quite a while (since the posix clock_gettime() where made available on MacOS quite a while ago), so I suspect that your MacOS is quite old. Therefor I guess that there is no monotonic time source not stopping during suspend on your system.
By default the Erlang VM use no time warp mode which causes Erlang system time to stop if OS monotonic time stops. This in turn will cause Erlang system time having to slowly catch up with the OS system time when the system is resumed which can take a really long time. If you enable multi time warp mode (which will be the default as of OTP 26), Erlang system time can align with OS system time as soon as the VM detects the difference in times.
Another reason can be that the OS system time was changed while the Erlang VM was alive. When using no time warp mode this cause the same issue as the suspend.