This post is going to get way too long anyway, so I am going to skip any discussion regarding the importance of accurate timekeeping or reasons for wanting it.

While it is nice that the nodes will update with ntp servers when they have access to an internet connection, I think it would be nice for them to be able to get a time-set without a connection to the actual Internet.

I haven't done any extensive testing or experimenting just yet and this is my first foray into NTP aside from using it on nearly all of my machines pointing to pool.ntp.org to keep time set. My admittedly limited research has given me some education into some of the terms and methods of NTP. For those who are unfamiliar with it:

- There are 16 “valid” levels of NTP (0-15) referred to as strata, NTP stratum 16 is used to refer to a device that is considered unsynchronized.

- A GPS is considered a Stratum 0 time source and can be used as a reference clock for NTP.

- A machine connected to a GPS and set to serve time to the network would be considered a Stratum 1 NTP Server. Stratum 1 servers may peer with other stratum 1 servers for sanity checking and backup. These are considered primary time servers.

- Stratum 2 are machines that are synchronized over a network to stratum 1 servers. Often a stratum 2 computer will query several stratum 1 servers. Stratum 2 computers may also peer with other stratum 2 computers to provide more stable and robust time for all devices in the peer group.

- Stratum 3-15 are the same as Stratum 2, using the level above and peering with others at the same level to get their time and acting as a server for devices in the next level down.

What I'm thinking of is a GPS connected to a computer (the Stratum 1 server) connected to the mesh. My initial thought is that this would be a great use for a Raspberry Pi, but I do not yet have one for testing and will be using another old computer I had lying around and an older GPS that I'm not currently using for some testing/proof of concept. I currently have the machine getting it's time from the GPS but have not done any testing beyond that.

In the simplest form, the configuration of a mesh node would be edited to point to this NTP server, and all would be complete; no big deal. I've even seen the configuration file on a mesh node that would need to be edited. However, this doesn't keep in the spirit of the self-configuring aspect of hsmm-mesh and also would require each node in the mesh to be configured to point to each NTP server (at least until 2-4 are active in the config file) as it is brought online. These additions to the configuration file would then be irrelevant when that server leaves the mesh.

Starting with NTPv4, the Manycast Scheme was added, and this looks promising for use in the mesh. There are also Broadcast and Multicast Schemes, but at this point and from the information I was reading I think Manycast looks most promising for our purposes here.

So my vision then is that users can have a GPS connected to a computer (I've seen tutorials for using a Raspberry Pi as a NTP server like this) and then configure it for the Manycast protocol. Get 2, 3, 4, or even more of these throughout the mesh as the Stratum 1 servers. They can automatically detect and peer with each other.

The second step would be to have the hsmm-mesh nodes look to these servers to set their own time. I'm not sure if the implementation of NTP that the firmware currently uses supports manycast or if there is some reason that ntpd is not the default, but I have notice ntpd in the available packages list and will likely be using that as I continue experimenting. Ideally, the node itself will use manycast and find the Stratum 1 servers described above and also have fallback to the pool.ntp.org servers in the event that an internet connection is available and none of the described Stratum 1 servers are. For the time-being, each node will have to be individually configured to support this implementation. Perhaps and ideally, if we get this working well, future versions of the firmware will have this as the default setup, eliminating the need to make this change on each node.

The third thing, and this might be a bit of a stretch/pipe-dream would be that once the hsmm-mesh node receives a time-set, it determines it's stratum (stratum 2 if from a stratum 1 on the mesh, stratum 3 if from stratum 2s on the mesh but no stratum 1 or whatever it would be from pool.ntp.org) and becomes an NTP server itself. Would have to make sure that it does not become a server until it receives a time-set from somewhere else though.

Extrapolate on this a bit and we see that then devices connected to the mesh (IP cameras, IP Phones, Laptops, etc) could be pointed at the mesh node they connect to for the NTP time and not need to support manycast or know the name/IP of a NTP server, and if they did support manycast they too could get the time directly from the stratum 1 server itself.

If we can get this working, it would support the philosophy that mesh nodes (and the GPS connected computers attached to them) would be able to join and leave the mesh and provide improved time-keeping while they are there without causing major disruptions when they leave. It would also allow for a level of redundancy that would scale well without requiring central administration (that might occasionally be unreachable from certain areas of the mesh)

So now that I've gotten this far, if you're not completely confused, if this seems like a reasonably feasible idea, and if I'm not completely mistaken on how things work, has someone already gotten something like this already setup? Is there anyone around interested in assisting with some collaboration and experimenting?

The lack of consistent time across the nodes of the mesh has kinda bothered me since I started reading and learning about hsmm-mesh and I am only just now starting to experiment with the mesh and learn about some of the inner workings. Please, share your thoughts, ideas, and comments regarding this and thank you for taking the time to read it.