[ntp:questions] Client using Meinberg NTP can't sync with ntp server problem

William Unruh unruh at invalid.ca
Sat Jul 12 16:43:35 UTC 2014


On 2014-07-12, Brian Inglis <Brian.Inglis at SystematicSw.ab.ca> wrote:
> On 2014-07-11 00:51, vothanhhung22 at gmail.com wrote:
>> Hi all,
>>
>> I read and followed as the link Martin suggest and I tried to
>> find the latest version. Can you check for me if this link is
>> the latest because I tried this link but it is not working.
>> I tried set minpool to 9 but it doesn't work.
>                minpoll
> pool hk.pool.ntp.org iburst minpoll 6 maxpoll 6
> pool tw.pool.ntp.org iburst minpoll 6 maxpoll 6
>
>> Here is the link: http://www.satsignal.eu/ntp/x86/ntp-4.2.7p447-win-x86-bin-djt.zip
>>
>> In my case (as  William explained) it is not a normal clock rate
>> sync but just a copy time from ntp server to machine clock.
>> So what I am wondering now is if it is right in my situation to
>>use ntp to "sync" from ntp server.
>>
>> The machine I am trying to "sync" is a VPS machine.
>
> Search for "ntp under Xen OR KVM" or substitute your platform.
> You have to find out what your platform is, whether your
> provider syncs the domain and host time with NTP, what service
> level and timing facilities are provided.
>
> If the domain and host time is not synced with NTP, as is
> common in Windows domains, you probably have no chance, as
> the platform time may appear to jump and/or drift any old
> way, and NTP requires a stable hardware base to work from.
>
>> I still don't get the point William explained that "you cannot
>> "force it to sync every 10 min" that is not how it works".
>> Can you explain me more?

ntpd operates, as I said, in a certain way. It sends out a request for
time at the poll intervals. It then looks at the last 8 times and if the
current round trip time is greater than any in the last 8 times, the
current one is not used and the next poll is waited for. Thus, the used
measurements vary between poll interval and 8 times poll interval time
between them. 
Then that measurement is compared with the local clock. If it shows that
the local clock is slow, the local clocks tick rate is increased by a
small amount-- proportional to that offset and inversely proportional to
the poll interval, but much less than would be required to fix the
offset within even 8 poll intervals. And the process continues.
Eventually, the local clock's rate is increased enough that the offset
starts to decrease and finally the time offset is also decreased. 
Ie, the local clock is NOT reset, is not synced except over a long time. 
Its rate is gradually changed. After the local rate equals the distant
rate, and the local offset is small, the local clock tracks slow drifts
either in its own rate or the remote rate. 
ntp does terribly if the local, or remote rate change suddenly. It takes
a long time (about 8 poll intervals) to even notice, and then much
longer to bring the rates into line again. Mills designed the system
with stability, not speed of response, in mind. 
Whether this kind of feedback system is the best use of the measurements
made has been a long topic of discussion (extending back into the first
design of ntpd). chrony, another program which uses the ntp packet
exchange protocol for time discipline, and interoperates on the packet
level with ntpd, uses a different philosophy, and is much faster at
responding to changes, and has been found to discipline the clock much
more accurately (3-20 better in offset jitter in a variety of tests).
Whether it has drawbacks to compensate is a topic ripe for testing.
However for you its biggest drawback is that it does not run under
Windows or MacOS (although the latter should not be a difficult port
since macOS is based on BSD/Unix. )


>
> NTPd whe  started with -g steps your system within 128ms of UTC
> then disciplines the rate at which the system sees time passing
> to get the offset closer to UTC.
> It decides how often it needs to request information and make
> corrections depending on how it sees your platform behaving.
>
> How close you get to UTC depends on the stability of your OS,
> hardware, and time sources, so may be ms with network sources
> or Windows, us with hardware reference clocks (e.g. GPS with PPS),
> or ns with BSD on embedded systems (e.g. Soekris) with time nut
> level hardware (e.g. Trimble Thunderbolt) and external antennas
> (e.g. survey quality) with a good view of the sky (no trees or
> buildings nearby and above the level of the antenna). YMMV

Well, no, with just a bog standard level gps (eg the $35 Sure out a
window with trees in the way)  and standard serial port interupt, 
I get a few usec level jitter, and using it as a network source for
other machines, I get 10s of usec errors (measured with separate gps pps
attached as the standard) over the local network. Even over an ADSL line
from home, I was getting better than 100 usec on the home machine. 
So, yes, YMMV.

>



More information about the questions mailing list