Check for ntp clock shift when scheduling next beacon.

[craigerl]

See #206 for details and logs.

According to beacon.c, if the system clock shifts forward, direwolf will emit all the pbeacons it missed during that interval all at once, until it's caught up. For example, if the internet is unavailable during boot, ntp cannot update the system time. Direwolf then starts, the internet becomes available, and ntp shifts the clock foward three hours. If direwolf is configured to send a pbeacon every 20 minutes, it will quickly send nine consecutive pbeacons (observed).

beacon.c is where the bug exists. Pbeacons should, in fact, be relative to "now" if the system clock shifted forward. If the next scheduled beacon is in the past, then set it relative to the new now. This prevents all the catchup beacons after a system time change.

On a raspberry pi with a read-only filesystem, the NTP jump can be months, effectively jamming the transmitter on for hours. (observed)

[dranch]

I haven't reviewed the patch but is it the intent of this code to DROP all "outstanding" beacons to catch up to the new time? I believe this is the only correct way to deal with these "unsent" beacons: DROP THEM. Please also note that there should be no specific linkage to NTP as many Direwolf installations are not connected to the Internet or using things like ntpd, chrony, etc. Whatever solution is proposed should only look at the Linux system time.

[craigerl]

Yes, all your assumptions and assertions are 100% correct.

Currently if direwolf starts before ntp updates the system clock, we get a transmitter jammed on scenario.

Bug #206 provides details. The patch is only a couple lines.

[hessu]

I would recommend using monotonic time instead of wall-clock time for scheduling beacons and other similar timers which do not need to be tied to wall-clock time. Monotonic time, available on all modern systems, does not jump when NTP does its thing.

clock_gettime(CLOCK_MONOTONIC) according to IEEE Std 1003.1b-1993, works great on MacOS and Linux at least.

[craigerl]

Could anyone possibly merge this pull request? This is a rather serious issue jamming a transmitter on, when using a Raspberry Pi that gets time from a lagging GPS or NTP server. This is a common scenario.

[Tyler-2]

I just ran into this problem when I hooked up my isolated RPi to a laptop for troubleshooting - suddenly it was hammering APRS and I didn't initially know why. Ah yes, it suddenly had access to a time source...

This seems like an important change.

[wb2osz]

Which branch did you use?
I thought a quick fix was in the "dev" branch.
The proper fix, of using monotonic time, for elapsed time measurements, is in progress.

[Tyler-2]

Which branch did you use? I thought a quick fix was in the "dev" branch. The proper fix, of using monotonic time, for elapsed time measurements, is in progress.

It was my RPi digi that doesn't have regular internet, so it might e a little out of date... typically runs the Debian testing package though.

[sq2mo]

Seems to be already implemented in dev:
26727bb