[ntp:questions] Bug 2341 - ntpd fails to keep up with clock drift at poll>7

Brian Inglis Brian.Inglis at SystematicSw.ab.ca
Thu Nov 28 13:27:20 UTC 2013

On 2013-11-28 00:46, xiaoniao112233 at gmail.com wrote:
> 在 2013年11月28日星期四UTC+8下午3时11分23秒,Brian Inglis写道:
>> On 2013-11-27 23:15, Michael Tatarinov wrote: > 2013/11/28, Brian Inglis <Brian.Inglis at systematicsw.ab.ca>: >> Running on AMD quad with stepping disabled in BIOS and fixes for TSC. >> Tried to force TSC with HTPD_PCC=1 but ntpd switched to using HPET! >> No apparent difference before/after. > > Did you mean NTPD_PCC? also ntpd has an option options '--usepcc' under Windows. Sorry, of course I meant to type NTPD_PCC=1. I use the env vars to see if there is any change, before deciding whether it is worth adding permanently to the service params. -- Take care. Thanks, Brian Inglis
>    My time source come from GPS software getting GPS time running in  Windows Server 2008 R2;
> Windows Server 2008 R2 --NTP sync--Linux Cent OS 6.2--w32TIME Sync--Windows XP/7
> NTP Version NTP 4.2.4 P8

GPS Time is not UTC time!
Since the GPS epoch of 1980-01-06 00:00:00 UTC, GPS has ignored leapseconds,
and UTC counts leapseconds.
If the software does not account for leapseconds to date, time will be ahead by 16s.

How is the GPS time received?
Many devices that can be plugged into Linux, BSD, or Windows have NTP drivers.

NTP knows about GPS time and leapseconds to convert to UTC, as NTP distributes
UTC around the world, and may be involved in derivation of global UTC.

Many of us run NTP on our Windows systems because we have seen how Windows does time sync!

NTP can handle many GPS receiver date time stamps and PPS pulses, no matter if signals
come from US NavStar, Russian GLONASS, Chinese Compass/BeiDou, Indian Regional NSS,
EU Galileo, or any mix, as long as the time from the receiver is accurate.

Take care. Thanks, Brian Inglis

More information about the questions mailing list