Sander Smeenk wrote:
Quoting Terje Mathisen (terje.mathi...@tmsw.no):
a) You should not run ntpdate, instead you use the -q option to ntpd to
handle any initial time steps.
What is actually wrong with running ntpdate to initially sync a clock?
Why is the ntpdate.exe binary provided when 'we' shouldnt use it?
Keep in mind that i 'just want to get to seconds accuracy' before i
start ntpd.
There's nothing wrong with using ntpdate, especially not under Windows
As already pointed out in some other posts here, ntpdate
- always steps the time if the -b option is used
- if the -b option is not used then it slews the time if the offset is
below 128 ms, else it steps the time
- under Windows ntpdate is unable to slew the time (ntpd can, of
course), so *have to* use the -b option
I think the discussion whether ntpdate should be used or not is
worthless in this case. Maybe some of you remember the problems with the
Windows multimedia timer, causing virtual time steps of the windows
system time if set to highest resolution by some application *after*
ntpd has been started.
As a workaround to avoid this ntpd for windows sets the MM timer to
highest resolution by itself when the service starts (if the ntpd's -M
option is used, which is the default when the Meinberg installer is used).
This usually causes the initial time seen by ntpd to be off by a couple
of milliseconds anyway, since the virtual time step happens immediately.
Anyway, after this the reported time offset should *decrease* down to
some minimum, which depends on the target hardware, etc.
b) All the delay/offset/jitter times are measured in ms, not seconds!
I actually knew that. I made that mistake on this list before.
However it is also not relevant to the issues i am experiencing. Wether
it's microseconds or seconds, the jumps in offset/jitter are abnormal
nonetheless.
c) It seems that you have an ntp.drift file which contains "500"!
Indeed i did. That file was probably written by ntpd after the first run
going completely haywire. I removed it from the configuration. No change
to the issues i'm experiencing.
That's what I would expect. If the time offset doesn't settle you will
probably have a new driftfile with a similar wrong huge drift value.
Martin
--
Martin Burnicki
Meinberg Funkuhren
Bad Pyrmont
Germany
_______________________________________________
questions mailing list
questions@lists.ntp.org
http://lists.ntp.org/listinfo/questions
