Chrony, PTP, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd)
-
For anyone who “love to play with TIME-server”:
Do You use ntpperf utility to test Your server?
Write back Your appliances and a result in numbers!
Thx!
-
And again one time: when Netgate implementing modern time-protocols???!
-
@Sergei_Shablovsky said in Chrony, PTP, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
And again one time: when Netgate implementing modern time-protocols???!
NTP is a modern time protocol. The version in pfSense is ntpd 4.2.8, which implements NTP version 4 and is the current version of the standard.
Is ntpd my favorite NTP implementation? No, it isn't. I would strongly prefer Chrony or even NTPsec, but ntpd is certainly adequate for what is needed.
Unfortunately, Chrony is not considered viable due to license incompatibilities. This has been discussed previously. It's a shame really, because Chrony really is very good in all aspects.
NTPsec is viable on a license basis and is in FreeBSD ports. However, to replace ntpd with NTPsec (or Chrony for that matter), you would also require gpsd as well. Moving to NTPsec and gpsd would require significant effort to integrate and then test. If someone wants to put that effort in, I'm sure that the devs would consider a PR if submitted.
PTP would be a complete waste of time for pfSense.
-
@dennypage said in Chrony, PTP, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
@Sergei_Shablovsky said in Chrony, PTP, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
And again one time: when Netgate implementing modern time-protocols???!
NTP is a modern time protocol. The version in pfSense is ntpd 4.2.8, which implements NTP version 4 and is the current version of the standard.
Is ntpd my favorite NTP implementation? No, it isn't. I would strongly prefer Chrony or even NTPsec, but ntpd is certainly adequate for what is needed.
Unfortunately, Chrony is not considered viable due to license incompatibilities. This has been discussed previously. It's a shame really, because Chrony really is very good in all aspects.
NTPsec is viable on a license basis and is in FreeBSD ports. However, to replace ntpd with NTPsec (or Chrony for that matter), you would also require gpsd as well. Moving to NTPsec and gpsd would require significant effort to integrate and then test. If someone wants to put that effort in, I'm sure that the devs would consider a PR if submitted.
PTP would be a complete waste of time for pfSense.
Ummm what?! License incompatibilities? So all GPLv2 packages are having their license broken by being already present in pfSense? Doesn't make sense to me. Not to mention chrony is already available in FreeBSD.
-
@e-1-1 said in Chrony, PTP, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
Ummm what?! License incompatibilities? So all GPLv2 packages are having their license broken by being already present in pfSense? Doesn't make sense to me. Not to mention chrony is already available in FreeBSD.
I believe that Chrony is in FreeBSD ports rather than in FreeBSD release (core).
This was a hotly debated topic 10 years ago. The BSD and pfSense folk took the position that GPL components cannot be safely included in a distribution that is issued under the FreeBSD license. Ditto for the Linux folk when looking at ZFS and CDDL. You may or may not agree with their conclusions, but it is theirs to make. Who knows? Maybe you can get them to change their minds. Give it a go.
I've done a bit of work with Chrony on Linux. Some time back I considered making Chrony available as an add-on replacement package for pfSense, but the barriers to entry were large. And I was only looking at chronyd--I wasn't thinking of including gpsd with its associated headaches.
https://forum.netgate.com/topic/106105/chrony
FWIW, ntimed is truly dead at this point.
-
I use Chrony on my Proxmox host as the local time reference with pfsense accessing that only as a client.
I agree it would be much better if pfsense ran chrony as it could then be used as the server for local devices.
Sad to hear licensing issues prevent this. -
@Patch said in Chrony, PTP, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
if pfsense ran chrony as it could then be used as the server for local devices.
huh? Why can ntp that running on pfsense not be used for clients? chrony can query just normal ntp server.. If you want to use chrony on them. Chrony would be pretty useless if it couldn't query your standard ntp server
-
@johnpoz said in Chrony, PTP, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
Why can ntp that running on pfsense not be used for clients?
In can but it is an inferior time server.
Chrony is a better time server so I use it. -
@Patch said in Chrony, PTP, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
In can but it is an inferior time server.
ok ;) the standard ntpd keeps pretty accurate time.. I run ntpsec on my ntp server.. Just because I was playing with it one day and set it up on my little gps pi ntp server I run.. few ms is more than accurate enough for me..
Maybe I will look to switching my little pi guy to using chrony ;)
-
@Patch said in Chrony, PTP, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
Chrony is a better time server so I use it.
In what way? It can have accuracy comparable to PTP, but only if your source is that accurate. This means you'd need your own stratum 0 source, such as GPS or the cell phone network. IIRC, GPS is supposed to be accurate within 30 nS and the cell network within 1.5 uS. If you're using a source on the Internet, it won't get you much. If you do have your own stratum 0, you might also want to get one of those Facebook atomic clock cards to use with it.
I do understand it has some advantages for devices that are not always connected to the Internet.
PTP is designed for networks where extremely precise timing is necessary, including with SyncE, but other than that, it would be hard to justify worrying about it.
-
Yes, chronyd is a much better time keeper than ntpd. ~1us vs a few tens of us against a local stratum 1. But still, a few 10s of us is pretty damn good. But that kind of precision isn't that important for a firewall.
-
@dennypage yeah was just reading some of the difference between chrony and ntp.. While it does seem like good stuff, Im with you a few ms here or there makes little matter to be honest.. But I think I have added something new to look at when I find some time - switching my little pi ntp server over to chrony ;)
-
@johnpoz said in Chrony, PTP, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
switching my little pi ntp server over to chrony ;)
Don't forget to add a GPS receiver and Facebook atomic clock card!
I first came across precision clocks about 35 years ago, when I worked for a telecom. Back then, the networks used Time Division Multiplexing and everything had to be precisely synced. We used the LORAN C signal as our clock source. However, that was a signal clock only and not time of day.
-
@JKnott my pi ntp server has gps already.
-
@e-1-1 said in Chrony, PTP, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
Doesn't make sense to me. Not to mention chrony is already available in FreeBSD.
Because of this I’m asking again and again about Chrony implementation in pfSense.
I really think that so famous and rich company like Netgear have a budget for this.
-
Need to note that local RS-232 directly (not through RS-232<~>USB adapter) connected GPS receiver with PPS signals OR GSM receiver with PPS signal -> are Stratum 1.
Stratum 0 - this is for local-connected atomic clock. Yeah, some hi-education Institutes, financial and militarily of course in US already have it. ;)
-
@JKnott said in Chrony, PTP, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
@Patch said in Chrony, PTP, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
Chrony is a better time server so I use it.
In what way? It can have accuracy comparable to PTP, but only if your source is that accurate. This means you'd need your own stratum 0 source, such as GPS or the cell phone network. IIRC, GPS is supposed to be accurate within 30 nS and the cell network within 1.5 uS. If you're using a source on the Internet, it won't get you much. If you do have your own stratum 0, you might also want to get one of those Facebook atomic clock cards to use with it.
Thank You for very interesting link. I hear about but now see the real results, need to dive in …:)
I do understand it has some advantages for devices that are not always connected to the Internet.
No, this would be more for systems that may suffer from GPS spiffing and jamming (war in Ukraine, war in Israel and possible next escalation between China and US, EU and russia, South and North Koreas - all this rapidly involves civil GSM technologies right now …).
PTP is designed for networks where extremely precise timing is necessary, including with SyncE, but other than that, it would be hard to justify worrying about it.
If I understand all “time card” docs and specifications, bulky and proprietary rack time-servers would be replaced by tiny 1CPU server with 2xPSU and this “time card” (and a little bit antennas from server room to rooftop;)
BTW, I cannot read anything about how to resolving radio interference on antennas in server room… Looks like developers are focused more on electronics and less on radio/antennas-related things. Am I wrong?
-
@dennypage said in Chrony, PTP, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
Yes, chronyd is a much better time keeper than ntpd. ~1us vs a few tens of us against a local stratum 1. But still, a few 10s of us is pretty damn good. But that kind of precision isn't that important for a firewall.
Hm… Are You sure that chrony are enough for speeds 10G+ per interface? :)
-
@Sergei_Shablovsky said in Chrony, PTP, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
Need to note that local RS-232 directly (not through RS-232<~>USB adapter) connected GPS receiver with PPS signals OR GSM receiver with PPS signal -> are Stratum 1.
I have wondered about this. While the instantaneous time could be off with USB, NTP averages in the long term. How much is the clock in error after it's been running for a while?
Stratum 0 - this is for local-connected atomic clock. Yeah, some hi-education Institutes, financial and militarily of course in US already have it. ;)
The source, such as GPS, is stratum 0 and the first NTP server is stratum 1. The atomic clock provides stability to the local time.
BTW, one thing some people don't seem to understand is NTP is supposed to be traceable to International Atomic Time. A few years ago, I was working on a project for a light rail transit system in Toronto. The spec called for the NTP servers to be connected to the parent company's NTP server, falling back to the GPS receivers should that connection fail. Whoever wrote that clearly had no idea how NTP worked. They should have said to peer or at least be a client of the parent NTP servers, in addition to GPS. Since both the local and parent NTP servers were traceable back to IAT, there should be no significant difference between them.
Here's an interesting read about time:
From Sundials To Atomic Clocks -
@Sergei_Shablovsky said in Chrony, PTP, Network Time Security (NTS, NTPsec) to replace unsecure/old NTP (ntpd):
If I understand all “time card” docs and specifications, bulky and proprietary rack time-servers would be replaced by tiny 1CPU server with 2xPSU and this “time card” (and a little bit antennas from server room to rooftop;)
BTW, I cannot read anything about how to resolving radio interference on antennas in server room… Looks like developers are focused more on electronics and less on radio/antennas-related things. Am I wrong?
I'm not sure what you're getting at, but if that's a concern just put the receiver someplace other than the server room. In fact, GPS might not work at all in a server room simply because the signal is blocked by reinforced concrete.
I had an example of this when I worked at IBM. My office was in the Canadian HQ and the building held about 5000 employees. You could get FM radio reception near the windows, but not if you were well away from them.