Dave Hart

"We continue to investigate why these connections were timing out
during connect, rather than quickly determining that there was no
route to the unavailable hosts and failing quickly."

potential translation:

"We continue to shoot ourselves in the foot by filtering all ICMP
without understanding the implications."

Cheers,
Dave Hart

I hope anyone implementing systems that depend on minutae of leap
seconds does not rely solely on your reading, but actually tests by
inconveniently setting their clock and ntpd leapfile to actually
insert a leap second.

That FAQ is woefully out of date.   http://support.ntp.org/  has more
current information.  The best reference for a given ntpd version is
the html docs included in the tarball for that version.  Some
widely-used versions' html documentation is archived at http://doc.ntp.org/

But exactly how it handles it is up to the kernel.  Linux and FreeBSD
essentially step the clock backward 1s at 23:59:60.0 UTC.  At least
one system (I believe it was NetBSD or OpenBSD) instead stalls the
clock for 1s, though each reading of the clock during that period is
greater than the prior, the delta is microscopic and not related to
elapsed time within that second, but simply preserves ordering of
events.  Dr. Mills attempted to exhort kernel developers to implement
leap seconds while keeping the system time ever-increasing, but that
advice was largely ignored because of implementation difficulty.  For
example, when first considered, NTP kernel extensions had microsecond
precision.  The approach of adding a tiny amount with each reading
would open the system up to problems if apps could read the clock more
than 1 million times during the leap second.  It's also ugly for a SMP
kernel to maintain global state on the last clock reading across
processors.

Most systems offer a monotonic alternative to the wall clock,
typically implemented as an uptime counter in nominal SI seconds
(nominal as defined by hardware, as the monotonic clock is _not_
disciplined by ntpd or affected by steps (setting the wall clock to a
particular value).  Look for CLOCK_MONOTONIC in the documentation of
clock_gettime.  There are also interval-only timer facilities like
timer_settime.  The tools are at hand for those who understand the
implications of clock steps (which can occur under circumstances other
than leap seconds).

This is the historic behavior of ntpd, but after years of complaints,
it was changed.  ntpd 4.2.6 and later step the clock backward 1s at
the scheduled insertion if using the daemon loop discipline (as
opposed to the kernel loop discipline).

That is incorrect.  -x is often misunderstood -- it does not disable
stepping entirely, it raises the "step threshold" from 0.128s default
to 600s.  When ntpd synchronizes the clock and determines the offset
exceeds the step threshold, the clock is stepped to the correct time.
So long as you manage to keep your clock within 10 minutes of correct,
-x isn't terribly different from disabling steps, but that's not what
it does.

In particular, when ntpd using the daemon loop implements a leap
second by stepping the clock backward one second, the step threshold
(and hence -x) are not a decision factor -- the step is taken.

Cheers,
Dave Hart

I agree the Garmin GPS 18x LVC solution is only appropriate near a
window, or in a short wooden structure.  David J. Taylor's experience
was the older GPS 18 LVC had a substantially less sensitive receiver,
so that his needed to be mounted outside, while his 18x LVC works
inside.

The area where 18x LVC underperforms the 18 LVC is the jitter of the
timing of its NMEA output relative to the leading edge of the PPS.
Configured correctly, this should matter very little, and only
transiently at startup where ntpd first uses the NMEA end-of-line
timestamp (possibly fudged to bring it closer to the top of second) to
"number the seconds" before engaging the PPS.  I don't recommend
attempting to use any NMEA source without PPS.  With it, I don't
understand why Majdi finds the 18x LVC much worse.

The 18x is a number of years old at this point.  Newer GPS receivers
(such as the Sure GPS evaluation kits at around $30) are likely to be
much more sensitive.  I've heard reports of them working in basements
and in office buildings 20 or more feet from a window.

There was a bug in early firmware versions of the GPS 18x LVC that
could result in the device wedging until you either left it unpowered
long enough to drain its battery/capacitor and thereby clear its
configuration, or cracked it open to achieve the same, or (as many
did) exchanged it with Garmin for a replacement.  I believe that bug
was first fixed in the 3.20 or 3.30 release, but one of those made the
NMEA timing even worse, sometimes causing NMEA sentences to continue
past the next top-of-second that could have fit easily in one second
if not so delayed.  The NMEA timing was improved in the 3.70 firmware,
which I recommend all GPS 18x LVC   ntpd users upgrade to,
particularly those using 3.20 or earlier.

The change history included with the 3.70 firmware doesn't completely
align with my recollection.  There's no mention of fixing the bricking
bug I mentioned.  The closest likely mention is of a 3.60 fix:

Version 3.50 to 3.60

1.  Fixed factory firmware flash capabilities.

It does confirm the NMEA timing fix for 3.70, on the other hand.

Cheers,
Dave Hart