comp.protocols.time.ntp Google Group

Re: Let ntp server not synchronize time from other servers

2008-08-30T02:01:26Z

WANG> That's what I did. But it can't work, if there's no server lines, I
WANG> _always_ got:
WANG> # /usr/sbin/ntpdate -u -b 192.168.90.41 28 Aug 11:21:35
WANG> ntpdate[10515]: no server suitable for synchronization found
ntpdate does not use the ntp.conf file.
I suspect that either .41 is not sync'd or you have firewall problems or a

Re: Linux NTP Kernel unsync flag remains long after NTP&Kernel have PPL sync

2008-08-30T01:39:03Z

I'd appreciate folks collecting various bits of wisdom about the
synchronization status of ntpd at:
[link]

Re: Linux NTP Kernel unsync flag remains long after NTP&Kernel have PPL sync

2008-08-30T01:26:45Z

Also see:
[link]
[link]

Re: NTP-Question about "ntpq -p"

2008-08-29T21:12:36Z

You don't need to dig too deeply in the archives to find cases of people
doing just that!

Re: NTP-Question about "ntpq -p"

2008-08-29T21:11:10Z

If he did, it is a case of garbage in and ntpd is under no obligation to
expeditiously correct for it. You can't evaluate the dynamic response
of ntpd based on unreasonable stimuli.

Re: Linux NTP Kernel unsync flag remains long after NTP&Kernel have PPL sync

2008-08-29T21:08:58Z

I don't understand what you are demonstrating. Without a measurment of
local clock error to a resolution of about 10 microseconds, in this
case, you cannot compare these offsets against the actual error,
although you can guess that the actual error might be of the order of 50
microseconds, relative to the systematic error in your time sources,

Re: Linux NTP Kernel unsync flag remains long after NTP&Kernel have PPL sync

2008-08-29T18:08:09Z

Let's see ... there's the offsets shown with:
ntpq -c"rv 0 offset"
ntpq -p
ntpdc -c kern | grep offset
Take your pick ...
Running all of those commands together against one of my systems
produces the following (I've combined the two ntpq invocations):
$ ntpq -pc"rv 0 offset" edge_box | awk '/offset=/ { print }; \

Re: offset with ntpdate and ntpq ?

2008-08-29T17:51:49Z

0.5 sec is 500 milliseconds. ntpd should have no problem keeping your
remote servers within that offset.
One way to do this is add all of your remote NTP servers to your
reference NTP server as 'noselect' servers. e.g.:
server remote_NTP_server noselect
You will need one of those lines for each of your remote NTP servers.

Re: Linux NTP Kernel unsync flag remains long after NTP&Kernel have PPL sync

2008-08-29T17:53:30Z

Why does any of this matter when you have NTP to set the clock at start
up?

Re: No libntp.so

2008-08-29T14:44:25Z

ntpq will not give the current time offset. It will give the offset last
time packets were sent out and filtered which could be hours ago. There is
not 25ms urgency. But then he has not responded as to what he needs from
ntpq and why he needs a less than 25ms latency on that query, so anything
we do is guessing. Modulo that your suggestion is undoubtedly better than

Re: NTP-Question about "ntpq -p"

2008-08-29T13:14:50Z

Unless he introduced the error deliberately in order to "test" NTP.

Re: offset with ntpdate and ntpq ?

2008-08-29T12:44:46Z

Dnia 29-08-2008 o 00:55:09 David Woolley
<da...@ex.djwhome.demon.co.uk. invalid> napisał(a):
Thanks for your answer. I am administrating large network (Intranet).
I need to control time of several internal NTP servers, each located in
different place/town.
I would like to "read" a time of each remote NTP server and compare it to

Re: Linux NTP Kernel unsync flag remains long after NTP&Kernel have PPL sync

2008-08-29T09:27:21Z

Yes and I still see it that NTP the daemon is in the correct position to
make the judgment.
All that remains is to feed NTP with a command detailing your
bounds/requirements and let it come back with an opinion in respect of that.
So "sync_ntp" is the important one here ?
And the state of convergence is the current estimated "offset" ?

Re: Very large offset and jitter values after reboot

2008-08-29T09:09:36Z

Hello Nicola,
First verify that hwclock worked well, immediatly looking at the
adjtimex "system-cmos" offset value:
If the offset is not a sane few microseconds, then let's see if
hwclock --systohc --debug can reveal something.
Serge.

Re: No libntp.so

2008-08-29T08:58:05Z

Hello Kay,
Why splitting up doquery?
If you would ever have to send several queries in parallel and then
receive several replies you'd have to check which reply is associated to
which query.
If your programming environment supports threads then I'd suggest to
start one thread for each server to be queried.