ntp client software slow - NTP

This is a discussion on ntp client software slow - NTP ; Hi I've installed ntp 4.2.4p0 on an OpenBSD 4.0 box and I'm having some problems: 1. If I run the ntpd binary it, sometimes, doesn't start and doesn't report about problems. When I run it with -d it always works. ...

+ Reply to Thread
Results 1 to 8 of 8

Thread: ntp client software slow

  1. ntp client software slow

    Hi

    I've installed ntp 4.2.4p0 on an OpenBSD 4.0 box and I'm having some
    problems:
    1. If I run the ntpd binary it, sometimes, doesn't start and doesn't
    report about problems. When I run it with -d it always works. If I run
    it with ktrace (strace equivalence) it always works.
    2. running ntp client commands (I tried ntpq and ntpdc), regardless of
    switches, takes a very long time (about 5 minutes). Even if ntpd isn't
    or if I run it with -n (ntpq) switch.
    There aren't any resolution problems on the computer in question.
    Anyone know why this is happening?


    PS - I know that OpenBSD has OpenNTP, and I don't want to start a
    flame war on the history of NTP on OpenBSD and OpenNTP: I have a
    hetrogeneous network with linux and Solaris systems and admins that
    are familiar with the standard NTP.



    TIA
    Paolo


  2. Re: ntp client software slow

    >>> In article <1174280447.034902.274820@l77g2000hsb.googlegroups. com>, "vrkid0@gmail.com" writes:

    vrkid0> Hi I've installed ntp 4.2.4p0 on an OpenBSD 4.0 box and I'm having
    vrkid0> some problems:
    vrkid0> 1. If I run the ntpd binary it, sometimes, doesn't
    vrkid0> start and doesn't report about problems. When I run it with -d it
    vrkid0> always works. If I run it with ktrace (strace equivalence) it always
    vrkid0> works.

    What exactly do you mean by "doesn't start"?

    Just to ask, what does your ntp.conf file look like?

    vrkid0> 2. running ntp client commands (I tried ntpq and ntpdc),
    vrkid0> regardless of switches, takes a very long time (about 5
    vrkid0> minutes). Even if ntpd isn't or if I run it with -n (ntpq) switch.
    vrkid0> There aren't any resolution problems on the computer in question.
    vrkid0> Anyone know why this is happening?

    I suspect a DNS problem on your machine.

    Assuming your machine gets low enough traffic, I have found that when I
    start ntpd with debugging I can watch the ntpq or ntpdc packets arrive and
    the responses get sent back.

    H

  3. Re: ntp client software slow

    Hi

    If it was a resolving issue than the -n switch would have absolved
    me from the problem. We have several Solaris and Linux servers on the
    same subnet with the same resolver (DNS) setup and none of them has
    the same problem.
    I also noticed from my first post that ntpd failed with segmentation
    fault (running it with ntpd with -d) and it's not a hardware issue (as
    other operating system (Linux/Windows) worked on this hardware for
    months without a problem.
    I reduced ntp.conf to the bare minimum (see below) and I'm still
    experiencing the slowness on the openbsd system. Running ntpq -pn from
    another linux (or solaris) server on the same subnet returns a reply
    immediately.



    ntp.conf (reduced to the bare minimum):
    #
    # ntpd configuratoin file
    #
    server 127.127.1.0 # local clock
    fudge 127.127.1.0 stratum 10

    # write drift file
    driftfile /var/ntp/drift

    # broadcast to the lan ntp updates
    broadcast 192.168.19.255

    the full ntp.conf (the configureation includes IP addresses as an
    attempt to see if it's a resolver issue):
    #
    # ntpd configuratoin file
    #
    server 192.114.62.249

    server 127.127.1.0 # local clock
    fudge 127.127.1.0 stratum 10

    # peers:
    peer 192.168.19.11
    peer 192.168.19.12
    peer 192.168.19.25
    peer 192.168.19.50
    peer 192.168.19.51
    peer 192.168.19.52
    peer 192.168.19.100

    # write drift file
    driftfile /var/ntp/drift

    # broadcast to the lan ntp updates
    broadcast 192.168.19.255




    TIA
    Paolo








    On Mar 19, 1:43 am, Harlan Stenn wrote:
    > >>> In article <1174280447.034902.274...@l77g2000hsb.googlegroups. com>, "vrk...@gmail.com" writes:

    >
    > vrkid0> Hi I've installed ntp 4.2.4p0 on an OpenBSD 4.0 box and I'm having
    > vrkid0> some problems:
    > vrkid0> 1. If I run the ntpd binary it, sometimes, doesn't
    > vrkid0> start and doesn't report about problems. When I run it with -d it
    > vrkid0> always works. If I run it with ktrace (strace equivalence) it always
    > vrkid0> works.
    >
    > What exactly do you mean by "doesn't start"?
    >
    > Just to ask, what does your ntp.conf file look like?
    >
    > vrkid0> 2. running ntp client commands (I tried ntpq and ntpdc),
    > vrkid0> regardless of switches, takes a very long time (about 5
    > vrkid0> minutes). Even if ntpd isn't or if I run it with -n (ntpq) switch.
    > vrkid0> There aren't any resolution problems on the computer in question.
    > vrkid0> Anyone know why this is happening?
    >
    > I suspect a DNS problem on your machine.
    >
    > Assuming your machine gets low enough traffic, I have found that when I
    > start ntpd with debugging I can watch the ntpq or ntpdc packets arrive and
    > the responses get sent back.
    >
    > H




  4. Re: ntp client software slow

    Again, what exactly do you mean by "doesn't start"?

    >>> In article <1174285741.649498.183020@e65g2000hsc.googlegroups. com>, "vrkid0@gmail.com" writes:


    vrkid0> Hi If it was a resolving issue than the -n switch would have
    vrkid0> absolved me from the problem.

    Why do you think this would matter?

    vrkid0> We have several Solaris and Linux
    vrkid0> servers on the same subnet with the same resolver (DNS) setup and
    vrkid0> none of them has the same problem.

    That does not mean there is not a problem on this one machine, however.

    vrkid0> I also noticed from my first
    vrkid0> post that ntpd failed with segmentation fault (running it with ntpd
    vrkid0> with -d) and it's not a hardware issue (as other operating system
    vrkid0> (Linux/Windows) worked on this hardware for months without a
    vrkid0> problem.

    Do you still have that core file? If ntpd was compiled with symbols a stack
    backtrace would be useful.

    vrkid0> I reduced ntp.conf to the bare minimum (see below) and I'm
    vrkid0> still experiencing the slowness on the openbsd system.

    By "slowness" you mean the delay before ntpq responds?

    vrkid0> Running ntpq
    vrkid0> -pn from another linux (or solaris) server on the same subnet
    vrkid0> returns a reply immediately.

    To the same server?

    H

  5. Re: ntp client software slow

    Hi


    On Mar 19, 4:53 am, Harlan Stenn wrote:
    > Again, what exactly do you mean by "doesn't start"?
    >
    > >>> In article <1174285741.649498.183...@e65g2000hsc.googlegroups. com>, "vrk...@gmail.com" writes:

    >
    > vrkid0> Hi If it was a resolving issue than the -n switch would have
    > vrkid0> absolved me from the problem.
    >
    > Why do you think this would matter?

    Because the -n switch means forces not to try and resolve the
    addresses and when there is resolving issues on a system using it
    avoid dealing with resolving timeouts.


    >
    > vrkid0> We have several Solaris and Linux
    > vrkid0> servers on the same subnet with the same resolver (DNS) setup and
    > vrkid0> none of them has the same problem.
    >
    > That does not mean there is not a problem on this one machine, however.

    True, but reduces the possibility of resolver issues to almost
    none. There isn't any firewall active on the system. Other software on
    the same system doesn't have resolver issues and works fine. I did
    another test: I changed the system network configuration to aquire
    it's setting from a DHCP server. ntpq still the same thing.


    >
    > vrkid0> I also noticed from my first
    > vrkid0> post that ntpd failed with segmentation fault (running it with ntpd
    > vrkid0> with -d) and it's not a hardware issue (as other operating system
    > vrkid0> (Linux/Windows) worked on this hardware for months without a
    > vrkid0> problem.
    >
    > Do you still have that core file? If ntpd was compiled with symbols a stack
    > backtrace would be useful.

    It's not a core file. It's a system call trace file, I can
    reproduce it if someone is interesting in helping me debug the
    problem.


    >
    > vrkid0> I reduced ntp.conf to the bare minimum (see below) and I'm
    > vrkid0> still experiencing the slowness on the openbsd system.
    >
    > By "slowness" you mean the delay before ntpq responds?

    Yes. 5+ minutes, regardless of ntpd running on or not.

    >
    > vrkid0> Running ntpq
    > vrkid0> -pn from another linux (or solaris) server on the same subnet
    > vrkid0> returns a reply immediately.
    >
    > To the same server?

    Yes to the same OpenBSD server.


    >
    > H






    TIA
    Paolo


  6. Re: ntp client software slow

    >>> In article <1174306564.003252.44160@d57g2000hsg.googlegroups.c om>, "vrkid0@gmail.com" writes:

    vrkid0> Hi
    vrkid0> On Mar 19, 4:53 am, Harlan Stenn wrote:
    >> Again, what exactly do you mean by "doesn't start"?
    >>
    >> >>> In article <1174285741.649498.183...@e65g2000hsc.googlegroups. com>,

    >> "vrk...@gmail.com" writes:
    >>

    vrkid0> Hi If it was a resolving issue than the -n switch would have
    vrkid0> absolved me from the problem.
    >> Why do you think this would matter?

    vrkid0> Because the -n switch means forces not to try and resolve the
    vrkid0> addresses and when there is resolving issues on a system using it
    vrkid0> avoid dealing with resolving timeouts.

    -n means "do not fork". I see nothing in the code about it affecting dns
    resolution.


    vrkid0> We have several Solaris and Linux servers on the same subnet with
    vrkid0> the same resolver (DNS) setup and none of them has the same problem.
    >> That does not mean there is not a problem on this one machine, however.

    vrkid0> True, but reduces the possibility of resolver issues to almost
    vrkid0> none. There isn't any firewall active on the system. Other software
    vrkid0> on the same system doesn't have resolver issues and works fine. I
    vrkid0> did another test: I changed the system network configuration to
    vrkid0> aquire it's setting from a DHCP server. ntpq still the same thing.

    What if this is an issue with the way DNS resolution is configured on the
    machine? That would not be affected by your network setup.

    vrkid0> I also noticed from my first post that ntpd failed with segmentation
    vrkid0> fault (running it with ntpd with -d) and it's not a hardware issue
    vrkid0> (as other operating system (Linux/Windows) worked on this hardware
    vrkid0> for months without a problem.
    >> Do you still have that core file? If ntpd was compiled with symbols a
    >> stack backtrace would be useful.

    vrkid0> It's not a core file. It's a system call trace file, I can
    vrkid0> reproduce it if someone is interesting in helping me debug the
    vrkid0> problem.

    Your call. If you want somebody to successfully help resolve the problem
    you need to provide the information needed to duplicate and analyze the
    problem. And http://bugs.ntp.isc.org is a better for that than this
    newsgroup, and I'm happy to work with you to better identify the problem
    before it makes it to the bugs page.

    vrkid0> I reduced ntp.conf to the bare minimum (see below) and I'm still
    vrkid0> experiencing the slowness on the openbsd system.
    >> By "slowness" you mean the delay before ntpq responds?

    vrkid0> Yes. 5+ minutes, regardless of ntpd running on or not.

    My guess is still DNS resolution issues. You may need to crank debugging
    and/or add debug lines to the code and/or strace (or truss or ...) the code
    to see what it is doing.

    vrkid0> Running ntpq -pn from another linux (or solaris) server on the same
    vrkid0> subnet returns a reply immediately.
    >> To the same server?

    vrkid0> Yes to the same OpenBSD server.

    Then this is still sounding like a DNS resolution problem to me.

    What other possibilities are there?

    H

  7. Re: ntp client software slow

    vrkid0@gmail.com wrote:
    > Hi
    >
    > If it was a resolving issue than the -n switch would have absolved
    > me from the problem. We have several Solaris and Linux servers on the
    > same subnet with the same resolver (DNS) setup and none of them has
    > the same problem.
    > I also noticed from my first post that ntpd failed with segmentation
    > fault (running it with ntpd with -d) and it's not a hardware issue (as
    > other operating system (Linux/Windows) worked on this hardware for
    > months without a problem.
    > I reduced ntp.conf to the bare minimum (see below) and I'm still
    > experiencing the slowness on the openbsd system. Running ntpq -pn from
    > another linux (or solaris) server on the same subnet returns a reply
    > immediately.
    >


    I suspect that your clock is too far off for ntpd to correct and it
    exits. Try running ntpd with the following options: -gN
    The -g allows it to reset your clock even if it exceeds the normal
    threshold. The -N merely lets it run at high priority. Also take a look
    at your drift file. If it exceeds 500 it can also cause you problems.
    This does not look like a DNS problem based on your ntp.conf file.

    Dany

    >
    >
    > ntp.conf (reduced to the bare minimum):
    > #
    > # ntpd configuratoin file
    > #
    > server 127.127.1.0 # local clock
    > fudge 127.127.1.0 stratum 10
    >
    > # write drift file
    > driftfile /var/ntp/drift
    >
    > # broadcast to the lan ntp updates
    > broadcast 192.168.19.255
    >
    > the full ntp.conf (the configureation includes IP addresses as an
    > attempt to see if it's a resolver issue):
    > #
    > # ntpd configuratoin file
    > #
    > server 192.114.62.249
    >
    > server 127.127.1.0 # local clock
    > fudge 127.127.1.0 stratum 10
    >
    > # peers:
    > peer 192.168.19.11
    > peer 192.168.19.12
    > peer 192.168.19.25
    > peer 192.168.19.50
    > peer 192.168.19.51
    > peer 192.168.19.52
    > peer 192.168.19.100
    >
    > # write drift file
    > driftfile /var/ntp/drift
    >
    > # broadcast to the lan ntp updates
    > broadcast 192.168.19.255

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


  8. Re: ntp client software slow

    vrkid0@gmail.com wrote:
    >> By "slowness" you mean the delay before ntpq responds?

    > Yes. 5+ minutes, regardless of ntpd running on or not.


    It is possible that there is a DNS problem but it's hard to know. There
    was a recent bug fix related to DNS lookups translating IP addresses to
    names. It may not be your problem but it's worth testing. Try the
    ntp-dev 4.2.4p16 build and see if that makes a difference. Otherwise I'd
    look at the outgoing and incoming packets using Wireshark (Ethereal) for
    both DNS and NTP.

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


+ Reply to Thread