Wolfgang S. Rupprecht wrote: > Can someone shed any light on what is going on here? Could > clock.sjc.he.net have jumped the gun and inserted a leap second a day > early? I've never seen it off by more than a millisecond or two > before and the offset of almost exactly a second is very suspicious, > especially since we are so close to a leap second event. > > remote refid st t when poll reach delay offset jitter > ============================================================================== > *GPS_ONCORE(0) .GPS. 0 l 14 16 377 0.000 0.004 0.002 > -bonnet.wsrcc.co 25.96.172.67 2 u 34 64 377 0.250 -0.473 0.390 > xclock.sjc.he.ne .CDMA. 1 u 7 64 377 15.278 -999.34 0.953 > LOCAL(0) LOCAL(0) 10 l 45 64 377 0.000 0.000 0.001 > > -wolfgang > -- > Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ > Direct SIP URL Dialing: http://www.wsrcc.com/wolfgang/phonedirectory.html
Sure looks like a software bug in the reference clock. They do not have additional backup references to protect against false ticking. Here is the current status: $ ntpq -c cv clock.sjc.he.net status=0606 clk_badtime, last_clk_badtime device="EndRun Technologies Praecis CDMA", timecode="2005 365 15:41:02.644978", poll=415464, noreply=1, badformat=0, baddata=1, fudgetime1=0.000, stratum=0, refid=CDMA, flags=2 I suppose it could be an error in the actual reference clock in the cellsite this thing is listening to which is likely a GPS rcvr. Humm. . . My PCS phone is a second slow right now, but I've never actually checked it to the second before. . . Roger (at hmc.edu) _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
