Tag Info

New answers tagged

0

Your situation is unusual, and I'd be surprised if anyone comes up with a standard ntpd-based configuration to do what you want. That said, I like being surprised, and it happens quite often around these parts. But until someone comes up with a better idea, have you considered a crontab entry like */5 * * * * ntpdate 0.pool.ntp.org || hwclock --hctosys ...


-1

There are known issues with the local clock, that don't apply to the RTC. You may be able to use the Dump clock driver (33) with a program that writes the appropriate RTC time to the /dev/dumbclockX device. There are a number of other drivers based on Radio clocks. Someone has written an RTC driver as well, but it does not appear to be incorporated.


0

Remove the iburst from the reference clock entry. You could also make the following changes to the server entries: Change: server 0.ubuntu.pool.ntp.org server 1.ubuntu.pool.ntp.org server 2.ubuntu.pool.ntp.org server 3.ubuntu.pool.ntp.org To: pool 0.ubuntu.pool.ntp.org iburst pool 1.ubuntu.pool.ntp.org iburst pool 2.ubuntu.pool.ntp.org iburst ...


1

I use the following: KERNEL=="ttyS0", RUN+="/bin/setserial /dev/ttyS0 low_latency" KERNEL=="ttyS0", SYMLINK+="gps0", RUN+="/usr/sbin/ldattach pps /dev/ttyS0" KERNEL=="pps0", OWNER="root", GROUP="dialout", MODE="0660", SYMLINK+="gpspps0" Did you test your udev rule with udevadm:? # udevadm test /sys/class/tty/ttyS0 Update Your setserial ...


1

Don't use a manual peer list if you're syncing from the domain hierarchy. Sync your PDCe from an external time source - not the Hyper-V host. Disable Hyper-V host time sync for your virtual DCs.


1

From TechNet: The Windows Time source authenticates with a time source client. In an Active Directory forest, the Windows Time service (W32time) relies on standard domain security features to enforce the authentication of time data. The security of Network Time Protocol (NTP) packets that are sent between a domain member and a local domain ...


1

If you want an NTP server to do anything reliably, you need not to lie to it about the reliability of its own clock; the lines server 127.127.1.0 and fudge 127.127.1.0 stratum 10 do exactly that, and it looks like getting rid of them has fixed things. As for stopping ntpd before brute-forcing the time with ntpdate, my understanding is that there's a ...


1

It sounds like your clock is off by more than the panic threshold. However this does not explain why multiple ntpdate invocations would fix things. To be honest I can not think of any error that would be overcome by multiple ntpdate invocations. Regardless ntpdate has been deprecated. I think that the most likely explanation is that your clock exceeds the ...


1

On RHEL / CentOS 6 and 7, for whatever reason ntpq tries to query the IPv6 loopback at ::1 instead of the IPv4 loopback at 127.0.0.1. With this in mind, I added this line to my /etc/ntp.conf file: restrict ::1 Saved the file then restarted ntpd (service ntpd restart) and now the command: ntpq -p works as expected. (This is the same as running ntpq in ...


0

The commands ntpstat and ntpq -p off-hand (from mobile so without sample output for now)



Top 50 recent answers are included