[ntp:questions] Tobit LAN!Time DCF77 receiver not working
nomail at example.com
Fri Dec 25 12:03:17 UTC 2009
Marc-Andre Alpers <m-a.alpers at web.de> wrote:
> Es schrieb Rob:
>> Get a better set of time references on the network (that a referenced
>> off a GPS or similar clock) and that agree to eachother.
>> With this set, there is no way to tell where you are.
> And now?
> remote refid st t when poll reach delay offset jitter
> LOCAL(0) .LOCL. 10 l 6 64 377 0.000 0.000 0.001
> *SHM(0) .DCFa. 0 l 54 64 377 0.000 1.898 0.478
> ntp1.sda.t-onli .PPS. 1 u 22 128 377 32.013 32.997 2.745
> ntp1.sul.t-onli .PPS. 1 u 7 128 377 37.546 32.421 5.332
> metasweb01.admi .HBGi. 1 u 7 128 377 38.800 32.678 1.276
> chronos.zedat.f .PPS. 1 u 20 128 377 39.441 30.029 1.489
> ntp1.rrze.uni-e .DCFp. 1 u 10 128 377 35.681 33.177 3.585
> It seems i have an offset of round about 31 ms. Right?
> In remembrance, I do not need a hundred percent right time. Just as close as
> possible with this setup. The computer will not work in a temperature
> controlled environment.
> MfG Marc-Andre Alpers
Yes this looks good.
Now you tweak the offset until your external sources are near zero offset.
It is always difficult to predict in which direction you have to move,
so just add 31 ms and if this worsens it, subtract 62.
Also, during this operation you will be affected by the bad startup
characteristics of ntpd. Tweaking the file and restarting ntpd a couple
of times can make it very unstable. Sometimes it steers away from
correct time, loses lock, jumps back, attempts again, steers away again,
This problem does not exist in the labs of the creators of the software,
so nothing is being done about it.
Be patient. After a while things will stabilize and you can make another
judgement about the accuracy of your offset.
More information about the questions