[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ntp-hackers
Subject:    [ntp:hackers] Re: holdover,
From:       "David L. Mills" <mills () udel ! edu>
Date:       2004-03-07 0:41:49
Message-ID: 404A6FCD.C6072B34 () udel ! edu
[Download RAW message or body]

gnu not unix,

I said some brainfog in my last, as I had forgotten a driver change some
time back. I did in fact change to the behavior you report; that is,
when no signals on any frequency from either station are heard after 30
minutes, which is time enough for three cycles over all ten
frequency/stations, the radio comes unreachable. The reason I did that
was for cases when the radio is indeed unreachable yet other radios or
backup servers are still alive. My reasoning is that, if holdover is
necessary, that can be done with the local clock driver.

The original design did provide a much longer holdover, presumably
enough to span a couple days for a single-frequency receiver to grab the
signal as the MUF waxes and wanes. However, once the driver has settled
down and the time constant has reached the max (1024 s), the driver sees
typically no more than a few milliseconds bump during recovery after
6-18 hours of signal loss.

My original assumption was that the codec clock is probably better than
the CPU clock, so it makes sense to continue discipline with the codec
clock when the signal goes away. After experience with recent Solaris
audio drivers, I no longer cling to that assumption.

Dave

gnu not unix wrote:
> 
> In message <4049B805.nail6C111Y166@mini-me.trailing-edge.com> you write:
> 
> (Steven wrote about "coasting" aka holdover):
> >> any of the coasting the old code would do.
> 
> >I am running 4.2.0 under linux with some hacks applied to the audio
> >library, and the wwv refclock works just as you describe it, not coasting
> >for hours after loss of signal.
> 
> Did you use the echo to set the fragment size also? Are your
> libntp hacks patchified and on a web site somewhere? Fun :)
> 
> >My personal feeling is that while the "coasting" behavior is fine for
> >a standalone non-network-connected DSP WWV decoder, that it probably isn't
> >what we want for a NTP implementation.  IMHO the generic ntpd methods
> >deal just fine with loss of a refclock, and the last thing I want is for
> >a refclock that hasn't heard a real tick in hours to claim that it's
> >still hearing one and is still stratum-0.  Maybe, just *maybe*, a
> >graceful degradation in stratum might be appropriate for some users,
> >but I honestly don't feel that is right either.
> 
> In effect, wwv holdover is substituting the pc's rtxo for
> signal reception. This is kind of similar to one of those
> surplus HP gps cellular systems with a built in ocxo for
> holdover, of course with somewhat more drift (cough).
> 
> Esthetically of course, the gps/ocxo is much sexier than
> a vhf/rtxo setup.
> 
> I think it is perfectly fine to provide the wwv holdover.
> It is the responsibility of the site engineer to decide how
> to integrate such a time source into their brood.
> 
> >Now when WWV starts booming in again and we lock, we may possibly see
> >a step or at least a rapid slew.  This happens, I think, whether we
> >have the old "coasting in the refclock" method or the new "non-coasting
> >refclock".  And if I had my choice, this would be done out of the
> >refclock anyway.
> 
> Yes, humps happen when the clock locks. Not sure what you mean by
> "out of the refclock" though.
> 
> >With all this talk, I hooked my WWV receiver back up last night:
> 
> >bash-2.05a# /usr/local/bin/ntpq -c peers
> >     remote           refid      st t when poll reach   delay   offset  jitter
> >==============================================================================
> >*WWV_AUDIO(0)    .WV15.           0 l   39   64  377    0.000   -0.032   0.007
> >
> >7 microseconds is like a mile... not bad considering that I'm 2000+ miles
> >from Colorado.  If only they would re-activate the transmitter in Greenbelt :-
> >)
> 
> Nice. What kind of receiver/soundcard?
> 
> Last December, I managed to get Hawaii quite well here in California's
> sf bay area, using the old hacked 4.1.73 refclock code:
> 
>      remote           refid      st t when poll reach   delay   offset  jitter
> ==============================================================================
> oPPS(0)          192.58.220.5     1 l   12   16  377    0.000    0.007   0.008
> +WWV_AUDIO(0)    .WH2.            0 l   18   64  377    0.000    0.011   0.016
> 
> That's with an indoor random wire antenna on the Ramsey.
> I live 300ft up in the hills surrounding the bay.
> 
> That code is awesome, Dave. Thanks for all the fun!
> 
> ../Steven
_______________________________________________
hackers mailing list
hackers@ntp.org
http://mailman.ntp.org/mailman/listinfo/hackers
[prev in list] [next in list] [prev in thread] [next in thread]