giuseppe@marullo.it said: > just wondering if a PI4 could be a suitable NTP server for a small lab (and > maybe with some other NTP servers for my company, about 2000 clients). > Main use is for correct timestamp on logs/computer time sync. It should work fine. This is the time nuts list. You have to decide how much time you want to spend tuning, tweaking, and understanding NTP quirks. It's a bottomless pit. ------- > 0.europe.ntp.or .POOL. ... I think you have a typo in there. 0.europe.ntp.org doesn't exist. Try 0.europe.pool.ntp.org But it looks like you are getting enough servers via it.pool so you probably don't even need those lines. ------ tvb is trying to avoid this list turning into an NTP support list. > version="ntpd 4.2.8p12@1.3728-o (1)", That's the classic Mills code. Their support lists are broken. I suggest switching to NTPsec. Debian has a ntpsec package. Their lists are working. (Of course, as I type this, the server is down. :) https://lists.ntpsec.org/ Disclaimer: I work on the NTPsec software. ------- > BTW I don't know why reftime and clock time differs so much, and I don't know > why the difference vary, from some seconds to several seconds if check even > within a short time span. I'd have to check the code. I think reftime is the time it last tweaked the system clock. I can't read Italian. I usually set things up with separate slots for the NMEA device and the PPS device, just so I can get more information. -- These are my opinions. I hate spam.

Hi Hal, Thanks for your answer. >This is the time nuts list. You have to decide how much time you want to spend tuning, tweaking, and understanding NTP quirks. It's a bottomless pit. I have a couple of GPSDOs, but my time nuttery is pretty limited, just wondering if this is doable. I see that NTP is a whole universe in itself, adding the "unusual" raspberry serial port (NMEA sentences on one serial port BUT CD not available for PPS signal) to the mix would take even more time to master. My reasoning is that if Microsoft says 1ms accuracy is possible: https://docs.microsoft.com/en-us/windows-server/networking/windows-time-serv ice/configuring-systems-for-high-accuracy I could/should have less than 1ms at the Stratum-1. Ntpstat command says 2ms then something is wrong: 1) I am off by about 2ms 2) ntpstat does not report accuracy reliably 3) both >> 0.europe.ntp.or .POOL. ... >I think you have a typo in there. 0.europe.ntp.org doesn't exist. Try 0.europe.pool.ntp.org Thanks and corrected, I also removed the server references, just pools. Rebooted and waiting if this would improve anything. So far, no improvement. >> version="ntpd 4.2.8p12@1.3728-o (1)", >That's the classic Mills code. Their support lists are broken. >I suggest switching to NTPsec. Debian has a ntpsec package. Their lists are working. (Of course, as I type this, the server is down. :) > https://lists.ntpsec.org/ > >Disclaimer: I work on the NTPsec software. I appreciate the info but I would not start again from scratch with NTPsec, this is the first setup that somewhat works and do use PPS signal. There are a lot of tutorials for doing the NTP Server+Rspberry recipe, but either they are obsolete or inaccurate at best. The one I found allowed me to skip GPSD at all, I was not able to make gpsd work with my board. Nevertheless I could give it a shot, like using this tutorial: https://www.ntpsec.org/white-papers/stratum-1-microserver-howto/#_clockmaker Do you have any better one to use? ------- >> BTW I don't know why reftime and clock time differs so much, and I >> don't know why the difference vary, from some seconds to several >> seconds if check even within a short time span. >I'd have to check the code. I think reftime is the time it last tweaked the system clock. You do seem right. Difference is never more than 8 seconds, the time I configured as polling interval. >I can't read Italian. > I usually set things up with separate slots for the NMEA device and the PPS device, just so I can get more information. Don't worry, main thing is that is not using gpsd, everything else is pretty standard. I got the serial port reversed (prolly because I switched the SD from a pi-zero to the PI4), other than this it worked.