Re: clock running fast

From: Brooks Davis (brooks_at_one-eyed-alien.net)
Date: 12/30/04

  • Next message: Frank Shute: "Re: how to remote update 4.10 -> 5.3?"
    Date: Thu, 30 Dec 2004 11:32:44 -0800
    To: David Talkington <dtalk@u.washington.edu>
    
    
    

    [Please don't top post].

    On Thu, Dec 30, 2004 at 11:13:55AM -0800, David Talkington wrote:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > Federico Galvez-Durand Besnard wrote:
    >
    > >what do you have in :
    > >/etc/ntp.conf
    >
    > Only:
    >
    > server time.u.washington.edu
    > server 127.127.1.0
    > fudge 127.127.1.0 stratum 10
    >
    >
    > Command line:
    >
    > /usr/sbin/ntpd -c /etc/ntp.conf -p /var/run/ntpd.pid \
    > - -f /var/db/ntpd.drift

    It's generally recommended that you never trust your own clock since
    it's completely crap as time sources go. It's also recommended that you
    use at least 5 time sources to avoid problems with bad clocks.

    -- Brooks

    > >-----BEGIN PGP SIGNED MESSAGE-----
    > >Hash: SHA1
    > >
    > >
    > >Salutations --
    > >
    > >I have an old board with an installation of STABLE whose time keeps
    > >running away. ntpd is not helping. I can manually set the time using
    > >ntpdate, and my ntpq queries look fine, yet the clock persists in running
    > >very fast (seems to be about 1.5x speed). The BIOS clock remains correct,
    > >and the machine therefore has the correct time at each reboot, but quickly
    > >runs away.
    > >
    > >Data points:
    > >
    > >- - I have set kern.timecounter.hardware=TSC, and this has not helped. - -
    > >Two other hosts on the same network, using the same ntp server, do not
    > >have this problem.
    > >- - This box did not display this behavior under FreeBSD 5.2. - - I have
    > >replaced the board on the problem box (with the same age and type), and
    > >the problem persists.
    > >- - dmesg for this machine, an old Dell Optiplex 590, is below.
    > >
    > >What other information might help diagnose the problem?
    > >
    > >Thank you ... -d
    > >
    > >- --
    > >David Talkington
    > >dtalk-ml at prairienet.org
    > ><http://lists.freebsd.org/mailman/listinfo/freebsd-stable>
    > >
    > >
    > >
    > >_______________________________________________
    > >freebsd-stable@freebsd.org mailing list
    > >http://lists.freebsd.org/mailman/listinfo/freebsd-stable
    > >To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
    > >
    > >
    >
    > - --
    > David Talkington
    > Computing and Communications
    > University of Washington
    > 206-543-2144
    > - --
    > dtalk@u.washington.edu
    > - --
    > PGP key: http://staff.washington.edu/dtalk/004B8F8B.asc
    > -----BEGIN PGP SIGNATURE-----
    > Version: GnuPG v1.2.6 (FreeBSD)
    >
    > iD8DBQFB1FN55FKhdwBLj4sRAknTAJ9Wq/I64DpzBoblMmH2JMl2UR08NgCgkLuL
    > qlB7DOSkWlOmR2OLZ32O1NA=
    > =8B5z
    > -----END PGP SIGNATURE-----
    > _______________________________________________
    > freebsd-stable@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
    > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

    -- 
    Any statement of the form "X is the one, true Y" is FALSE.
    PGP fingerprint 655D 519C 26A7 82E7 2529  9BF0 5D8E 8BE9 F238 1AD4
    
    



  • Next message: Frank Shute: "Re: how to remote update 4.10 -> 5.3?"

    Relevant Pages

    • Re: suggestion
      ... Possible time sources for the box are: ... NTP server (optional and configurable: ... local GPS connected to serial line (an alternative to NTP: ... it instead of any sort of cronjob calling ntpdate to step the clock. ...
      (comp.protocols.time.ntp)
    • Re: Two time sources with offset => fails to synchronize
      ... It seems that the Radio clock has 50ms offset compared to the GPS ... time sources is the worst configuration you can have. ... have configured a local GPS clock and 3 external servers then the external ...
      (comp.protocols.time.ntp)
    • Re: clock running fast
      ... > It's generally recommended that you never trust your own clock since ... > it's completely crap as time sources go. ... > use at least 5 time sources to avoid problems with bad clocks. ... the local clock during those times when the configured NTP servers aren't ...
      (freebsd-stable)
    • Re: clock running fast
      ... >> it's completely crap as time sources go. ... > But isn't that what the drift file is for, ... > the local clock during those times when the configured NTP servers aren't ...
      (freebsd-stable)