`Process.send_after` inaccuracy - anyone know what causes it?

I have a system in a project where an end user schedules something to happen. I use Process.send_after/3 to do the actual scheduling, i hadn’t really considered the accuracy of sending a message to yourself long in the future. (in this case about 24 hours). I noticed this morning that my message was received at 9:40 AM, when it was scheduled to run at 10:05.

I know how to fix this issue pretty easily. I was just wondering if anyone has hit this before, or if anyone knows what causes the skew?

FWIW this is a Nerves app deployed to an RPI3. It has no real time clock, so the time on the device skews by about a minute before ntpd fixes it. i don’t feel as if the timer otp application uses the system time internally tho does it?

2 Likes

quite interesting since the RPI is most likely one of very few places the BEAM runs without rtc.

http://erlang.org/doc/apps/erts/time_correction.html#erlang-monotonic-time

send_after uses monotonic time, and afaik by default the BEAM runs with no time warp mode http://erlang.org/doc/apps/erts/time_correction.html#time-warp-modes

my unqualified guess would be if the time skews in “wrong” direction, monotonic time will still increase (being monotonic, after all) - and you end up with way of accuracy…

I wonder if using(and calculating) the absolute monotonic time, using the :abs option provides better accuracy, or is still prone to this inaccuracy https://hexdocs.pm/elixir/Process.html#send_after/4-options

I’ve never quite understood how (especially the more modern) RPIs lacks rtc on the board…

so maybe try and check the time warp mode used by nerves, and try and use single time warp in the vm.args…

On an embedded system it is not uncommon that the system has no power supply, not even a battery, when it is shut off. The system clock on such a system is typically way off when the system boots. If no time warp mode is used, and the Erlang runtime system is started before OS system time has been corrected, Erlang system time can be wrong for a long time, centuries or even longer.
http://erlang.org/doc/apps/erts/time_correction.html#single-time-warp-mode

2 Likes

Very interesting. I will have a read through this.