[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Antw: syncrepl error (53) with 3-way delta-mmr (consumer state is newer than provider)
Hi Ulrich
Thank you for your response.
On 08/31/2017 09:37 AM, Ulrich Windl wrote:
> Hi!
>
> Some of the time ntpd needs to sync may be host name resolution (if you use
> names). Methods to speed up initial synchronization inlude "iburst", "minpoll"
> and adding a large crowd of servers. Note that reducing minpoll could reduce
> the final accuracy (just as increasing "maxpoll" does). Depending on your
> network and load I would not rely on a time offset less than a few ten
> milliseconds. How well LDAP can operate then is a different question.
We have 2 timeservers (stratum 1) in our local net with gps clock source:
server time1.phys.ethz.ch minpoll 4 maxpoll 10 iburst
server time2.phys.ethz.ch minpoll 4 maxpoll 10 iburst
minpoll is already set at its lowest value, although I do not understand
what this option does. I may increase its value, increasing accuracy sounds
good.
# ntptrace
localhost: stratum 2, offset 0.000008, synch distance 0.031825
time1.ethz.ch: stratum 1, offset -0.000001, synch distance 0.000298,
refid 'PPS'
# ntpq -c pe
remote refid st t when poll reach delay offset
jitter
==============================================================================
LOCAL(0) .LOCL. 5 l 149m 64 0 0.000 0.000
0.000
*time1.ethz.ch .PPS. 1 u 251 256 377 0.426 0.009
0.026
+time2.ethz.ch .PPS. 1 u 64 256 377 0.430 -0.003
0.019
Looks like the time offset is only a few microseconds once ntp is in sync.
> Also note for Linux (on most platforms) and NTP one problem is that the
> frequency correction needed for the clock can vary significantly between boots;
> thus the tijme for "perfect sync" can be quite long. See attached image for an
> example.
This is very interesting, we will look further into this.
I am thinking about waiting in the startup process until ntp is in
"perfect sync"and start slapd after that. Maybe I can use the loopstats
file to check/automate this.
> Updating one entry on different servers within a very short time (shorter than
> the time of syncing) will probably cause trouble. What real-life situation
> causes such?
Probably none. But we have a logparser, which writes "last use" statistics
of our users to ldap, this is done in "realtime". We also use openldap as
kerberos KDC database backend, which writes on successful/failed
authentication attempts. The chance is probably very low if the time offset
is lower than the network delay.
> Regards,
> Ulrich
Kind regards
--
Sven