I've sent this to EndRun tech support, but since they're not around at
the moment, figured I'd run a quick check with people on the list.  I
don't really expect an "oh, here's your problem", but I'd love one if
someone happens to know!

I have a somewhat older Praecis Ct (CDMA cellular time receiver) that
seems to be having either general problems or leap second problems, or
is locking itself to a bad CDMA station.  I'm a little baffled.

ntpdc> pe
remote          local      st poll reach  delay  offset    disp

---=====
*clock.xmission. 155.98.35.100    1  64  377 0.03848  0.664292 0.00499
=ops.emulab.net  155.98.35.100    2  64  377 0.00032  0.629554 0.00421
=GPS_PALISADE(0) 127.0.0.1        0  16  377 0.00000  0.000439 0.00023

I reset it and tried again a bit later, with more ntp servers:

=nist1.symmetric 155.98.35.100    1  64    1 0.03024  0.681881 7.93750
=clock.xmission. 155.98.35.100    1  64    1 0.03828  0.704977 7.93750
=ops.emulab.net  155.98.35.100    2  64    1 0.00037  0.683862 7.93750
*GPS_PALISADE(0) 127.0.0.1        0  16  37 0.00000  0.000297 0.43768

(top is nist1.datum.com, which I'm fairly certain is good)

Running the latest firmware from the website:

Praecis Ct FW 6010-0001-000 v 2.18 - May 25 2004 16:09:30  Praecis FPGA
6020-0001-000 v 09

The node is located in Salt Lake City, UT, at the University of Utah.

My guess, based on the other times I've seen things like this happen, is
either:

a)  It's synched to a CDMA base station that's running some funky
version of the spec.  This happened a while ago when some sites upgraded
to an early version of the CDMA2000 spec, for instance.

b)  It's synched to a CDMA base station that's just completely lost its
clock.  Last time this happened, it was a BS that was configured with
the wrong # of leap seconds (a few years ago, before the last one), but
this 0.7 second offset is just weird.

Some settings and debug info from the Ct, which probably won't make much
sense unless you've got one of these things yourself.

spstat shows:

LKD PRIB  57 212 35130  5.0 0.787

for the first, and

LKD PRIB  57 212 35128  5.8 0.029

for the second try.  (I should note that there was another one in there
where we actually appeared to be off by .96 seconds.)

Settings on the Ct are:

Cal = +0.000000000
ChannelSet = NORTH AMERICA
Ctime = OFF
DSTStart = 0,0,0
DSTStop = 0,0,0
Emul = TRIMBLE
Event = ON (TRIMBLE)
Leap = 14 14
Lo = +0:00
Port = 9600,8,N,1
Respmode = TERSE
Tmode = UTC

and there are no "fudges" or other things applied in ntp.conf that would
be causing the problem, as far as I can tell.

Hardware settings are:

Auxout = Ldetb
IFDiv = 0
NDiv = 29448
Agc = 212
Agc Mode = Auto
A/D Gain = 2 (High)
CarrierLock = On
CarrierPLLType = TYPE 0
EarlyLateMode = On

decoded msg is:

TimeStamp___  Ticks  Len  Typ  Rev  MRev  Sid__  Nid__  PnO  SysTime___
Lp  Off  DST  BadCrcCount
19088472    966  26    1    5    2    94      1  57 10474949728
14  -12  0  0

Leapinfo is:

CDMA system message leap second field = 14
User override settings: Override = 1, current = 14, future = 14, saved
timetag = 837977017
Current timetag = 837996007, current leap seconds = 14, current leap
state = OFF

Saved CDMA information is:

TimeStamp___  Nid__  Sid__  PN_  SNR_  AGC  TCXO_  LO_  DST  Leap  Len
Type  Rev  MRev  Freq_
837976990      1    94  57  5.4  213  35133  -12    0    14  26
1    5    2  PRI B
837995243      1    94  57  6.2  212  35131  -12    0    14  26
1    5    2  PRI B

Any clue would be appreciated!

-Dave

"Science News" for June 24, 2006 (yes, I'm behind on some
reading) has a letters column devoted to their article,
"To Leap or Not to Leap" in the 22 April issue.

Michael Zachary of Phoenix says he wouldn't mind accumulating
3600 leap seconds before changing because that's a time zone.

Dave Heiden of Stratford, Conn, suggests that computers can
have an algorithm to compute UTC from atomic time, starting
at the new millennium.

Frederic Fallon of Bowie, MD, suggests readjusting the definition
of atomic time so that there would be as many leaps ahead as back.
Dennis McCarthy of USNO said that the definition was too embedded
in the definition of physical standards to change. Besides, there
are more leaps back as the Earth slows down.

Just thought you'd like to know...

Bill Hawkins