Synchronizing against a free-running server

[detha]

We have been trying to convince ntpd to synchronize with a free-running
windows server (why one would want to do this is another question, suffice
to say there are political reasons).

However I have not been able to convince it (neither 4.2.6p2 on debian nor
4.2.4p8 on centos) to do this. The moment the windows server is set to
sync to anything (pool.ntp.org, some other server, ...) it works. But
as long at the server advertises itself as 'stratum 1, .LOCL.', ntpd seems
to ignore it. Tried to force it using 'server 10.x.x.x true prefer', and
setting all other server lines including the local fall-back to
'noselect', no dice.

Any hints appreciated.

-d

[David Woolley]

detha wrote:
> We have been trying to convince ntpd to synchronize with a free-running
> windows server (why one would want to do this is another question, suffice
> to say there are political reasons).

Is this w32time? w32time will send a true root dispersion, which will
eventually disqualify the server. You will probably need to run the
real reference ntpd with a local clock pseudo driver (something not
otherwise recommended).

In general, though, you will need to provide the ntpq rv output for the
rejected server's association, to see why it is being rejected.

>
> However I have not been able to convince it (neither 4.2.6p2 on debian nor
> 4.2.4p8 on centos) to do this. The moment the windows server is set to
> sync to anything (pool.ntp.org, some other server, ...) it works. But
> as long at the server advertises itself as 'stratum 1, .LOCL.', ntpd seems

It is bad practice to use stratum one for the bogus local clock driver.
If there is another valid method of disciplining the clock, a lowish
stratum number is OK. If it is free-running, the stratum should be set
as high as possile subject to being acceptable to all of its clients, so
that it cannot accidentally propagate very far.

[detha]

On Mon, 15 Apr 2013 11:23:04 +0100, David Woolley wrote:

> detha wrote:
<snip>

> Is this w32time? w32time will send a true root dispersion, which will
> eventually disqualify the server. You will probably need to run the real
> reference ntpd with a local clock pseudo driver (something not otherwise
> recommended).
>
> In general, though, you will need to provide the ntpq rv output for the
> rejected server's association, to see why it is being rejected.

Alas yes, w32time. ntpq rv says:

ntpq> rv 1399
assID=1399 status=9014 reach, conf, 1 event, event_reach,
srcadr=10.55.17.245, srcport=123, dstadr=10.55.17.246, dstport=123,
leap=00, stratum=1, precision=-6, rootdelay=0.000,
rootdispersion=10802.399, refid=LOCL, reach=377, unreach=0, hmode=3,
pmode=4, hpoll=10, ppoll=10, flash=400 peer_dist, keyid=0, ttl=0,
offset=-124.961, delay=0.697, dispersion=34.222, jitter=41.139,
reftime=d515509e.59585f3c Sun, Apr 14 2013 17:58:22.349,
org=d5165a2a.eb856d92 Mon, Apr 15 2013 12:51:22.920,
rec=d5165a2b.162b3880 Mon, Apr 15 2013 12:51:23.086,
xmt=d5165a2b.15eab1f4 Mon, Apr 15 2013 12:51:23.085,
filtdelay= 0.98 0.70 0.80 0.58 0.61 1.09 0.00 0.96,
filtoffset= -166.10 -124.96 21.37 -181.69 -144.35 -0.09 41.00 -164.28,
filtdisp= 15.63 30.97 46.35 61.74 77.13 92.47 107.86 123.22
ntpq>

>
>> However I have not been able to convince it (neither 4.2.6p2 on debian
>> nor 4.2.4p8 on centos) to do this. The moment the windows server is set
>> to sync to anything (pool.ntp.org, some other server, ...) it works. But
>> as long at the server advertises itself as 'stratum 1, .LOCL.', ntpd
>> seems
>
> It is bad practice to use stratum one for the bogus local clock driver.
> If there is another valid method of disciplining the clock, a lowish
> stratum number is OK. If it is free-running, the stratum should be set as
> high as possile subject to being acceptable to all of its clients, so that
> it cannot accidentally propagate very far.

It's what w32time seems to do (I don't know too much about windows, so
maybe that can be tweaked)

This setup is at a remote site(remote as in 'intermittent connectivity,
sometimes a consistent ~200ms latency, sometimes 3G with huge latency
variations, sometimes nothing').

The whole setup needs about 500ms to 1 second accuracy, and at the
moment machines drift apart by 5 sec/day. I'm inclined to either just
leave it on 'hourly cron-job running ntpdate', or put together a box with
a Raspberry Pi and a GPS receiver and have it shipped out there.

-d

[David Woolley]

detha wrote:

> rootdispersion=10802.399, refid=LOCL, reach=377, unreach=0, hmode=3,

^^^^^^^^^

> pmode=4, hpoll=10, ppoll=10, flash=400 peer_dist, keyid=0, ttl=0,

^^^^^^^^^

Dispersion is too high because it is too long since the server
synchronised to any valid source. Faking root dispersion is the real
reason that one runs local clock drivers on free-running reference
implementation servers.

I don't know if and how w32time can be forced to lie about the root
dispersion.

You may be able to set tos maxdist on the clients, assuming they are
sufficiently recent, to make it tolerate root distances of more than 1.5
seconds (you'd need 11 seconds at the instant at which you ran rv, but
this value will grow without bounds).

>
> It's what w32time seems to do (I don't know too much about windows, so
> maybe that can be tweaked)

Recent versions of w32time can be tweaked to be NTP compliant, or at
least more or less so, but supporting a local clock driver is not part
or the requirements of the standard.

[David Taylor]

Ad David Woolley suggests, use the Windows port of reference NTP instead
of W32time:

http://www.satsignal.eu/ntp/setup.html
--
Cheers,
David
Web: http://www.satsignal.eu

[detha]

On Mon, 15 Apr 2013 13:22:57 +0100, David Woolley wrote:

> detha wrote:
>

>> It's what w32time seems to do (I don't know too much about windows, so
>> maybe that can be tweaked)
>
>
> Recent versions of w32time can be tweaked to be NTP compliant, or at least
> more or less so, but supporting a local clock driver is not part or the
> requirements of the standard.

Thanks for pointing me at the root dispersion.

For future reference: 'w32tm /localclockdispersion:0 /update' seems to
turn w32time from a bad liar into an accomplished liar - at least it works
in my test setup. Totally broken solution, do not try this at home, but
for now it will do what I need until I can a better solution approved and
in place.

-d

[Jeroen Mostert]

On 2013-04-15 11:40, detha wrote:
> We have been trying to convince ntpd to synchronize with a free-running
> windows server (why one would want to do this is another question, suffice
> to say there are political reasons).
>

I'm sort of curious what reasons those could be. Is the Windows machine the
domain controller and do people think that syncing with it is better than not
syncing with it?

This is sort-of true, even, although this set-up is really weak. Even so, in my
experience, having ntpd clients sync with a w32time server is still not as bad
as the other way around. The best set-up is ntpd all the way, of course, whether
you sync with external time or not. Even sync to within 1 second is not
something w32time can promise (although that's probably more a problem on the
client side than the server side).

The next logical step might be sneaking ntpd onto the Windows server. It
performs fine, especially on Windows Server 2012/W8. Installing ntpd on all
Windows clients could be a bit more involved.

--
J.

[David Woolley]

Jeroen Mostert wrote:

> sync to within 1 second is not something w32time can promise (although
> that's probably more a problem on the client side than the server side).

Modern w32time's can achieve this, but generally won't do so out of the
box, and the number of people who run it in a configuration much
different from that must be quite few.

[Jeroen Mostert]

Now you tell me, I've just installed ntpd on all the machines in our network!

Just kidding. Even if I learned how to configure w32time like this it would
still be of limited value because the machines are not all using the same
Windows version, there's no way to upgrade w32time (AFAIK), the settings are
poorly documented at best and even if w32time can /de facto/ achieve better
results, the fact that Microsoft explicitly says "good for you if you do but we
are really putting no support into that scenario" convinces me that banking on
it is something you should only do if the costs of rolling out ntpd are really
prohibitive for some reason.

That's ignoring the fact that 1 sec is by far not good enough for my particular
scenario, but that's another discussion altogether.

--
J.

[unruh]

Would it not have been better to leave the bad solution in place and
tell the higherups that win32time simply cannot be made to work? The
problem with the good-enough kludge is that it is the enemy of the
better.


>
> -d

[detha]

On Mon, 15 Apr 2013 17:01:50 +0200, Jeroen Mostert wrote:

> On 2013-04-15 11:40, detha wrote:
>> We have been trying to convince ntpd to synchronize with a free-running
>> windows server (why one would want to do this is another question,
>> suffice to say there are political reasons).
>>
> I'm sort of curious what reasons those could be. Is the Windows machine
> the domain controller and do people think that syncing with it is better
> than not syncing with it?

Site with no reliable external comms. There have been cases with similar
sites that were solely on VSAT where the interface with the outside world
consisted of a USB external harddrive that got driven back and forth to a
nearby (~100 miles) site daily for over a week.

A bunch of Win7 PCs and embedded systems, W2K8 PDC, and one or two Linux
boxen. One needs to be able to match timestamps in logfiles between
boxes.

>
> This is sort-of true, even, although this set-up is really weak. Even
> so, in my experience, having ntpd clients sync with a w32time server is
> still not as bad as the other way around. The best set-up is ntpd all
> the way, of course, whether you sync with external time or not. Even
> sync to within 1 second is not something w32time can promise (although
> that's probably more a problem on the client side than the server side).
>
> The next logical step might be sneaking ntpd onto the Windows server. It
> performs fine, especially on Windows Server 2012/W8. Installing ntpd on
> all Windows clients could be a bit more involved.

Putting ntpd on the PDC is probably an option. All clients? Not so much.
Having a timesource with a GPS receiver would be better. What gets chosen
in the end depends more on internal politics and financial issues than on
sound technical reasons.

[detha]

On Mon, 15 Apr 2013 16:53:42 +0000, unruh wrote:

> Would it not have been better to leave the bad solution in place and tell
> the higherups that win32time simply cannot be made to work? The problem
> with the good-enough kludge is that it is the enemy of the better.
>

You are right Bill. Often happens, but in this case the technical manager
in charge has a clue or two. This is only the first site in this
configuration, and I'm surprised they didn't spec an external time source.
For the next 15 or so I'll put together a simple 1U box with a
power supply, Soekris or Raspberry board, a GPS receiver and a ton of
surge suppressors hidden in it. Just need time to get something together,
and get it past finance.

-d

[E-Mail Sent to this address will be added to the BlackLists]

detha wrote:
> A bunch of Win7 PCs and embedded systems, W2K8 PDC,
> and one or two Linux boxen.
> One needs to be able to match timestamps in logfiles
> between boxes.

If "Match" means within however they all drift apart between
during the time between when the clock are correctly reset.

Is that going to be Matchmaking within a Minute ?

The way people solve the issue of not having external
comm for sysc, nor GPS (far underground ?),
is to have a local reference like a rubidium / cesium
frequency source {or perhaps a cheaper less accurate
TCXO / OCXO}, so that it can keep time within spec.

See ANSI T1.101 Table 2, or a doc that references it;
e.g. <http://www.spectratime.com/product_downloads/an_itu_ansi.pdf>


FYI, you can buy a NTP server with an internal "atomic" frequency
reference from dozens (hundreds ?) of vendors like BrandyWine,
Elproma, EndRunTechnologies, HP, OscilloQuartz, SpectraTime,
Symmetricom, Unitronix, ...;

As well as things like single unit appliance GPS Antenna / NTP server.



--
E-Mail Sent to this address <Blac...@Anitech-Systems.com>
will be added to the BlackLists.