[ntp:questions] Re: CDMA and Leap Seconds

Eric Jensen ejensen at spamcop.net
Mon Jan 2 14:39:24 UTC 2006

On Sat, 31 Dec 2005 23:31:25 -0800, Bruce Penrod
<bmpenrod at comcast.net> wrote:
Hi Bruce - 

First of all, there were quite a few glitches surrounding the
leap-second, many of them not related to CDMA or your products. 

 I apprectiate your explanation of the problem, but I have a different
point of view in a couple of areas.   As an affected Endrun CDMA clock
user, I have the following comments. 

My base station apparently started transmitting the new TAI-UTC offset
one day early. Or, perhap one could say it started transmitting the
new offset during the last day of the year, expecting that all users
of the signal understood it was only to be applied at the next UTC

You have the manual setting available to override the transmitted
offset, which you referenced in your post and also in the support
bulletin.  I actually came into the office to make the manual
adjustment six hours before midnight UTC, and discovered that my clock
had been off for 18 hours already.  Your support bulletin said
specifically that the manual adjustment could be applied to the unit
anytime up to midnight of the day in question.  Not so,  it turns out.

Another problem with manual adjustments is that they require repeated
attention.  My reference clock was off by a second for about 24 hours
using the glitchy automatic settings.  Clocks that have been manually
configured could be off for days, weeks, or indefinetly if they are
installed and forgotten about.  I don't think relying on manual
intervention is a good long-term solution.

If I understand your post, products of yours shipped after July 1,
2005 had the leap seconds values manually set.  Does this mean that
all of those devices will miss the next leap second(s) permanently, if
not manually reconfigured each time?

Because the manual settings can be applied ahead of time and are
implemented by the clock at the correct time, I think there must be a
way to take the transmitted offset (early) and only apply it at the
correct time and day.  

To summarize, my CDMA reference clock gave the wrong time for one day,
the product bulletin had incorrect advice, and the "solution" of
manual intervention before each leap event is not very practical.  Net
result, my clock added to the instability on the 'net, and I am
embarrased and dismayed.

I look forward to a CDMA firmware revision that solves this problem
before the next leap-second.  

- Eric

On Sat, 31 Dec 2005 23:31:25 -0800, Bruce Penrod
<bmpenrod at comcast.net> wrote:

>Though until now there have been no leap second insertions since we 
>began shipping our CDMA based products, we have had over the years a 
>handful of customers report basestations transmitting leap second values 
>that were off by one second.  In response, three years ago we created a 
>user enterable leap second mode for our CDMA products to allow 
>overriding the system transmitted value if necessary.  This mode also 
>included the ability to set up the future leap second value prior to the 
>next insertion so as to be independent of the behavior of the 
>basestation.  This has all been well documented in the product manuals 
>and a webpage dedicated to leap seconds has been maintained continuously 
>on our site to show the current and future values of the leap second so 
>that customers may easily determine how to configure their boxes.
>When the IERS Bulletin C arrived in July, we updated our website and 
>notified via e-mail all CDMA product customers of the impending leap 
>second, and recommended that all users operate their NTP servers in the 
>user leap second mode.  All NTP servers we shipped after July 1 were 
>preconfigured to user leap second mode with the current and future leap 
>seconds set appropriately.

More information about the questions mailing list