NTP sync on a standalone network (Windows 2k) - NTP

This is a discussion on NTP sync on a standalone network (Windows 2k) - NTP ; "Wolfgang S. Rupprecht" wrote in message news:87mza1zqnv.fsf@bonnet.wsrcc.com... > If you are allowed to have fiber-optical signals go into the room (but > not out) you might be able to run a GPS in some not quite so secure > area ...

+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast
Results 21 to 40 of 44

Thread: NTP sync on a standalone network (Windows 2k)

  1. Re: NTP sync on a standalone network (Windows 2k)


    "Wolfgang S. Rupprecht"
    wrote in
    message news:87mza1zqnv.fsf@bonnet.wsrcc.com...
    > If you are allowed to have fiber-optical signals go into the room (but
    > not out) you might be able to run a GPS in some not quite so secure
    > area and send only the NMEA and/or PPS into the secure area.


    I agree but the link between the GPS antenna and the secure area will be
    coper, not fiber.

    Are you aware of a GPS solution that would use fiber?










    > -wolfgang
    > --
    > Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/




  2. Re: NTP sync on a standalone network (Windows 2k)


    "Hal Murray" wrote in message
    news:_L2dnc1lD-lW5HjZnZ2dnUVZ_v6dnZ2d@megapath.net...
    > Using a single system as the master seems like a reasonable approach
    > to me. It's simple so you can understand it. Just fixup the time
    > by hand when it drifts too far off.


    That's my plan. Today my system is 9 minutes below the real time. I can't
    add 9 minutes in one go otherwise everything would crash. But I could add
    one minute every morning during nine days and it would be fine.


    > The main source of error in most systems is the initial accuracy
    > of the crystal when it comes from the factory. That's a constant.
    > You can measure it and correct for it. After that, your systems
    > will keep pretty good time. (That's how we used to do it before
    > NTP.)
    >
    > The next source of error is the shift in frequency as the temperature
    > changes. Is the temperature in your bunker stable? If so, that
    > helps a lot.
    >


    The aircon system is good so I am quite confident that it is stable.

    > Is the load on your system stable or bursty? Self heating is important.
    > It might help to allocate a separate box to being your NTP server.
    >



    The load is stable on the main server as it is only providing the active
    directory. Not very busy (not like a db backup).

    > adjtimex is the utility to tweak the clock frequency.


    Seems interesting in the long run.
    The only data I have found looks like code to be compiled for Unix. Anything
    ready for Windows?


    >
    > --
    > The suespammers.org mail server is located in California. So are all my
    > other mailboxes. Please do not send unsolicited bulk e-mail or
    > unsolicited
    > commercial e-mail to my suespammers.org address or any of my other
    > addresses.
    > These are my opinions, not necessarily my employer's. I hate spam.
    >




  3. Re: NTP sync on a standalone network (Windows 2k)

    Alexandre Carrausse wrote:

    > "Richard B. Gilbert" wrote in message
    > news:cPKdndwstPMAM3jZnZ2dnUVZ_oydnZ2d@comcast.com. ..
    >
    >>David J Taylor wrote:
    >>
    >>>Hal Murray wrote:
    >>>
    >>>
    >>>>In article <44e4e0a2$0$31030$626a54ce@news.free.fr>,
    >>>>"Alexandre Carrausse" writes:
    >>>>
    >>>>
    >>>>>Thanks, the GPS would be an option, but in the very secure site I am
    >>>>>working in, I am afraid I will not even be allowed to install an
    >>>>>antenna.
    >>>
    >>>[]
    >>>
    >>>
    >>>>>What is the approx cost of such systems?
    >>>>
    >>>>Do-it-yourself: Under $100 for a Garmin GPS 18 LVC. You also need
    >>>>a PC. Old ones are probably OK.
    >>>
    >>>
    >>>For example ..
    >>>
    >>> http://www.david-taylor.myby.co.uk/n...SD-GPS-PPS.htm
    >>>
    >>>.. including an antenna just poking out of the window. Of course, you
    >>>probably can't open the windows either!
    >>>
    >>>David

    >>
    >>If his site is really secure, he may have Windows but probably doesn't
    >>have windows!!! His electronic equipment may have to meet the "Tempest"
    >>criteria; e.g. any electromagnetic energy emissions do not contain
    >>recoverable information. Add inner and outer chain link fences topped
    >>with barbed wire, armed guards, and dogs. Your imagination can't be to
    >>vivid!!!! ;-)

    >
    >
    > It is not fort knox but almost ;-)
    > No windows and no telecommunication devices are allowed in the computer
    > room, no gsm, no antenna, no copper.
    >
    > Thank your for your help. Today I have tested some monitoring tools, and
    > overall the situation is good.
    > Our system is 9 minutes below the real time (my wristwatch:-)
    >
    > Here is how looks our client tcp.conf file file :
    >
    > server serverA
    >
    > As suggested, I am thinking about improving it to have
    >
    > server serverA
    > server serverB
    > server serverC
    > server serverD
    > server serverE
    >
    > On serverA, I am thinking about having the following conf
    >
    > peer serverB
    > peer serverC
    > peer serverD
    > peer serverE
    >
    > and so on for BCDE.
    >
    > Does this make sense?
    >
    > Alex
    >


    If you are not allowed ANY external reference, I suppose it's the best
    you can do. Your cell phone has time that is correct to within a few
    microseconds. Of course it probably only displays hours and minutes but
    the rollover of the minute should be within microseconds. From that
    you can probably set your watch within a second or so if you have good
    reflexes.

    Set the correct time on your server(s) and let them run for, say, seven
    days. You will need to know the exact time you set and the exact error
    seven days later. Knowing how far the servers drifted in seven days,
    you should be able to compute a frequency correction in parts per
    million. The number you come up with should have an absolute value of
    less than 500 and probably will be less than 50. Put this number in
    your drift file (or use it in adjtimex()or equivalent) to correct your
    freqency. For a check, 500 PPM works out to something like 43.2 seconds
    per day. It's hardly state-of-the-art timekeeping but I don't know what
    else you can do.

  4. Re: NTP sync on a standalone network (Windows 2k)

    Alexandre Carrausse wrote:

    > "Richard B. Gilbert" wrote in message
    > news:wYCdnSJs15yydnnZnZ2dnUVZ_sCdnZ2d@comcast.com. ..
    >
    >>Alexandre Carrausse wrote:
    >>
    >>
    >>>Thanks a lot for your feedback.
    >>>
    >>>See my comments below.
    >>>
    >>>
    >>>"Richard B. Gilbert" wrote in message
    >>>news:dNWdnQHRI_X9UX7ZnZ2dnUVZ_vGdnZ2d@comcast.com. ..
    >>>
    >>>
    >>>>Alexandre Carrausse wrote:
    >>>>
    >>>>
    >>>>
    >>>>>Hello,
    >>>>>
    >>>>>I want to keep the time sync'd on about 90 machines spreaded on 11
    >>>>>different sites (one central site with the main servers and 10 remote
    >>>>>sites with secondary domain controlers and workstations).
    >>>>>
    >>>>>>>>configuration and we are unsure about the time accuracy on our
    >>>>>>>>system.
    >>>>>
    >>>>>1. 1st question : Is this basic configuration enough?
    >>>>
    >>>>That is a question that only you can answer! Does it meet your needs
    >>>>for accuracy, and tightness of synchronization?
    >>>
    >>>
    >>>I am not sure that the current conf meet our needs because I have no
    >>>means to check it. Maybe Time Server Monitor (which I will test soon)
    >>>will help me to find the answer. ;-)
    >>>

    >>
    >>If you can't tell if the clocks are synchronized or not, why do you care?
    >>What problem are you trying to solve here?
    >>
    >>

    >
    >
    > I have used the tool NTPmonitor V5.0.6.28 - from David Taylor and I can
    > confirm that everything is synchronised, so at least my main goal is
    > reached.
    > If you think there is more I could do (within my constraints), I am open to
    > learn.
    >
    >
    >
    >
    >>>
    >>>But providing the fact that the remote clients will sync with the main
    >>>time server at the central site, over a 64 kbps network, is it reliable?
    >>>

    >>
    >>It's your net network! You should be in a far better position than I to
    >>say if it's reliable or not. You also need to specify what degree of
    >>reliability you need. If you cannot afford the failure of a network, you
    >>need redundant network connections
    >>

    >
    >
    > Let me ask the question in a different way : is the NTP protocol running
    > without any problem over a 64 kbps, or is there any configuration to think
    > about, that would tell the remote "hold on mate, don't be too impatient
    > because I am sending my packets over a 64 kbps line". I have seen somewhere
    > that it could be necessary to implement the huff'n'puff option. Is it true?
    >
    >
    >
    >>>
    >>>
    >>>>>4. Should we peer the server at the central site to keep them more on
    >>>>>time (9 minutes drift in one year, but the outside world time is not
    >>>>>very important for us)
    >>>>
    >>>>Suit yourself.
    >>>
    >>>
    >>>
    >>>I feel there is a risk of too much drift is my solution is based on only
    >>>one server providing the time to all the others... because this network
    >>>is isolated from the real world (let's say it's a bunker). If the main
    >>>server drift, all the rest of the system will drift.
    >>>My thought was that by peering the servers, that would minimise the
    >>>drift. If one drift, the others would tell hom : "hold on mate, you're
    >>>drifting too far"

    >>
    >>If you don't really care about accuracy, why should you care if the whole
    >>network follows a drifting server? Turning a single drifting server into
    >>a committee of drifting servers is unlikely to improve either accuracy,
    >>stability, or reliability. (There is a Sun White Paper that suggests that
    >>unsynchronized peering servers will converge to a common time but I would
    >>not want to count on it. See "Using NTP to Control and Synchronize System
    >>Clocks - Parts I, II, & III.
    >>http://www.sun.com/blueprints/browse...tml#networking)
    >>
    >>

    >
    > In fact my application which is based on clusters of servers, is running
    > over DCE Encina (IBM). In order to run, the servers must be very well
    > synchronised between them, and the time difference must never exceed 180 s.
    > If the time diff exceeds the threshold, everything will crash and will be
    > corrupted....
    >
    > I agree that my solution is not acurate, but it is quite stable (based on
    > the spec above), and for the reliability, I may have not to rely only on
    > one time server, but several...
    >
    >
    >
    >
    >>>
    >>>
    >>>>>5. What would happen if a silly user change the time by adding lets say
    >>>>>one hour to the main server... would this mistake be cascaded on all the
    >>>>>system? Is there any safety options? (our application would crash if the
    >>>>>time between 2 servers is more than 3 minutes)
    >>>>
    >>>>NTPD will panic and exit if the error is more than 1024 seconds (about 17
    >>>>minutes)
    >>>
    >>>
    >>>What do you mean by exit? He will refuse the clock change? Or the clock
    >>>will change but he will refuse to serve possibly wrong time to the
    >>>others... Any message logged?
    >>>

    >>
    >>I mean that the ntpd program will stop executing; fold up its tent and go
    >>away!! This is the usual meaning of "exit". No more time synchronization.

    >
    >
    > OK. So it means that if someone change the time on the main server (+/-1000s
    > ie approx 20 mins) the NTP daemon will stop to provide time, and all the
    > machine on the network will start to drift appart?... until someone realise
    > that the NTPDaemon is not started.
    >
    >
    >
    >


    A sixty-four KBPS link is slow but if it's not carrying a lot of other
    traffic it should work. Problems will show up if the transmission
    delays are not symmetric; e.g. if it take 1.1 milliseconds to go from
    point A to point B and 1.2 milliseconds to go from point B to point A
    that asymmetry is going to show up as an error in your time. If the
    link is loaded so that you can hardly slip a packet in edgewise, it's
    not going to work very well for NTP.

  5. Re: NTP sync on a standalone network (Windows 2k)

    Alexandre Carrausse wrote:

    > "Wolfgang S. Rupprecht"
    > wrote in
    > message news:87mza1zqnv.fsf@bonnet.wsrcc.com...
    >
    >>If you are allowed to have fiber-optical signals go into the room (but
    >>not out) you might be able to run a GPS in some not quite so secure
    >>area and send only the NMEA and/or PPS into the secure area.

    >
    >
    > I agree but the link between the GPS antenna and the secure area will be
    > coper, not fiber.
    >
    > Are you aware of a GPS solution that would use fiber?
    >


    If you are allowed to have a fiber optic link but not a copper link you
    could run NTP over the fiber link! I'm not aware of any refclock that
    uses a fiber optic output but if you can put a fiber optic Ethernet NIC
    in a PC outside and a PC inside and connect the two. . . . If the
    inside machine runs a firewall that only allows the NTP protocol to and
    from port 123 only. . . . Fiber optic NIC's are rare and expensive but
    there are, or were, such things.

  6. Re: NTP sync on a standalone network (Windows 2k)


    Richard B. Gilbert wrote:

    Fiber optic NIC's are rare and expensive but
    > there are, or were, such things.


    You may search for:

    1. Allied Telesyn AT-2701FX/ST or AT-2701FX/SC
    2. Allied Telesyn AT-2930SX 1000BaseSX-SC, PCI, ACPI

    The price is around 150 USD.


  7. Re: NTP sync on a standalone network (Windows 2k)

    Eugen COCA wrote:

    > Richard B. Gilbert wrote:
    >
    > Fiber optic NIC's are rare and expensive but
    >
    >>there are, or were, such things.

    >
    >
    > You may search for:
    >
    > 1. Allied Telesyn AT-2701FX/ST or AT-2701FX/SC
    > 2. Allied Telesyn AT-2930SX 1000BaseSX-SC, PCI, ACPI
    >
    > The price is around 150 USD.
    >


    No thanks. I could buy the fiber NICs but I'm afraid that the
    hub/switch would bankrupt me!! I've seen fiber used for gigabit links
    between 10/100 switches but that's about all.

  8. Re: NTP sync on a standalone network (Windows 2k)


    Richard B. Gilbert wrote:

    > No thanks. I could buy the fiber NICs but I'm afraid that the
    > hub/switch would bankrupt me!! I've seen fiber used for gigabit links
    > between 10/100 switches but that's about all.


    You may use a direct link between 2 NICs on fiber optic, without
    switches. The price of the link is around 250 USD.

    And, after all, you may use Ethernet to fiber converters (around 75USD
    a piece) and ordinary Ethernet cards. And you'll have the same result.
    We have several links like this ...


  9. Re: NTP sync on a standalone network (Windows 2k)


    "Richard B. Gilbert" wrote in message
    news:ioOdnSafmsPzzXvZnZ2dnUVZ_tSdnZ2d@comcast.com. ..
    >>[snipped for HER pleasure]

    >
    > If you are not allowed ANY external reference, I suppose it's the best
    > you can do. Your cell phone has time that is correct to within a few
    > microseconds. Of course it probably only displays hours and minutes but
    > the rollover of the minute should be within microseconds. From that
    > you can probably set your watch within a second or so if you have good
    > reflexes.
    >

    Assuming, of course, that he's on a CDMA network. GSM networks don't care
    what a particular second of time is labeled, so long as it's sliced
    correctly. Around these parts, Cingular time is 16 seconds slow.


    Brian Garrett




  10. Re: NTP sync on a standalone network (Windows 2k)

    Alexandre Carrausse wrote:
    > "Hal Murray" wrote in message

    []
    >> adjtimex is the utility to tweak the clock frequency.

    >
    > Seems interesting in the long run.
    > The only data I have found looks like code to be compiled for Unix.
    > Anything ready for Windows?


    Not "ready", as far as I know, but in principle it can be done as Windows
    allows you to set the number of timer ticks required between each timer
    interrupt to, IIRC, a precision of about 1 part in 150,000 (about a second
    a day). So to catch up just set that value to about 100 less than it is
    now, and catch up in a small number of days, smoothly, without any steps.
    [Please check my sums!]

    See:
    http://msdn.microsoft.com/library/de...adjustment.asp

    http://msdn.microsoft.com/library/de...adjustment.asp

    A "two line" program should do the job....you may even be able to do it
    from the command-line with VB Script.

    Cheers,
    David



  11. Re: NTP sync on a standalone network (Windows 2k)


    "Alexandre Carrausse" writes:
    > Are you aware of a GPS solution that would use fiber?


    Not out of the box, but there are fiber converters for rs-232 and ttl
    levels. They are low volume items and the price seems to be all over
    the place.

    http://www.telebytedatacom.com/catal...ducts/9271.htm

    -wolfgang
    --
    Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/

  12. Re: NTP sync on a standalone network (Windows 2k)


    See www.meinberg.de (http://www.meinberg.de/english/products/goal.htm)
    - they can put a fiber link between the antenna unit and the actual receiver.

    Frank

  13. Re: NTP sync on a standalone network (Windows 2k)

    In article ,
    Richard B. Gilbert wrote:
    > Alexandre Carrausse wrote:


    > > I agree but the link between the GPS antenna and the secure area will be
    > > coper, not fiber.


    No. The copper would terminate on the GPS receiver, which would be outside
    the secure area. The fibre would carry the baseband NMEA signal.

    > If you are allowed to have a fiber optic link but not a copper link you
    > could run NTP over the fiber link! I'm not aware of any refclock that


    There are two likely reasons for restricting to fibre: one is EMP
    protection, the other is security. If security is the case, and
    you operate a bidirectional protocol like NTP, the electronics at the
    remote end of the link would almost certainly also be considered
    part of the secure area and subject to the same restrictions as the
    main area, unless the data was encrypted and they were not the final
    end point of the transmission. (Google "covert channels" for more.)

    He might be allowed to operate a link that was uni-directional, which
    would allow him to have the complete receiver in an insecure area,
    and transmit the data optically (phototdiodes aren't very good light
    sources, so there is little risk of information leaking the other way).

    I don't believe that ntpd needs to be able to talk to NMEA time sources,
    although it may try to configure them.

  14. Re: NTP sync on a standalone network (Windows 2k)

    In article <44e63895$0$32471$626a54ce@news.free.fr>,
    Alexandre Carrausse wrote:
    > "Hal Murray" wrote in message
    > news:_L2dnc1lD-lW5HjZnZ2dnUVZ_v6dnZ2d@megapath.net...
    > > Using a single system as the master seems like a reasonable approach
    > > to me. It's simple so you can understand it. Just fixup the time


    Definitely. Peering was never intended to be use for unsychronised
    networks. It was not designed for creating a consensus time out of
    nothing. For a start, local clocks are normally clocks of last
    resort, so you would have to prefer them, but even then, the whole
    system would almost certainly wander in frequency and could end up
    with some machines exceeding the 500ppm maximum correctable frequency
    offset.

    > > by hand when it drifts too far off.


    > That's my plan. Today my system is 9 minutes below the real time. I can't
    > add 9 minutes in one go otherwise everything would crash. But I could add
    > one minute every morning during nine days and it would be fine.


    The smoothest way of doing this is to stop the master server's ntpd
    temporarily, load a large number in the correct sense into its ntp.drift
    and restart it. When it intersects true time, repeat the process,
    but put the measured static frequency error into ntp.drift.

    The large number should be less than 500.0 and it should also be less than
    500 minus the largest value in ntp.drift, of the same sign, for any of
    the other clients. This ensures that no machine will need to exceed a
    500ppm correction to retain lock. I'd suggest using 450, rather than 500.
    If you can get away with less, it will be even better.

    Assuming that the NT port supports remote configuration, I would suggest
    enabling that when you first stop the master server. You can then fudge
    the correction, to trim the frequency, without having to stop the server
    again.

    > > adjtimex is the utility to tweak the clock frequency.


    > Seems interesting in the long run.
    > The only data I have found looks like code to be compiled for Unix. Anything
    > ready for Windows?


    You can achieve the same by setting ntp.drift manually and restarting,
    or by fudging the local clock frequency, remotely.


  15. Re: NTP sync on a standalone network (Windows 2k)

    "Alexandre Carrausse" wrote in message
    news:44e62aba$0$32476$626a54ce@news.free.fr...
    [...]
    > On serverA, I am thinking about having the following conf
    >
    > peer serverB
    > peer serverC
    > peer serverD
    > peer serverE
    >
    > and so on for BCDE.
    >
    > Does this make sense?


    Probably not. Peering does not in any way average the time from
    several servers. It just creates an association that may work
    either way (but not both).

    It's useful when both servers have (disjoint) references, and
    may independently lose their connection with those. Then either
    server can fall back on the other. If both servers have the
    same sources, you gain nothing.

    If you have only one source, just build a simple tree. Doing better
    requires rather careful fault scenario analysis.

    Groetjes,
    Maarten Wiltink




  16. Re: NTP sync on a standalone network (Windows 2k)

    "Maarten Wiltink" wrote in message
    news:44e6f442$0$4527$e4fe514c@news.xs4all.nl...
    [...]
    > 's useful when both servers have (disjoint) references, and
    > may independently lose their connection with those. Then either
    > server can fall back on the other. If both servers have the
    > same sources, you gain nothing.


    Sorry. If both servers have the same _connection_, you gain nothing.

    Groetjes,
    Maarten Wiltink



  17. Re: NTP sync on a standalone network (Windows 2k)

    Eugen COCA wrote:

    > Richard B. Gilbert wrote:
    >
    >
    >>No thanks. I could buy the fiber NICs but I'm afraid that the
    >>hub/switch would bankrupt me!! I've seen fiber used for gigabit links
    >>between 10/100 switches but that's about all.

    >
    >
    > You may use a direct link between 2 NICs on fiber optic, without
    > switches. The price of the link is around 250 USD.
    >
    > And, after all, you may use Ethernet to fiber converters (around 75USD
    > a piece) and ordinary Ethernet cards. And you'll have the same result.
    > We have several links like this ...
    >


    I had my home wired (cat-5e) a few years ago. I don't see any advantage
    in going to fiber at this time; certainly not enough to justify the
    expense.

  18. Re: NTP sync on a standalone network (Windows 2k)

    in article <44e634ea$0$32462$626a54ce@news.free.fr>,
    Alexandre Carrausse wrote:

    > Let me ask the question in a different way : is the NTP protocol running
    > without any problem over a 64 kbps, or is there any configuration to think
    > about, that would tell the remote "hold on mate, don't be too impatient
    > because I am sending my packets over a 64 kbps line". I have seen somewhere
    > that it could be necessary to implement the huff'n'puff option. Is it true?


    33k is quite possible. In fact slow links can be more reliable, because, if
    they overload, the round trip time goes so high that ntpd ignores the
    updates until the overload goes away.

    The main problem happens on systems with medium fast connections and consumer
    type traffic profiles (i.e. most traffic is extracting information from the
    web, and it tends to peak drastically at lunch times). It will also depend
    on how heavily utilised your link is.

    In your case, I might be more worried that the encryption may be introducing
    delays and uncertainties.

    You can tell if you have a problem by monitoring the delay value in the
    peers subcommand of ntpq. The best solution is to configure the routers
    to give priority to NTP traffic. This is an option that you probably have
    but people dependant on an ISP generally don't have.

    > OK. So it means that if someone change the time on the main server (+/-1000s
    > ie approx 20 mins) the NTP daemon will stop to provide time, and all the


    As others have said, this is really a social engineering problem.

    However, the master server will continue to provide time, because
    the effect of using the local clock is that their time always seems
    to be perfectly correct. It is the clients that will commit suicide.
    If you are lucky, NT will still retain the last frequency correction,
    and you should have an error which could be as low as 30 seconds a year.
    (This is what happens on modern Unix-like systems, with kernel support
    for NTP and I think that the NT time adjustment mechanism would require
    ntpd to explicitly cancel its adjustment for that not to happen.)

    > machine on the network will start to drift appart?... until someone realise
    > that the NTPDaemon is not started.


    Given that you say that the application will crash if there is an error
    of more than 3 minutes, it seems to me that it won't take long for them
    to discover that one of the machines (the master) is out by more than
    20 minutes. More generally, if you cannot realise and correct this
    quickly, I think you ought to look into that, rather than whether or not
    the remote systems will start to free run and may fail a some time in the
    future . Similarly, if the operators are allowed to make such a mistake
    and correct it, without logging the fact, you have a discipline problem.


  19. Re: NTP sync on a standalone network (Windows 2k)

    It's very easy to monitor your machines if they all peer with each other.

    H

  20. Re: NTP sync on a standalone network (Windows 2k)

    Alexandre Carrausse wrote:
    >
    > The load is stable on the main server as it is only providing the active
    > directory. Not very busy (not like a db backup).
    >


    Okay, just remember that Active Directory uses Kerberos so the clients
    need to be within 5 minutes of the Active Directory Controller to work
    properly, which you are apparently doing with your setup.

    >> adjtimex is the utility to tweak the clock frequency.

    >
    > Seems interesting in the long run.
    > The only data I have found looks like code to be compiled for Unix. Anything
    > ready for Windows?
    >


    No, we've never had an occasion to build it. I don't think it's
    necessary if you are running ntpd and just synching to the master.

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


+ Reply to Thread
Page 2 of 3 FirstFirst 1 2 3 LastLast