[ntp:questions] Stuck at stratum 16

[David Woolley]

Charles Leeds wrote:
> I cannot seem to get my server to out of stratum 16.  Are offsets and 
> jitters over 1000 common?  Is the offset and jitter in milliseconds?
> 
> I've let it sit for an hour and it makes no difference.  It is still at 
> stratum 16. 
> 

> 
> assID=0 status=c035 sync_alarm, sync_unspec, 3 events, event_clock_reset,

This and the reachability figures indicate that the clock has recently 
stepped.

> offset=0.000, frequency=-3.972, jitter=80.189, noise=0.001,

Frequency <> 0 indicates that at some time the system has been 
synchronized (possibly in a previous run).

> stability=0.000, tai=0
>      remote           refid      st t when poll reach   delay   offset  
> jitter
> ==============================================================================
>  slice-gw.warnet 18.26.4.105      2 u   49   64   17   32.101  3176.46 
> 2139.56

Reachability 17 indicates that the last time reset was about 4 poll 
intervals ago, which looks like about five minutes ago.

>  unlawful.id.au  129.6.15.28      2 u   19   64   17   64.230  1662.04 
> 1386.83
>  tesla.fireduck. 63.192.96.10     2 u   16   64   17   24.210  753.143 
> 2096.85
>  server1-a.your. 64.202.112.75    2 u   13   64   17   22.021  1804.17 
> 1369.11

These offsets are all over the place.  With delays in this range, you 
would expect the offsets to be within a few 10s of milliseconds of each 
other.  Something is badly wrong here.  Although you haven't run rv on 
the individual associations, to get their root delays, I think it is 
very likely that no two clocks have overlapping error bands, so they are 
all being rejected as falsetickers.

Even if you assume the offsets are proportional to age, which you might 
get if the clock frequency was completely broken, they are still all 
over the place

>  leconte.local   .STEP.          16 u    -   64    0    0.000    0.000   
> 0.000
> 

I hope this isn't the subject machine itself; that would indicate that 
you had probably broken the loop detection.  Otherwise, it is in similar 
difficulties.

> 
> 
> # Fudging if outside servers are down
> server 10.2.5.10
> fudge 10.2.5.10 stratum 10

Fudge is ineffective here, only reference clocks can be fudged.  In any 
case, that server seems to have its own problems.

> 
> #fudge 10.2.5.10 stratum 5
> broadcastdelay 0.008