Hello,
On Sat, Feb 18, 2012 at 01:50:54PM +0000, Dave Hart wrote:
> On Sat, Feb 18, 2012 at 11:55, <[email protected]> wrote:
> > Hello,
> >
> > the situation before I had a DCF77 clock: I synchronized my
> > NTP-Server against a few Stratum-0 Servers (ptbtime2.ptb.de,
> > ntp1.sda.t-online.de, ntp1.fau.de).
> > At the statistic site from the pool, I saw that my offset (in good
> > times) oscillates about 0 with +/- 10ms. That was ok for me.
>
> Were the offsets equally balanced between positive and negative?
>
They were nearly balanced.
> > I bought a DCF77 clock and connected it to my NTP-Server:
> >
> > server 127.127.8.0 mode 16 prefer
> > fudge 127.127.8.0 time1 0.251
> >
> > Now I have a problem:
> > On a second independent computer I ran NTP and let it
> > syncronize against my NTP-Server with the DCF77 clock
> > and against ptbtime2.ptb.de. I changed the "time1" to a
> > value, so that my NTP-Server and ptbtime2.ptb.de a
> > almost the same (low difference of the offset).
>
> Please tell us the time1 value that brought your clock into apparent
> alignment with this national time reference.
>
> > But the statistics of the pool now show me, that my
> > NTP-Server has an offset of 10ms +/- 2ms. If I change the
> > "time1" so that my NTP server show a good value on the
> > pool statistic site, I get a huge difference (>10ms) to
> > ptbtime2.ptb.de.
>
> Please tell us the time1 value that minimized your offset with the
> pool monitoring.
>
> > How can I calibrate my NTP-Server correctly?
>
> NTP relies on network paths being symmetric -- the same latency from A
> to B as from B to A. If the path is not symmetric, the result is an
> offset error. Often the access link is inherently asymmetric such as
> ADSL. In contrast, your DCF77 receiver suffers offset error due to
> propagation delay between the transmitter and receiver, as well as
> delay getting the signal into your computer. You cannot be sure your
> calibration is correct using only network sources, due to the
> asymmetry likely present. You may be able to come close by checking
> against different remote sources as you have tried with PTB and the
> pool, but both share the access link from your premises which may be
> the major source of error.
>
I found an error, I did the measurement on a different computer, not on that
computer were the DCF77 clock was attached. Now I did the measurement on the
NTP server directly. I got somehow better results. I recorded the difference of
offsets between the DCF77 clock and ptbtime2.ptb.de. The avverage is less than
0.5ms and no single difference is higher than +/- 2ms. I had to adjust the
time1 parameter to reach this. The graph at the pool shows me now a very
constant line at 5-6ms. Since now the values are less than the oscillation
before, I think I can't get it any better without a GPS clock.
The values for the time1 parameter are
default of the driver: 258
Best value now: 247 (lowest average difference to local offical time)
Value for a zero line at the pool: 241
Thanks for your efforts,
Michael Gellesch
> Cheers,
> Dave Hart
--
"It has long been known that one horse can run faster than another --
but which one? Differences are crucial."
-- Lazarus Long, "Time Enough for Love"
_______________________________________________
pool mailing list
[email protected]
http://lists.ntp.org/listinfo/pool
