[RndTbl] system loses time

[Trevor Cordes]

I have another system (not the same one with RTC problems).  It loses 
about 1s every 1m in system time!!  ntp is running, configured the same 
way I have 20 other boxes that work just fine.

Right now the system thinks it's 6:38pm when the actual time is 20:14pm.  
It lost that much time since I last ntpdate'd Dec 7!

ntpq shows some weird values:

#ntpq
ntpq> lpeers
     remote           refid      st t when poll reach   delay   offset jitter
==============================================================================
 ntp1.sscgateway 209.87.233.53    3 u    5   64  377   46.645  5757133 6180.03
 time.netspectru 132.246.11.228   3 u   62   64  377   40.248  5755927 6235.07
 backup.relay.mt 132.246.11.227   3 u   14   64  377   40.161  5756937 6165.72
 74.3.161.36     140.142.16.34    2 u   46   64  377   49.971  5756303 6236.14

However, the above indicates ntp is finding peers that it can sync with.

The last message in /v/l/m about ntp is from the restart:

Dec  7 14:38:32 firewall ntpd[25512]: peers refreshed
Dec  7 14:38:32 firewall ntpd[25512]: Listening on routing socket on fd #26 for interface updates
Dec  7 14:38:33 firewall ntpd[25512]: format error frequency file /var/lib/ntp/drift
Dec  7 14:38:33 firewall ntpd[25512]: 0.0.0.0 c016 06 restart
Dec  7 14:38:33 firewall ntpd[25512]: 0.0.0.0 c012 02 freq_set kernel 0.000 PPM
Dec  7 14:38:33 firewall ntpd[25512]: 0.0.0.0 c011 01 freq_not_set
Dec  7 14:38:39 firewall ntpd[25512]: 0.0.0.0 c61c 0c clock_step +5.921205 s
Dec  7 14:38:45 firewall ntpd[25512]: 0.0.0.0 c614 04 freq_mode
Dec  7 14:38:46 firewall ntpd[25512]: 0.0.0.0 c618 08 no_sys_peer
Dec  7 14:42:07 firewall ntpd[25512]: 0.0.0.0 c628 08 no_sys_peer

This seems to match up with what my other systems look like.  Though the 
kernel 0.000 PPM is a bit weird.  no_sys_peer seems entirely normal though 
it sounds bad.

I also don't get why ntp isn't barfing out like it normally does after it 
goes out more than 1000s.

Any ideas on a) fixes for this board losing time, and b) having ntp do 
what it's supposed to.

I have wiped out the /v/l/ntp/drift file as a precaution that maybe the 
drift was wrong (it was leftover from a previous board).  Ntp doesn't seem 
to be updating this file anymore, and I have verified it's ntp:ntp 644.

In all my years I've never seen such a chronically chronologically 
challenged chronometer.