David Woolley schrieb am Dienstag, 18. Mai 2021 um 13:58:46 UTC+2: > On 18/05/2021 12:39, Andreas Schick wrote: > > I could safely remove the LCL entries and the server line where it lists > > own IPv4 address of the ARM box > I think it is more accurate to say that you CANNOT safely keep these! > The self reference is plain wrong.
@David:Wooley: Thank you for confirming that. I was 'forced/asked' to set it up this way by one of my former colleagues, who is frankly speaking not really familiar with ntpd functionality. People here sadly (my employer) tend to assume stuff without exactly knowing the technical backgrounds. I think this idea initially came up because we are also using several of these ARM machines on one network and all of them are running ntpd and people used to always put all of them into server lines assuming they will get some strange sort of pooling redundancy or something. I still doubt it is the right way in that scenario and I'd rather prefer one server that is reasonably safe provided it is synced to some sort of outside world and has at least a battery buffered LCL. Regarding w32time I know it is not the solution anyone using ntp mechanisms would prefer (me included), but at least it gives me some means of time syncronisation as the network is missing a real ntp timeserver (eiteher a dedicated device or a reliable linux server machine running 24/7). The windows workstation is actually a server machine running 24/7 and it is connected to the internet via a router and a secondary NIC. Sadly I had the mentioned router already failing or dropping the internet connection and that lead to the windows machine dropping to stratum 16 and then clients have to say goodbye to synchronisation. But this risk I currently have to take. If I could I'd replace that windows host by some dedicated time server (e.g. the meinberg lantime series). But at the moment unfortunately I can not do that. Another question I have is: does adding iburst to the server entry improve startup behavior of ntpd, as far as I saw it does not make much difference in my scenario, as I only have one accessible server on my network. And as per the documents I read so far it just makes the server send out several requests in a shorter time period. I do not think it will improve the situation I am having in regards to startup, as it already seems to work fine now without it. One further idea I had was just modifying some startup scripts (which run before ntpd process is started and after the network is up) to include some from of a ntpd-run-sync-and-quit or ntpdate call that steps the clock at system startup on the ARM device. I have to avoid stepping the system time during normal system runtime as timers in some software can misbehave if a leap in time is detected. But at the moment startup behavior seems fine after boot and the time just is not in sync after a couple of hours days of the system running. Thank you for helping anyway. _______________________________________________ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
