Effects of mindist setting

I have a bunch Endrun Technologies CDMA clock attached to small servers
using PPS. To prevent the jitter on the serial port from causing the
clock to be marked as falsetick and disabling the PPS, I have added "tos
mindist" to my configuration.

I am unclear on the actual effect of this configuration and that makes
me a bit unsure of how I should set the value. 0.010 was one
recommendation and 0.015 was another.

Any place I can look for an explanation of this? I don't see in in the
documentation.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: [email]oberman@es.net[/email] Phone: +1 510 486-8634
Key fingerprint:059B 2DDF 031C 9BA3 14A4 EADA 927D EBB3 987B 3751

_______________________________________________
questions mailing list
[email]questions@lists.ntp.isc.org[/email]
[url]https://lists.ntp.isc.org/mailman/listinfo/questions[/url]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (FreeBSD)
Comment: Exmh version 2.5 06/03/2002

iD8DBQFFFAebkn3rs5h7N1ERAnX3AJ0VVbe/0JBvnfDXuf5vzJDNcZcxwwCglA8Q
R88KrFjzHgG9lBrByML9Of8=
=Kmgb
-----END PGP SIGNATURE-----

Kevin Oberman wrote:[color=blue]
> I have a bunch Endrun Technologies CDMA clock attached to small servers
> using PPS. To prevent the jitter on the serial port from causing the
> clock to be marked as falsetick and disabling the PPS, I have added "tos
> mindist" to my configuration.
>
> I am unclear on the actual effect of this configuration and that makes
> me a bit unsure of how I should set the value. 0.010 was one
> recommendation and 0.015 was another.
>
> Any place I can look for an explanation of this? I don't see in in the
> documentation.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> questions mailing list
> [email]questions@lists.ntp.isc.org[/email]
> [url]https://lists.ntp.isc.org/mailman/listinfo/questions[/url][/color]

Either your posting was delayed many hours or your clock is way off!

Kevin,

See the architecture briefing at the NTP project page and especially the
slide on the selection/intersection algorithm. The mindist value is
added to the correctness interval in order to widen it and allow for
increased jitter.

Dave

Kevin Oberman wrote:[color=blue]
> I have a bunch Endrun Technologies CDMA clock attached to small servers
> using PPS. To prevent the jitter on the serial port from causing the
> clock to be marked as falsetick and disabling the PPS, I have added "tos
> mindist" to my configuration.
>
> I am unclear on the actual effect of this configuration and that makes
> me a bit unsure of how I should set the value. 0.010 was one
> recommendation and 0.015 was another.
>
> Any place I can look for an explanation of this? I don't see in in the
> documentation.
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> questions mailing list
> [email]questions@lists.ntp.isc.org[/email]
> [url]https://lists.ntp.isc.org/mailman/listinfo/questions[/url][/color]

Kevin Oberman wrote:[color=blue]
> I have a bunch Endrun Technologies CDMA clock attached to small servers
> using PPS. To prevent the jitter on the serial port from causing the
> clock to be marked as falsetick and disabling the PPS, I have added "tos
> mindist" to my configuration.
>
> I am unclear on the actual effect of this configuration and that makes
> me a bit unsure of how I should set the value. 0.010 was one
> recommendation and 0.015 was another.
>
> Any place I can look for an explanation of this? I don't see in in the
> documentation.[/color]

I see Dr Mills pointed you to the mathematical description...

For the 'code' description - see ntp_proto.c:3448 (the middle of the clock
intersection algorithm). The root_distance() function uses the mindist value to
basically state that no clock is 'better' than the given dispersion distance.

I recommended the 0.015 value for the owamp systems simply because our
calibration tests of the CDMA serial interface put it between 0.012 and 0.013
off from the PPS. (fudge time1)

After thinking this over more - I don't think mindist should be as large as I said.

First - once we set the time1 value the magnitude of the dispersions should be
decreased. (Was the 0.010 recommendation in
[url]http://ntp.isc.org/bin/view/Support/ConfiguringHPZ3801ARefclocks[/url]
based on any tests? Or perhaps assumptions based on Unix scheduling?)

Second, after more closely examining the code, I realize mindist actually sets
the root distance for each and every peer to the max of the real distance, and
this value. (This makes perfect sense - I just did not think through it.)

Unfortunately, this will effect the error estimate. For the one-way network
latency measurements - we really want to minimize the error estimates as much as
we can.

So, even the 0.010 value is probably larger than we want. We should experiment
with our hardware/OS combinations and try and use the smallest value we can that
removes the clock hopping problem.

jeff

>>> In article <12hgom22phb2d2e@corp.supernews.com>, "Jeff W. Boote" <boote@internet2.edu> writes:
Jeff> First - once we set the time1 value the magnitude of the dispersions
Jeff> should be decreased. (Was the 0.010 recommendation in
Jeff> [url]http://ntp.isc.org/bin/view/Support/ConfiguringHPZ3801ARefclocks[/url] based
Jeff> on any tests? Or perhaps assumptions based on Unix scheduling?)

No idea - please add your experience and ideas there.

H

[color=blue]
>First - once we set the time1 value the magnitude of the dispersions should be
>decreased. (Was the 0.010 recommendation in
>[url]http://ntp.isc.org/bin/view/Support/ConfiguringHPZ3801ARefclocks[/url]
>based on any tests? Or perhaps assumptions based on Unix scheduling?)[/color]

I wrote that text.

I think I pulled that value from a posting here, but that was a long
time ago. google-groups on mindist might find it. Try the thread
from Feb 2005, Subject: On jittery clocks and precision PPS signals

I tried it. It fixed my problem. I haven't done any testing.

--
The suespammers.org mail server is located in California. So are all my
other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's. I hate spam.

Guys,

The tinker mindist given on the cited ISC page is misleading. Each case
with each refclock, driver and kernel is different. The mindist defaults
to the minimum dispersion MINDISP (.005 s). This implies a rather close
agreement between the serial timecode signal and PPS signal. I have
observed wide variations between various refclocks with these signals,
due mostly to the FIFO in late model UART chips. The FIFO needs to be
disabled and, in some systems, the kernel driver software FIFO needs to
be disabled as well. Means for doing this vary widely between operating
systems and motherboards.

Those drivers that use the median filter in the refclock interface
usually find residual jitter well beneath the noise floor established by
the measured system precision. Peek at rackety.udel.edu and note the
jitter is usually only a few microseconds. One reason for the low PPS
jitter is that the atom driver uses the median filter and kernel PLL
discipline, but not the kernel PPS discipline. Note also that the
variation between the timecode and PPS signals is usually only a few
microseconds. Not too shabby for a very old Intel machine with FreeBSD,
GPS, parallel-port PPS and many hundreds of clients.

The experience with rackety suggests an interesting conclusion. The
residual errors with the timecode signal are almost as low as with the
PPS signal. So, why use the PPS at all? You need it to calibrate the
timecode signal with respect to the PPS signal, normally the most
accurate. The trick is to get the systematic offset (fudge time1) with
the serial driver) whittled down as far as possible and tinker the
mindist to something greater than the residual jitter. The calibrate
command in the configuration file can be used to do this automatically.

The Spectracom GPS seen by rackety is rather like a rock, but our
Spectracom WWVB receivers are very much worse due to local RFI generated
by UPS systems. The only one remaining that works at all is at my
suburban home, but even there RFI pollution has degraded accuracy and
consistency between timecode and PPS signals to several milliseconds and
does require tinker mindist. Your mileage may vary.

Dave

Harlan Stenn wrote:
[color=blue][color=green][color=darkred]
>>>>In article <12hgom22phb2d2e@corp.supernews.com>, "Jeff W. Boote" <boote@internet2.edu> writes:[/color][/color]
>
> Jeff> First - once we set the time1 value the magnitude of the dispersions
> Jeff> should be decreased. (Was the 0.010 recommendation in
> Jeff> [url]http://ntp.isc.org/bin/view/Support/ConfiguringHPZ3801ARefclocks[/url] based
> Jeff> on any tests? Or perhaps assumptions based on Unix scheduling?)
>
> No idea - please add your experience and ideas there.
>
> H[/color]

On Fri, 22 Sep 2006 15:56:11 GMT, [email]oberman@es.net[/email] (Kevin Oberman) wrote
for the entire planet to see:
[color=blue]
>I have a bunch Endrun Technologies CDMA clock attached to small servers
>using PPS. To prevent the jitter on the serial port from causing the
>clock to be marked as falsetick and disabling the PPS, I have added "tos
>mindist" to my configuration.[/color]

I don't use the PPS but the RTS style of interface to the Endrun CDMA.
This eliminates any concern about serial latency. I'm not sure it
offers as good precision as PPS if PPS is working well, but it's has
much lower potential for jitter and latency problems.

- Eric