Minimal system - NTP

This is a discussion on Minimal system - NTP ; What's the minimum x86 computer to adequately run freeBSD to set up as an NTP server? Keith _______________________________________________ questions mailing list questions@lists.ntp.isc.org https://lists.ntp.isc.org/mailman/listinfo/questions...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 27

Thread: Minimal system

  1. Minimal system

    What's the minimum x86 computer to adequately run freeBSD to set up as an
    NTP server?

    Keith

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


  2. Re: Minimal system

    Keith E. Brandt, M.D. wrote:
    > What's the minimum x86 computer to adequately run freeBSD to set up as
    > an NTP server?


    The smallest you can find that still works! :-)

    Actually, you probably want at least a Pentium-60 just so the OS will
    have RDTSC available, but you can make do with a 486 as well, you just
    have to use a slightly older kernel afaik.

    My Stratum-1 Motorola Oncore UT+ was running off a Pentium-133 for many
    years, delivering sub-us performance most of the time. The current
    Pentium-II/Pentium-III boxes are less stable. :-(

    Terje

    --
    -
    "almost all programming can be viewed as an exercise in caching"

  3. Re: Minimal system

    Keith E. Brandt, M.D. wrote:
    > What's the minimum x86 computer to adequately run freeBSD to set up
    > as an NTP server?
    >
    > Keith



    http://www.david-taylor.myby.co.uk/n...SD-GPS-PPS.htm

    I used the oldest I had to hand - 133MHz, 48MB, 10GB. It was very slow (5
    hours) rebuilding the kernel, but apart from that works well (when it can
    see enough satellites - worse now in the summer that the trees have
    leaves....).

    David



  4. Re: Minimal system

    I used a 486/33 for many years...

    H

  5. Re: Minimal system

    Keith E. Brandt, M.D. wrote:

    > What's the minimum x86 computer to adequately run freeBSD to set up as
    > an NTP server?
    >
    > Keith
    >
    > _______________________________________________
    > questions mailing list
    > questions@lists.ntp.isc.org
    > https://lists.ntp.isc.org/mailman/listinfo/questions
    >


    Well Poul Henning Kemp runs NTP servers on Soekris single board
    computers with the O/S and ntpd in PROM. That's pretty minimal and
    probably less than you want.

    I would expect a 133 MHz Pentium (7 - 8 years old now) to handle it.

    If you're not too proud to be a trash picker, simply grab the next
    machine you see at curb side that has not been stripped.

  6. ntpdc 'sysinfo' output inconsistent with ntpq -poutput

    Hi,

    I'm running ntpd version 4.2 on my linux M/C, I'm synching my m/c to a
    well known timer server 'clock.redhat.com' (without any authentication
    configured).
    After a while when I query the system with ntpq it shows synchronized,
    while the ntpdc 'sysinfo' output still shows the system on stratum '16'
    and system unsynched.

    Isn't this contradictory?

    What can I do to get the sysinfo output show the correct info?

    Ntpq / ntpdc outputs are given below:

    Linux#ntpq -p
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ======================
    ====
    *clock1.redhat.c .CDMA. 1 u 54 64 3 292.993 0.468
    76.733

    Linux#ntpdc> sysinfo
    system peer: clock1.redhat.com
    system peer mode: client
    leap indicator: 11
    stratum: 16
    precision: -20
    root distance: 0.00000 s
    root dispersion: 0.00433 s
    reference ID: [73.78.73.84]
    reference time: 00000000.00000000 Thu, Feb 7 2036 11:58:16.000
    system flags: auth monitor ntp kernel stats
    jitter: 0.083237 s
    stability: 0.000 ppm
    broadcastdelay: 0.003998 s
    authdelay: 0.000000 s

    My ntp.conf file is:
    -----------
    #system ntp configuration file
    server clock.redhat.com iburst

    # Drift file
    driftfile /var/etc/ntp/drift

    # Keys file.
    keys /var/etc/ntp/keys
    -----------

    Any insight into this situation will be very helpful.

    Thanks in advance,
    Anurag

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


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

    Tripathi, Anurag wrote:

    > Hi,
    >
    > I'm running ntpd version 4.2 on my linux M/C, I'm synching my m/c to a
    > well known timer server 'clock.redhat.com' (without any authentication
    > configured).
    > After a while when I query the system with ntpq it shows synchronized,
    > while the ntpdc 'sysinfo' output still shows the system on stratum '16'
    > and system unsynched.
    >
    > Isn't this contradictory?
    >
    > What can I do to get the sysinfo output show the correct info?
    >
    > Ntpq / ntpdc outputs are given below:
    >
    > Linux#ntpq -p
    > remote refid st t when poll reach delay offset
    > jitter
    > ================================================== ======================
    > ====
    > *clock1.redhat.c .CDMA. 1 u 54 64 3 292.993 0.468
    > 76.733
    >
    > Linux#ntpdc> sysinfo
    > system peer: clock1.redhat.com
    > system peer mode: client
    > leap indicator: 11
    > stratum: 16
    > precision: -20
    > root distance: 0.00000 s
    > root dispersion: 0.00433 s
    > reference ID: [73.78.73.84]
    > reference time: 00000000.00000000 Thu, Feb 7 2036 11:58:16.000
    > system flags: auth monitor ntp kernel stats
    > jitter: 0.083237 s
    > stability: 0.000 ppm
    > broadcastdelay: 0.003998 s
    > authdelay: 0.000000 s
    >
    > My ntp.conf file is:
    > -----------
    > #system ntp configuration file
    > server clock.redhat.com iburst
    >
    > # Drift file
    > driftfile /var/etc/ntp/drift
    >
    > # Keys file.
    > keys /var/etc/ntp/keys
    > -----------
    >
    > Any insight into this situation will be very helpful.


    First, you appear to have been running ntpd for only a minute or two.
    You have received only two packets from your server (reach field = 3)!
    You need to wait a few minutes after starting ntpd before you can get
    very much useful data from ntpq or ntpdc. When the reach field shows
    377 that will tell us that your server has responded to the last eight
    requests.

    Show us the output of ntpq and ntpdc after ntpd has been running for
    thirty to sixty minutes. You might also show us the output of
    ntpq -c version
    so that we will know what version of ntpd you are running.

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

    I'm not so sure about that.

    He's using iburst, so he probably got sync'd during the initial exchange.

    I do not understand the discrepancy between the ntpq output and the ntpdc
    sysinfo output, but I really haven't thought about it all that much.

    Version strings all around would be useful (ntpd, ntpq, ntpdc).

    H

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

    Harlan Stenn wrote:

    > I'm not so sure about that.
    >
    > He's using iburst, so he probably got sync'd during the initial exchange.
    >
    > I do not understand the discrepancy between the ntpq output and the ntpdc
    > sysinfo output, but I really haven't thought about it all that much.
    >
    > Version strings all around would be useful (ntpd, ntpq, ntpdc).
    >
    > H


    I still think that he could make a more convincing case that something
    is wrong, or see that things are really okay, by running ntpd for thirty
    minutes or more.

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

    On Sat, 22 Jul 2006 18:33:57 +0000, Harlan Stenn wrote:

    > He's using iburst, so he probably got sync'd during the initial exchange.
    >
    > I do not understand the discrepancy between the ntpq output and the ntpdc
    > sysinfo output, but I really haven't thought about it all that much.


    I think what happens is that iburst allows ntpd quickly to sync to
    a source, but as noticed it doesn't remember the responses in the
    reach status, and doesn't declare itself synced to its clients until
    it has received the usual normal responses later.

    I think "ntpq -crv" would show similar info to ntpdc sysinfo in this
    state.

    --
    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)

  11. RE: ntpdc 'sysinfo' output inconsistent withntpq-p output

    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)"



    -----Original Message-----
    From: questions-bounces@lists.ntp.isc.org
    [mailto:questions-bounces@lists.ntp.isc.org] On Behalf Of Ronan Flood
    Sent: Monday, July 24, 2006 5:28 PM
    To: questions@lists.ntp.isc.org
    Subject: Re: ntpdc 'sysinfo' output inconsistent with
    ntpq-p output

    On Sat, 22 Jul 2006 18:33:57 +0000, Harlan Stenn
    wrote:

    > He's using iburst, so he probably got sync'd during the initial

    exchange.
    >
    > I do not understand the discrepancy between the ntpq output and the

    ntpdc
    > sysinfo output, but I really haven't thought about it all that much.


    I think what happens is that iburst allows ntpd quickly to sync to
    a source, but as noticed it doesn't remember the responses in the
    reach status, and doesn't declare itself synced to its clients until
    it has received the usual normal responses later.

    I think "ntpq -crv" would show similar info to ntpdc sysinfo in this
    state.

    --
    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)

    _______________________________________________
    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


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

    Tripathi, Anurag wrote:
    > 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?)


    Just to avoid it being missed: a similar issue exists with ntptrace,
    which is a perl script that relies on ntpq -n -c rv being consistent
    across the trace.

    An example of the contrary:

    # ntptrace localhost ; ntpq -p localhost
    localhost: stratum 1, offset 0.000087, synch distance 0.461839, refid '
    '
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    LOCAL(0) .LOCL. 10 l 52 64 377 0.000 0.000
    0.001
    GENERIC(0) .DCFa. 0 l 976 64 0 0.000 -2.266
    0.001
    +cerber.obs.coe. 145.238.110.68 3 u 386 1024 377 67.058 0.866
    0.244
    *chronos.zedat.f .GPS. 1 u 363 1024 377 31.280 0.905
    0.440
    -salukes.opensou 185.55.101.136 2 u 324 1024 377 14.834 2.596
    1.284
    -217.71.122.144 80.190.252.238 3 u 327 1024 377 15.051 -4.640
    3.759
    +ntp1.belbone.be 195.13.23.250 2 u 337 1024 377 10.421 1.627
    0.385
    -time.ijs.si 193.2.4.2 2 u 331 1024 377 50.810 0.121
    0.045
    -bear.zoo.bt.co. 194.81.227.227 2 u 327 1024 375 23.634 5.755
    1.546
    skr03.xperim.be 192.168.1.1 2 u 379 1024 377 0.760 -3.400
    5.686


    This shows that ntptrace (and hence ntpq -n -c rv localhost) is
    inconsistent with ntpq -p localhost. This is perfectly reproduceable on
    my system. Note that in this case the refclock has last produced a valid
    sample 976 seconds ago.

    Note also that this issue causes ntptrace to incorrectly output the
    refid. In this particular case what is output seems to be a line feed,
    but sometimes it's a bit messier than that (e.g. Ctrl-E, causing my ssh
    client to output its ID string (PuTTY)).

    Cheers, Jan

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

    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.

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

    we could use a maintainer for ntptrace...

    H

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

    >>> In article , Anurag.Tripathi@symbol.com (Tripathi, Anurag) writes:

    Anurag> Here is ntpq -crv output: ---- assID=0 status=c624 sync_alarm,
    Anurag> sync_ntp, 2 events, event_peer/strat_chg, version="ntpd 4.2.0a"?,
    Anurag> processor="i686", system="Linux/2.6.13.4-ws-symbol", leap=11,
    Anurag> stratum=16, precision=-20, rootdelay=0.000, rootdispersion=10.965,
    Anurag> peer=17460, refid=INIT, reftime=00000000.00000000 Thu, Feb 7 2036
    Anurag> 11:58:16.000, poll=6, clock=0xc86f5eb1.a257a786, state=3,
    Anurag> offset=9.887, frequency=0.000, noise=3.628, jitter=2.328,
    Anurag> stability=0.000 ------

    You are in state 3, which means you are not sync'd. Therefore, in this
    case, ntpdc seems to be stating correct info.

    Just because ntpq shows that you are sync'd to the remote system does not
    mean that your ntpd is ready to announce to other systems that it is stable.

    Anurag> As suggested earlier after 30mins 'ntpdc sysinfo' starts showing the
    Anurag> correct information i.e. 'synched'.

    By this time I bet ntpq -crv will show that your ntpd is in state 4, which
    is sync'd.

    Anurag> But isn't 30mins too long a delay for show an information which ntpq
    Anurag> declares within seconds?

    Just to be thorough, I believe you are seeing the difference between "ntpd
    is not in state 4 but knows who to believe" and "ntpd is in state 4 and
    knows who to believe".

    H

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

    Jan Ceuleers wrote:
    >
    > Note also that this issue causes ntptrace to incorrectly output the
    > refid. In this particular case what is output seems to be a line feed,
    > but sometimes it's a bit messier than that (e.g. Ctrl-E, causing my ssh
    > client to output its ID string (PuTTY)).
    >


    Jan,

    Which line is the incorrect refid?

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


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

    Danny Mayer wrote:
    > Jan,
    >
    > Which line is the incorrect refid?
    >
    > Danny



    Danny,

    Referring back to the example in my earlier message, the following was
    the only line output by 'ntptrace localhost' (because it thought that
    localhost was at stratum 1 and therefore synchronised to its refclock):

    localhost: stratum 1, offset 0.000087, synch distance 0.461839, refid '
    '

    The refid is supposed to be displayed in single quotes, which here seems
    to be an LF (newline). It displays like that even in an 80-column
    window; this is not a result of newsgroup word-wrapping.

    This shows that the ntpq -n -c rv output had not yet caught on to the
    fact that the refclock had not yielded a valid sample for 976 seconds
    and that another server has been selected as the syspeer:

    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    LOCAL(0) .LOCL. 10 l 52 64 377 0.000 0.000
    0.001
    GENERIC(0) .DCFa. 0 l 976 64 0 0.000 -2.266
    0.001
    +cerber.obs.coe. 145.238.110.68 3 u 386 1024 377 67.058 0.866
    0.244
    *chronos.zedat.f .GPS. 1 u 363 1024 377 31.280 0.905
    0.440
    -salukes.opensou 185.55.101.136 2 u 324 1024 377 14.834 2.596
    1.284
    -217.71.122.144 80.190.252.238 3 u 327 1024 377 15.051 -4.640
    3.759
    +ntp1.belbone.be 195.13.23.250 2 u 337 1024 377 10.421 1.627
    0.385
    -time.ijs.si 193.2.4.2 2 u 331 1024 377 50.810 0.121
    0.045
    -bear.zoo.bt.co. 194.81.227.227 2 u 327 1024 375 23.634 5.755
    1.546
    skr03.xperim.be 192.168.1.1 2 u 379 1024 377 0.760 -3.400
    5.686


    As I said, this is reproduceable. I've just run the same couple of
    commands again (ntptrace localhost; ntpq -p localhost) and this is the
    output:

    localhost: stratum 1, offset 0.000497, synch distance 0.449679, refid '
    '
    remote refid st t when poll reach delay offset
    jitter
    ================================================== ============================
    LOCAL(0) .LOCL. 10 l 24 64 377 0.000 0.000
    0.001
    GENERIC(0) .DCFa. 0 l 113 64 164 0.000 1262304
    1262304
    -roxane.home-dn. 130.149.17.8 2 u 779 1024 377 13.128 4.907
    1.264
    -195.244.96.13 235.190.183.255 2 u 924 1024 377 17.820 40.431
    20.218
    *n3.surbl.org 193.0.4.7 2 u 787 1024 377 10.977 1.743
    2.962
    -host-213-189-18 98.221.144.0 2 u 778 1024 377 13.678 17.895
    10.933
    +tilia.zsx.hu 192.53.103.108 2 u 774 1024 377 36.650 0.513
    0.541
    -ntp1.belbone.be 195.13.23.250 2 u 770 1024 377 9.894 2.941
    2.934
    -time.ijs.si 193.2.4.2 2 u 780 1024 377 50.661 4.039
    1.605
    +bear.zoo.bt.co. 130.149.17.8 2 u 789 1024 377 24.860 0.708
    2.960
    -skr03.xperim.be 192.168.15.6 5 u 779 1024 377 0.741 -19.073
    58.959

    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.

    Hope this helps.

    Jan

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

    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.


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

    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.


    Does anyone else experience this behaviour? I thought reporting it here
    would cause it not to be missed (along with the original problem
    reported by Tripathi Anurag). This thread appears to be petering out
    without any unequivocal statements on this...

    I don't want to open a bug report unless this really is a bug, rather
    than an artefact of my particular system (but I will if asked).

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

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

    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.

    H

+ Reply to Thread
Page 1 of 2 1 2 LastLast