1 system to do it all?

It’s generally recommened that in a typical time server setup, that 3 time sources should be used to ensure an accurate time is provided to a network. NTP/Chrony/gpsd as far as I can tell, does not (properly) support multiple GPS serial/PPS signals under one system, which would mean for a “proper” setup, one would need 3 seperate physical systems. But what if all 3 systems could be combined into 1 using virtual machines?

I know the topic of using NTP/Chrony in a virtual machine has come up here and there, and the general consesus seems to be that in a modern system it should be ok to serve time from a VM with either daemon, (though bare metal would be ideal). However, setting up a single system with multiple virtual machines, each with thier own GPS/PPS setup, one could have 3 independant time sources under one machine. Sure, redundancy goes out the window if the host machine goes down, but you wouldn’t need to run 3 seperate physical systems for a proper time server setup.

Before I go down this road and experiment with such a setup, has anyone tried this before?

Why do you need/want multiple instances of gpsd? gpsd receives time from multiple satellites, there’s no need to run more than one gpsd on a server.

I personally think Raspberry Pis and BeagleBones are cheap enough that having 3 independent servers, each with their own GPS receiver, is viable. It means you can put them at different locations with different views of the sky, and thus get better overall coverage.

Which is what’s recommended for a proper time server setup, I understand that. But in my case, all 3 units would be installed in the same location, the only difference in sky view being how far a couple of feet of coax will reach. I’m just trying to consolidate 3 seperate units into 1, seeing as how I’m going to have normal PC hardware as one of the units because of other software/hardware needs. I could skip having to use and power 2 additional RPi’s just for time service. All I would need is a 2 port serial PCIe card and Proxmox should be able to assign each individual serial port to each VM running a time server.

Hence the question, has anyone tried such a setup, and what was your results? The good? The bad? Did it even work? Caveats? Hypervisor/OS quirks?

You keep referring to this, and to that implying that three sources would be needed, but in another place refer to three systems. I have a feeling that there may be a bit of misunderstanding here.

It is typically recommended that a single server have (at least) three sources of time, e.g., one stratum 0 (reference clock) and two (or more) lower stratum sources (other NTP servers). Some reasons for that are for the single server to have some redundancy in sources (thus more than one source, depending on requirements), and for the server to be able to derive a majority from among its sources (thus an odd number of sources). That is for a single server (or client for that matter), e.g., one contributing to the pool.

When you talk about multiple systems, then maybe that is if you want to provide time service to a certain set of clients, e.g., if operating a private network. In that case, if yours are the only sources of time (and, e.g., no external sources are available/reachable), then the recommendation for your clients to have three sources of time would translate to the need for three systems/servers to be available in your environment. How you realize that depends on your requirements. I.e., what scenarios you want to guard against, e.g., likelihood of some system becoming a falseticker, need to take systems offline every now and then for maintenance, or if you need to guard against hardware failures.

Not sure what kind of setup you have in mind, or why you think this wouldn’t work from a technical point of view. Having multiple sources of time (stratum 0 in that case) was not the driver for doing it (I have separate upstream systems both locally as well as externally for that), so not sure whether I missed something. But I have some systems running that have two or three GNSS-based reference clocks attached to them without issue, using gpsd and ntpd classic. It’s not redundant in multiple ways, e.g., some of the GNSS receivers share a common antenna. But as said, I am not after redundancy, but from gpsd/ntpd functional point of view, I don’t see an issue.

So it really depends on what you want to achieve, see above discussion on why, and how, three sources of time for clients.

E.g., if the point is to provide three GNSS-based time sources to a single NTP server, e.g., one contributing to the pool, then gpsd/ntpd/… should work. It is up to (external) clients of your server to then take care of in turn having at least two additional time sources besides yours.

If you want a different sort of time source redundancy on your end, and anyhow plan to operate three servers in some constellation, e.g., for contributing to the pool, or need to serve local clients without access to separate time sources, then you could set up three servers/systems to do so, each having one GNSS-based reference time source, and using the respective two other systems as second and third sources. Reference sources typically (in my experience) being chosen over lower stratum remote sources, the majority argument would be moot as long as the reference source is available and not totally off, but you’d at least have two backup sources for each server should one server’s reference source fail for some reason. And dependent local clients would have three local time sources. (Clients of the pool wouldn’t care as they’d anyway pick redundant sources from the pool, or from elsewhere, as per client operator responsability.)

Purchase 3 Luckfox ARM development boards for $45 and connect them to 3 GPS for low-cost implementation without the need for virtual machines

Motorola GPS receiver + LuckFox Rockchip RV1106 armv7 + Linux + PPS

  1. Low cost $30
  2. Low power consumption 0.7W,
  3. High precision±2 microseconds

1 Like