cron ticks are slightly less than ideal

[nwf]

• cron_handle_tmr resets os_timer_arm every call to tick on the next minute boundary. It might be better to keep the list of scheduled entities sorted by next firing time and set the timer to fire when the leading queue entry would fire (and to re-arm it when a schedule changes or an entry is created). Or perhaps we don't even need a list, and every entry could have its own backing timer.

• The cron module is not informed of rtctime changes, and so will be in for a surprise if sntp has stepped the clock since cron armed its timer. As a result, entry firing my be delayed arbitrarily (and, in fact, entries may never fire). In an ideal world, entries would probably degrade to rate-monotone firing even if the clock is jumping around (that is, firing with a period at most one minute larger than their scheduled interval, as they would compute the elapsed time until next firing upon each firing), while a stable clock would synchronize phase and frequency of schedules with the wall clock, and a periodically stepped clock would take on some middle behavior between those two extremes,

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.