offset with ntpdate and ntpq ?

Hello,

I have some questions regarding value offset with ntpq and ntpdate, these
values are different or not?
whether the value of the offset with ntpq is the difference local - peer?

Regards
Stavros Milos

Stavros Milos wrote:[color=blue]
>
> I have some questions regarding value offset with ntpq and ntpdate, these
> values are different or not?
> whether the value of the offset with ntpq is the difference local - peer?[/color]

The offset is the difference between the local time and an estimate
based on the weighted average of the "best of the last 8" measurements
made on the set of servers and peers chosen for disciplining the clock.

The local time is a smoothed estimate of the true time. The offset is
an unsmoothed estimate of the time on the other servers. Normally the
local time is a better estimate of true time, even if the actual time on
the servers is perfect.

Why are so many questions turning on the meaning of "Offset", in NTP
jargon, today?

Dnia 29-08-2008 o 00:55:09 David Woolley
<david@ex.djwhome.demon.co.uk.invalid> napisał(a):
[color=blue]
> Why are so many questions turning on the meaning of "Offset", in NTP
> jargon, today?[/color]


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
my local referential timeserver, just to examine if offset of each remote
NTP server is not too high. So, the purpose is not to synchronize time to
remote NTP servers, but to trace their time to keep a rule:

"remopte NTP server time" - "my referential NTP server time" < 0.5s

Regards
Stavros Milos

On 2008-08-29, Stavros Milos <root78@gazeta.pl> wrote:
[color=blue]
> 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 my local referential timeserver, just to examine if offset of
> each remote NTP server is not too high. So, the purpose is not to
> synchronize time to remote NTP servers, but to trace their time to
> keep a rule:
>
> "remote NTP server time" - "my referential NTP server time" < 0.5s[/color]

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.

Then you will be able to use the ntpq peers billboard ('ntpq -p') to
view all the offsets between your remote NTP servers and your reference
NTP server.

--
Steve Kostecke <kostecke@ntp.org>
NTP Public Services Project - [url]http://support.ntp.org/[/url]

Stavros Milos wrote:
[color=blue]
> I would like to "read" a time of each remote NTP server and compare it
> to my local referential timeserver, just to examine if offset of each
> remote NTP server is not too high. So, the purpose is not to synchronize
> time to remote NTP servers, but to trace their time to keep a rule:
>
> "remopte NTP server time" - "my referential NTP server time" < 0.5s[/color]

"Offset" doesn't really give you this information. If the ntpd design
is valid, "offset" is either a measure of the network performance, or
that ntpd has not been running long enough to work out which part of the
offset is a true clock error and which part measurement variation. If
you know of a way of telling the difference between a true error and
measurement uncertainty, before ntpd is able to do so, you need to
submit your algorithm to the NTP community.

David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
[color=blue]
>Stavros Milos wrote:[/color]
[color=blue][color=green]
>> I would like to "read" a time of each remote NTP server and compare it
>> to my local referential timeserver, just to examine if offset of each
>> remote NTP server is not too high. So, the purpose is not to synchronize
>> time to remote NTP servers, but to trace their time to keep a rule:
>>
>> "remopte NTP server time" - "my referential NTP server time" < 0.5s[/color][/color]
[color=blue]
>"Offset" doesn't really give you this information. If the ntpd design
>is valid, "offset" is either a measure of the network performance, or
>that ntpd has not been running long enough to work out which part of the
>offset is a true clock error and which part measurement variation. If
>you know of a way of telling the difference between a true error and
>measurement uncertainty, before ntpd is able to do so, you need to
>submit your algorithm to the NTP community.[/color]

Actually I have submitted such an algorithm but interest is low ( chrony
does it much faster than does ntp) But that is irrelevant. If he has
network errors of 500ms he has one very very weird network. For a local
network the network errors are typically microseconds, not seconds. ( Note
that offsets of seconds ntp will step so apparently it does know it is not
random network errors. )

Unruh wrote:[color=blue]
> David Woolley <david@ex.djwhome.demon.co.uk.invalid> writes:
>
>[color=green]
>>Stavros Milos wrote:[/color]
>
>[color=green][color=darkred]
>>>I would like to "read" a time of each remote NTP server and compare it
>>>to my local referential timeserver, just to examine if offset of each
>>>remote NTP server is not too high. So, the purpose is not to synchronize
>>>time to remote NTP servers, but to trace their time to keep a rule:
>>>
>>> "remopte NTP server time" - "my referential NTP server time" < 0.5s[/color][/color]
>
>[color=green]
>>"Offset" doesn't really give you this information. If the ntpd design
>>is valid, "offset" is either a measure of the network performance, or
>>that ntpd has not been running long enough to work out which part of the
>>offset is a true clock error and which part measurement variation. If
>>you know of a way of telling the difference between a true error and
>>measurement uncertainty, before ntpd is able to do so, you need to
>>submit your algorithm to the NTP community.[/color]
>
>
> Actually I have submitted such an algorithm but interest is low ( chrony
> does it much faster than does ntp) But that is irrelevant. If he has
> network errors of 500ms he has one very very weird network. For a local
> network the network errors are typically microseconds, not seconds. ( Note
> that offsets of seconds ntp will step so apparently it does know it is not
> random network errors. )
>[/color]
You get that kind of (wrong) offset when your machine is sitting at the
end of an ISDN line that is heavily utilised in one direction only.
This is the reason why I would like to have signaling to tell the
ntp daemon "poll now".
This can be _partly_ remedied with ( or similar )
tinker huffpuff 160000
you will still have the clock going south on occasion.

This is a feature that is of interest to mobile platforms too
( "mobile" platforms need the "hey man there is a new door" signaling too ).

uwe

Uwe Klein wrote:[color=blue][color=green]
>>[/color]
> You get that kind of (wrong) offset when your machine is sitting at the
> end of an ISDN line that is heavily utilised in one direction only.[/color]

Exactly. If you do this with a modem, root distance goes so high that
the measurements are rejected, but if you do it with something just that
little bit faster, you end up with balancing positive and negative
steps, as people start and finish their browser sessions.
[color=blue]
> This can be _partly_ remedied with ( or similar )
> tinker huffpuff 160000[/color]

tinker huffpuff was introduced precisely to cover this situation.
[color=blue]
> you will still have the clock going south on occasion.[/color]

The best approach, though is to prioritise NTP traffic, but with the
sort of speed of line for which this happens, you are unlikely to be an
important enough customer of the ISP for them to do it at their end,
unless they are enlightened enough to have done it for everyone.