Discussion: ntpd on a node

[aanon4]

(re: #221)

Rather than opening a PR with a possible solution, I thought I'd highlight some options for discussion first as there are several:

1. By default, no ntp on a node. Given that running ntp at all takes resources, perhaps we just shouldn't run it at all on nodes by default. After all, day-to-day, most nodes don't need the time set particularly.

2. Run ntp on startup. This is what we currently have. Ntpd runs on boot to set the initial time on the node and then assume the node will keep good-enough time afterwards.

3. Run ntp periodically. A slightly improved version of (2) given that, actually, nodes probably don't keep great time over long periods. Perhaps reset the time every day.

4. Run ntp. Here we run ntpd all the time, so a node will keep accurate time over long periods.

Orthogonal to the above is how a node chooses the time server to sync with. Currently we have a default set one on the main page which may, or may not, be reachable. It can be changed, although I have no idea how many people do that. An alternative to that is for a node to search out NTP server on the local mesh and use those for their time sync. Auto-configuration is nice, but it's not something we do anywhere else on the node at the moment. Also, it's a bit of a heuristic process as there's no well defined way to advertise ntp servers on the mesh (for now, it's basically looking for "ntp" in service names and then seeing if they're really ntp servers).

Thoughts?

[K6AH]

I think I'm landing on #3 using the default NTP server in the config, and on failure search via auto config as described. I think so long as we have a report such as the SNR Chart, we should be accurate on the time axis. Perhaps randomize when it gets the time from the mesh so they all don't do so at the same time. The trade off of course is memory, and you don't say how much space this will consume, but I can't image it's much.

[aanon4]

@K6AH A running ntpd server uses about 1M (at least that's the footprint I see on my AR750)

[ab7pa]

The legacy ntpclient uses about the same amount of memory as ntpd (932kb).

[wu2s]

I prefer #3. Just run periodically - my preference is about 4 times daily. That should be more than enough to keep reasonably in sync with correct time.

[K6AH]

Wow, that seams like a lot memory. So, between adding the tunnel and ntp features we've consumed all we saved by removing perl? Is there a smaller ntp client we could use?

[aanon4]

So for clarification, there's no change in the use of flash as ntpd (busybox) is already loaded onto the node. As for RAM, ntpclient and ntp use similar memory, and ntpclient is already running (and tends to hang around for some reason) using up RAM all the time. Option 3 would at least only use that RAM every few hours for a few moments; so all in all it would be a resource win.

[K6AH]

Then it's a no-brainer for me.... #3.

[ae6xe]

If the only dependency on a node knowing the time is meshchat, then we could consider making it an optional package like meshchat? Although I suspect a lot of admins like the node's time to be current regardless.

[ae6xe]

Busybox probably has an option to compile without ntp, to use a stand alone package.

[aanon4]

"I suspect a lot of admins like the node's time to be current" - this is really the question for me. Personally the moment I'm trying to debug something on a node is not the moment I like to discovery I can't trust the time on any file or in the log files. But I don't know if this is the usual case for most users.

[ab7pa]

My vote... try to keep the node clock reasonably accurate, if for nothing else then for ease of reading log files and logd. If there is a reachable time server, then at least update the clock upon reboot and once a day afterward if possible. If there is not a reachable time server then don't start ntpd, but maybe once a day try to check if a time server has become available and start it then.

[dman776]

What? There’s no way. Thanks, Darryl

…

On Mar 24, 2022, at 2:19 PM, Andre Hansen ***@***.***> wrote:  Wow, that seams like a lot memory. So, between adding the tunnel and ntp features we've consumed all we saved by removing perl? — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were assigned.

[dman776]

Agree with Steve Thanks, Darryl

…

On Mar 24, 2022, at 4:55 PM, Steve AB7PA ***@***.***> wrote:  My vote... try to keep the node clock reasonably accurate, if for nothing else then for ease of reading log files and logd. If there is a reachable time server, then at least update the clock upon reboot and once a day afterward if possible. If there is not a reachable time server then don't start ntpd, but maybe once a day try to check if a time server has become available and start it then. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were assigned.

[aanon4]

So I think this is the plan:
On boot and every 24 hours, sync the clock with an available time server, the one specific in the config or one found on the network. Don't run NTP otherwise.

[wck86]

At recent emergency preparedness fair in OC a small mesh was set up, with no access to the internet. Cameras were connected and the timestamps were off by about a day and a half. For smaller mesh networks, not having Internet access risks potentially substantial timing issues. After that experience, I put a stratum 1 NTP server onto a Raspberry Pi Zero W and it looks like it works pretty well.

The Pi Zero W is a bad platform for this for a few reasons- including, imo, only having 2ghz WiFi and no Ethernet port, but it works well enough in my kit for now.

Having something like this for smaller mesh networks could be pretty important. I understand the higher end Ubiquiti Rockets have GPS- could an optional package be made to utilize that for timing?

[k6ccc]

FYI, I put this NTP server on my network at my house a couple months ago and have all of my nodes using it for time sync. Working very well and not all that much money. https://centerclick.com/ntp/
I have the NTP200 model. It is reachable on the SoCal network at 10.9.60.82

[wck86]

That looks like a nice unit. A good NTP server can be made for about 35 dollars using pi zero

…

On Thu, May 12, 2022, 9:43 AM Jim Walls ***@***.***> wrote: FYI, I put this NTP server on my network at my house a couple months ago and have all of my nodes using it for time sync. Working very well and not all that much money. https://centerclick.com/ntp/ I have the NTP200 model. It is reachable on the SoCal network at 10.9.60.82 — Reply to this email directly, view it on GitHub <#318 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABQVPT2ZJILPSI75ZILJYT3VJUYJ3ANCNFSM5RRWYDSQ> . You are receiving this because you commented.Message ID: ***@***.***>

[wu2s]

Also agree

…

On Mar 24, 2022, at 18:48, Tim Wilkinson ***@***.***> wrote: So I think this is the plan: On boot and every 24 hours, sync the clock with an available time server, the one specific in the config or one found on the network. Don't run NTP otherwise. — Reply to this email directly, view it on GitHub <#318 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AIODNVSWUWB5K4TPYRLHVQLVBT5LJANCNFSM5RRWYDSQ>. You are receiving this because you were assigned.

[k6ccc]

Good luck at getting a Pi zero for $35. Double that (or more). Then add the GPS module, Then get it all talking. Nice if what you want is a project. I wanted a box that I could power up and plug into my network and it would just work. I do like my CenterClick NTP...