[ntp:questions] Clock selection in Orphan Mode

unruh unruh at invalid.ca
Mon Jul 29 12:57:24 UTC 2013


On 2013-07-29, Mathieu Deltorre <deltorrem at gmail.com> wrote:
....
>
>>> Second question:
>>> My needs is to synchronize network time to the maximum time
>>>  of all PCs.
>>??? what in the world does that mean.
> I mean : In orphan mode, orphan children use a metric computed from the
> offset time of each core servers. Each orpahn child chooses the orphan
> parent as the root server with the highest metric.
>
> According to the documentation :
> http://www.eecis.udel.edu/~mills/ntp/html/clock.html Paragraph "Step and
> Stepout Thresholds"
> "In some applications the clock can never be set backward, even it
> accidentally set forward a week by some evil means"
> The previous given example do not validate this sentence.

I think you are misreading that. That is not a statement about how ntpd
works, it is a statement about some people's requirements. Ie, some
people want the clock never never ever to go backwards, even if it, for
some reason turns out to set a week into the future.

Is this your requirement?


>
> To be more precise:
> Test scenario.
>==========
> 1/ Under ordinary condition, no UTC sources are available to any core
> server, one of them (in my case : PC1 with ip x.x.x.1) can provide a
> simulated UTC source for all other hosts in the subnet. Assuming synched
> time is 10h00.
> 2/ All systems reboot
> 3/ In case of hardware failure (or operator error), init hardware clock of
> PC1 is set to 09h00 (or worst 1 Jan 1970)
> 4/ ntpd on all systems are restarted in orphan/broadcast mode in order to
> broadcast their local clock and to first synchronize all systems.
> 5/ PC1 is select as a root server. NTP time is now the time of PC1.
> 6/ Time is set backward on PC2 and PC3, resulting inconsistent data
> timestamp stored in DB for example.

Backward? I thought they were switched off and thus they have no time.  
If you mean that the system time will now be behind the times already
stamped in the database, then yes, it will be. So you would have to do
something on bootup like check all of the times in all the databases,
and set the intial time to be the latest of those. Or have the database
software put a timestamp into a file every time a database write occurs,
and have the machine read that stamped time. None of those scenarios are
ones that ntpd is set up to handle.


>
> I think I have a point. Still determine if this is an issue.
>
> I code a new metric for select an orphan parent in orphan mode based on
> offset. Should be read as a workaround to fix my issue.
> ntp version 4.2.7 p368
> in ntp_proto.c, in function clock_select, near line 2470:
>
> if (peer->stratum == sys_orphan) {
>     if(sys_offset < peer->offset ) {
>         typeorphan = peer;
>         fprintf(stderr, "clock_select select typeorphan=%p\n", typeorphan);
>         fflush(stderr);
>     }
>     continue;
> }

That will still not prevent clocks from going backwards. Say there is a
read glitch on one of your servers so that it sends out a time 25 years
in the future. Your systems will not have to use that time. That glitch
only occurs once, and it settles back to delivering the correct time,
but all the machines are now locked into that wrong time, or are forced
to go backward on the next setting.


>
> Please feel free to comment and correct anything.
>
> --
> Mathieu



More information about the questions mailing list