Minimal system - NTP

This is a discussion on Minimal system - NTP ; David, In the latest NTPd the leap bits and stratum will get updated at the first time update from the server. So theoretically there shouldn't be any discrepancy between ntpdc and ntpq outputs? BTW, I'm using a tarball with following ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 27 of 27

Thread: Minimal system

  1. RE: ntpdc 'sysinfo' output inconsistent withntpq-poutput

    David,

    In the latest NTPd the leap bits and stratum will get updated at the
    first time update from the server. So theoretically there shouldn't be
    any discrepancy between ntpdc and ntpq outputs?

    BTW, I'm using a tarball with following version/timestamp :
    ntp-stable-4.2.0a-20050816.

    Should the below mentioned change be there in this?

    Thankyou,
    Anurag

    -----Original Message-----
    From: questions-bounces@lists.ntp.isc.org
    [mailto:questions-bounces@lists.ntp.isc.org] On Behalf Of David L. Mills
    Sent: Wednesday, July 26, 2006 12:29 AM
    To: questions@lists.ntp.isc.org
    Subject: Re: ntpdc 'sysinfo' output inconsistent with
    ntpq-poutput

    Richard,

    At cold start (no frequency file) the daemon sets the clock at the first

    update, then waits 15 minutes, measures and corrects the frequency
    (usually within 1 PPM) and assumes normal operation. This saves many
    hours to converge the frequency within 1 PPM, especially if the
    intrinsic frequency error is large, like 200 PPM.

    Until the frequency is corrected, the machine can have serious offset
    and frequency errors that would drive dependent clients nuts. Up to now,

    the leap bits and stratum were not initialized until the frequency was
    corrected. However, the clock was set and local clients were free to
    believe or not believe the clock. After review, the external behavior is

    only mildly worse than without the initial training period, so the leap
    bits and stratum are now set at the first update. The billboards should
    now be consistent with the Principle of Least Astonishment..


    Having revealed thus, the billboards on both ntpq and ntpdc should be
    the same, since they are derived from the same data. However, ntpdc has
    not been properly maintained for many years and there could well be bugs

    in that program. If ntpq and ntpdc disagree, use ntpq.

    If the kernel discipline is available and the frequency file is not
    present, the kernel offset and frequency should be set to zero (ntptime
    -o 0 -f 0) first. This is the approved way to restart from scratch.

    Dave

    Richard B. Gilbert wrote:
    > Tripathi, Anurag wrote:
    >
    >> Here is ntpq -crv output: ----
    >> assID=0 status=c624 sync_alarm, sync_ntp, 2 events,
    >> event_peer/strat_chg,
    >> version="ntpd 4.2.0a"?, processor="i686",
    >> system="Linux/2.6.13.4-ws-symbol", leap=11, stratum=16,

    precision=-20,
    >> rootdelay=0.000, rootdispersion=10.965, peer=17460, refid=INIT,
    >> reftime=00000000.00000000 Thu, Feb 7 2036 11:58:16.000, poll=6,
    >> clock=0xc86f5eb1.a257a786, state=3, offset=9.887, frequency=0.000,
    >> noise=3.628, jitter=2.328, stability=0.000
    >> ------
    >>
    >> As suggested earlier after 30mins 'ntpdc sysinfo' starts showing the
    >> correct information i.e. 'synched'.
    >> But isn't 30mins too long a delay for show an information which ntpq
    >> declares within seconds?
    >> More importantly is there anyway I can reduce/minimize this time lag?
    >> (some keyword or configuration?)
    >>
    >> This would be helpful!
    >>
    >> Regards,
    >> Anurag
    >>
    >> Other requested info:
    >> Ntpq version: "ntpq 4.2.0a@1.1196-r Thu Mar 16 13:07:10 IST 2006 (1)"
    >> Ntpdc version: "ntpdc 4.2.0a@1.1196-r Thu Mar 16 13:07:07 IST 2006

    (1)"
    >>

    >
    > Ntpd can select a synchronization source very quickly, especially if

    you
    > use "iburst" on your server lines in ntp.conf.
    >
    > It can take far longer for ntpd to bring your local clock into close
    > agreement with UTC where "close" means < 20 milliseconds.
    >
    > You can reduce the time required by using the -g option when you start


    > ntpd. That will cause ntpd to set the clock unconditionally to
    > something close to the correct time. Ntpd will still require some

    time
    > to adjust the speed of your local clock so that it neither gains nor
    > loses time.
    >
    > A "cold" start (no drift file) of ntpd can take many hours to reach a
    > stable state with both the correct time and the correct frequency
    > adjustment. A warm start is faster but can still require twenty or
    > thirty minutes to beat your local clock into submission. :-)
    >
    > You can probably see similar results from ntpq and ntpdc in far less
    > time than thirty minutes. As nearly as we could tell, you had allowed


    > less than two minutes since startup.


    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions

    __________________________________________________ ______________________
    This email has been scanned for computer viruses.

    __________________________________________________ ______________________
    This email has been scanned for computer viruses.
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  2. Re: ntpdc 'sysinfo' output inconsistent with ntpq-p output

    On Tue, 25 Jul 2006 16:57:27 +0200,
    Jan Ceuleers wrote:

    > Note that the IP address of the current sys_peer is 213.222.11.222
    > (which is what gets output in binary as the refid).
    >
    > One more data point: here is the output of 'ntpq -p -c rv localhost'
    > which ntptrace turned into the above output:
    >
    > assID=0 status=06f4 leap_none, sync_ntp, 15 events, event_peer/strat_chg,
    > version="ntpd 4.2.2p1@1.1570-o Sun Jul 9 11:18:35 UTC 2006 (1)",
    > processor="i686", system="Linux/2.4.20-28.7", leap=00, stratum=1,
    > precision=-20, rootdelay=0.000, rootdispersion=451.539, peer=63864,
    > refid=
    > , reftime=c870ad28.383ed848 Tue, Jul 25 2006 16:46:00.219,
    > poll=10, clock=c870ae8d.6d58d599 Tue, Jul 25 2006 16:51:57.427,
    > state=4, offset=0.497, frequency=6.306, jitter=3.058, noise=2.836,
    > stability=0.003, tai=0
    >
    > So: this problem is not caused by ntptrace; the incorrect refid, stratum
    > etc. are already shown by the ntpq -n -c rv output.


    It's not a problem with ntpq either, looking at that. If ntpd is
    reporting itself as stratum-1, the refid should be the text tag of
    its refclock. If ntpd has switched sys_peer from the refclock to
    a server, it shouldn't be reporting itself as stratum-1 ...

    --
    Ronan Flood
    working for but not speaking for
    Network Services, University of London Computer Centre
    (which means: don't bother ULCC if I've said something you don't like)

  3. Re: ntpdc 'sysinfo' output inconsistent with ntpq-p output

    Harlan,

    Harlan Stenn wrote:
    > There is no maintainer for ntptrace, so bugs get fixed there when somebody
    > feels like working on it.


    This is worring: you do not seem to have caught on to the fact that this
    issue is caused by ntpq -n -c rv being inconsistent with ntpq -p.

    Let me say that again: ntpq is inconsistent with ntpq.

    The ntptrace issue is just a symptom.

    I suspect that this is another form of the problem mentioned in the
    subject of this thread.

    > The "default" maintainer is me, and I have over 100 bugs in my queue.
    > I work on the bugs that are blocking the "upcoming" release when I am not
    > working on release issues. And I'm still a volunteer and do this work in my
    > spare time.


    Thank you (x1000). Really!

    But this is also worrying: from what you say the ntpd project is in a
    constant state of fire-fighting. Releases are driven by a lack of
    blocking issues, rather than by a vision of what new or improved
    functionality is needed that outweighs the risks of deployment.

    I would call upon the ICT industry to lend a hand, since time
    synchronisation is, frankly, too important to the industry to be left to
    volunteers who are very understandably forced to compromise.

    My employer is a bit busy merging right now, or I'd try and get some
    support going. Has anyone tried talking to industry federations?

    Cheers, Jan

  4. Re: ntpdc 'sysinfo' output inconsistent with ntpq-p output

    I was responding to an item in that thread that discussed ntptrace.

    At least, I thought so...

    As for the ntodc sysinfo v. ntpq -p issue, I thought I carefully described
    my observation of one of the detailed reports earlier - in that case ntpq
    was reporting it was sync'd to the remote server but it was still in state
    3, and the sysinfo command showed that the local machine was not yet sync'd.

    H

  5. Re: ntpdc 'sysinfo' output inconsistent with ntpq-p output

    On 28 Jul 2006 13:22:17 GMT, I wrote:

    > Jan Ceuleers wrote:
    >
    > > So: this problem is not caused by ntptrace; the incorrect refid, stratum
    > > etc. are already shown by the ntpq -n -c rv output.

    >
    > It's not a problem with ntpq either, looking at that. If ntpd is
    > reporting itself as stratum-1, the refid should be the text tag of
    > its refclock. If ntpd has switched sys_peer from the refclock to
    > a server, it shouldn't be reporting itself as stratum-1 ...


    I can confirm this problem with ntpd-4.2.2, as I'm seeing this on one of
    our GPS receivers which is having intermittent reception at the moment.
    Here are ntpq -np outputs I happen to have logged from one of its peers
    at consecutive two-minute intervals this morning:

    remote refid st t when poll reach delay offset jitter

    +193.62.22.74 .GPS. 1 u 20 64 377 5.780 0.087 0.055

    -193.62.22.74 .>^Vb. 1 u 12 64 377 5.780 0.087 0.043

    +193.62.22.74 .>^Vb. 1 u 2 64 377 5.834 0.049 0.031

    -193.62.22.74 192.36.134.17 2 u 57 64 376 5.834 0.049 0.044

    (>^Vb is textified ASCII of 193.62.22.98, another peer)

    Time to log a bug?

    --
    Ronan Flood
    working for but not speaking for
    Network Services, University of London Computer Centre
    (which means: don't bother ULCC if I've said something you don't like)

  6. Re: ntpdc 'sysinfo' output inconsistent withntpq-p output

    Ronan Flood wrote:
    > On 28 Jul 2006 13:22:17 GMT, I wrote:
    >
    >> Jan Ceuleers wrote:
    >>
    >>> So: this problem is not caused by ntptrace; the incorrect refid, stratum
    >>> etc. are already shown by the ntpq -n -c rv output.

    >> It's not a problem with ntpq either, looking at that. If ntpd is
    >> reporting itself as stratum-1, the refid should be the text tag of
    >> its refclock. If ntpd has switched sys_peer from the refclock to
    >> a server, it shouldn't be reporting itself as stratum-1 ...

    >
    > I can confirm this problem with ntpd-4.2.2, as I'm seeing this on one of
    > our GPS receivers which is having intermittent reception at the moment.
    > Here are ntpq -np outputs I happen to have logged from one of its peers
    > at consecutive two-minute intervals this morning:
    >
    > remote refid st t when poll reach delay offset jitter
    >
    > +193.62.22.74 .GPS. 1 u 20 64 377 5.780 0.087 0.055
    >
    > -193.62.22.74 .>^Vb. 1 u 12 64 377 5.780 0.087 0.043
    >
    > +193.62.22.74 .>^Vb. 1 u 2 64 377 5.834 0.049 0.031
    >
    > -193.62.22.74 192.36.134.17 2 u 57 64 376 5.834 0.049 0.044
    >
    > (>^Vb is textified ASCII of 193.62.22.98, another peer)
    >
    > Time to log a bug?
    >


    Yes, but what does the configuration file look like and why are all
    those server addresses the same?

    Danny
    _______________________________________________
    questions mailing list
    questions@lists.ntp.isc.org
    https://lists.ntp.isc.org/mailman/listinfo/questions


  7. Re: ntpdc 'sysinfo' output inconsistent withntpq-p output

    mayer@ntp.isc.org (Danny Mayer) wrote:

    > > I can confirm this problem with ntpd-4.2.2, as I'm seeing this on one of
    > > our GPS receivers which is having intermittent reception at the moment.
    > > Here are ntpq -np outputs I happen to have logged from one of its peers
    > > at consecutive two-minute intervals this morning:
    > >
    > > remote refid st t when poll reach delay offset jitter
    > >
    > > +193.62.22.74 .GPS. 1 u 20 64 377 5.780 0.087 0.055
    > >
    > > -193.62.22.74 .>^Vb. 1 u 12 64 377 5.780 0.087 0.043
    > >
    > > +193.62.22.74 .>^Vb. 1 u 2 64 377 5.834 0.049 0.031
    > >
    > > -193.62.22.74 192.36.134.17 2 u 57 64 376 5.834 0.049 0.044
    > >
    > > (>^Vb is textified ASCII of 193.62.22.98, another peer)
    > >
    > > Time to log a bug?

    >
    > Yes, but what does the configuration file look like and why are all
    > those server addresses the same?


    I picked the same line from four separate ntpq -np outputs, which were
    taken at two-minute intervals, to show how the refid was changed to an
    IP address but stratum was still 1, for a short period. I compressed
    the output to show just the relevant part.

    The ntp.conf for 193.62.22.74 proceeds as follows:

    server 127.127.8.0 mode 7 minpoll 4 prefer iburst
    fudge 127.127.8.0 time1 0.029

    peer 128.86.8.123
    peer 193.62.22.98
    peer 193.62.22.90
    peer 193.62.22.82

    server ntp0.linx.net
    server ntp1.linx.net
    peer ntp2.usno.navy.mil
    server ntp2.sp.se
    server ntp1.mmo.netnod.se

    driftfile /usr/local/etc/ntp.drift
    enable monitor

    restrict 127.0.0.0 mask 255.0.0.0
    restrict ::1 mask ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff
    restrict -4 default nomodify nopeer notrap limited
    restrict -6 default nomodify nopeer notrap limited

    restrict 128.86.8.0 mask 255.255.255.0 nomodify notrap
    restrict 193.62.22.82 mask 255.255.255.255 nomodify notrap
    restrict 193.62.22.98 mask 255.255.255.255 nomodify notrap
    restrict 193.62.22.90 mask 255.255.255.255 nomodify notrap

    # swathe of other restricts

    --
    Ronan Flood
    working for but not speaking for
    Network Services, University of London Computer Centre
    (which means: don't bother ULCC if I've said something you don't like)

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2