On Sat, 31 Dec 2005 23:31:25 -0800, Bruce Penrod <[EMAIL PROTECTED]> 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 midnight? 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 <[EMAIL PROTECTED]> 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. _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
