Re: 1 Machine, 2 NICs, 2 Instances of ntpd;Possible? - NTP

This is a discussion on Re: 1 Machine, 2 NICs, 2 Instances of ntpd;Possible? - NTP ; Maarten Wiltink wrote: > Could you say more about that? I realise that it's not as clean cut as > the division between an FTP client and server, and that NTP may be > better served by a model like ...

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

Thread: Re: 1 Machine, 2 NICs, 2 Instances of ntpd;Possible?

  1. Re: 1 Machine, 2 NICs, 2 Instances of ntpd;Possible?

    Maarten Wiltink wrote:

    > Could you say more about that? I realise that it's not as clean cut as
    > the division between an FTP client and server, and that NTP may be
    > better served by a model like for example the server always requiring
    > some interchangeable client module(s?) being plugged into it (whether
    > network associations or hardware reference clocks, as mentioned).


    I think you will find that nearly all the code in ntpd is client code or
    common to both client and server. The client function is the difficult bit.

  2. Re: 1 Machine, 2 NICs, 2 Instances of ntpd;Possible?

    Maarten Wiltink wrote:
    > "Steve Kostecke" wrote in message
    > news:slrnftdkhp.knr.kostecke@stasis.kostecke.net.. .
    > [...]
    >> Currently NTP uses port 123/UDP for both the source and destination
    >> port. What you are proposing would require the use of a different source
    >> port to work on a single-homed host. This would result in a DOS when
    >> polling a server that enforces the NTP port.

    >
    > I'm no IP wizard, but isn't there a SO_REUSEPORT flag or something
    > like that?
    >


    Yes, but you cannot have two different applications *listening* on the
    same address/port at the same time without major problems.

    > Anyway, I frankly doubt that requiring a specific source port is
    > still a good thing. Dit it ever accomplish anything above testing
    > that the sender has root on the remote machine? By now, it mostly
    > serves to chase off innocent NATted clients.
    >
    >


    There is actually nothing wrong with sending queries on a different port
    except that you now have twice as many interfaces to listen on and manage.

    >> Another thing to consider is the fact that you would now have two
    >> processes which both require high priority access to the system clock.

    >
    > I can see how that would be a party killer. But the current, monolithic
    > NTP can't discipline the clock and answer polls at the exact same time,
    > either.


    That doesn't matter. Having two different processes is more expense CPU
    and performance-wise than a single server doing both. I have also
    pounded an NTP server (trying to reproduce a bug) and the server barely
    notices the load. My system certainly didn't.

    The obvious choice would be to give the client part priority
    > over the server part. Things might actually get *better*.
    >


    No it would be worse since you now have two processes competing with
    each other for system resources instead of just one, not to mention your
    having to manage it.

    > At thirty-
    > seven, all I have left is the questionable sideline-based wisdom to
    > see room for improvement.


    I'm much older than you then and I can still do it.

    Danny

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2