> Le 12 déc. 2017 à 23:17, Mike Cook a écrit :
>
>>
>> (servers #4 ff. are assigned from pool.ntp.org)
>>
>> But, even then, from "eyeballing" the system clock it appears correct within
>> at least 1 s,
>
> Odd as well. Is it possible that there is another process
> Le 12 déc. 2017 à 17:31, Stephan E. a écrit :
>
>
> During that waiting period, I get a status of e.g.
>
># ./ntpq -c peers
> remote refid st t when poll reach delay offset
> jitter
>
>
On 12/12/2017 04:00 AM, Harlan Stenn wrote:
"Stephan E." writes:
I want ntpd 4.2.8p10 to sync to public servers, then serve time to a
local network. It is running with '-g' because initial system time on
the host can be far off. I observe that, when initial system time of
the host was set > 5
On 2017-12-12, romain.cordonn...@gmail.com wrote:
> Hi
>
> Many thanks for your information.
>
> My project is processing meteorological data.
>
> I will check the fake ntp server python code.
>
> Restarting the ntpd is enough to synchronize with upper source ? even
Stephan E. wrote:
> I want ntpd 4.2.8p10 to sync to public servers, then serve time to a
> local network. It is running with '-g' because initial system time on
> the host can be far off. I observe that, when initial system time of the
> host was set > 5 minutes into the future, the time it will
> Le 11 déc. 2017 à 12:49, Stephan E. a écrit :
>
> I want ntpd 4.2.8p10 to sync to public servers, then serve time to a local
> network. It is running with '-g' because initial system time on the host can
> be far off. I observe that, when initial system time of the