time server ??

Discussion in 'Linux Networking' started by Andre, Aug 26, 2011.

  1. Andre

    Andre Guest

    do you know a time server?
    I use to use time.windows.com, but since a while it seems to have stopped
    Many thanks
    Andre, Aug 26, 2011
    1. Advertisements

  2. Andre

    Thad Floryan Guest

    ntp.ubuntu.com works well
    pool.ntp.org is another

    A list of all public servers:


    This page <http://support.microsoft.com/kb/262680> lists:

    For the list of stratum one time servers, visit the following Web site:

    For the list of stratum two time servers, visit the following Web site:

    For the list of NIST Internet Time Servers, visit the following Web site:

    For the list of NTP Pool Servers, visit one of the following Web sites:

    Thad Floryan, Aug 26, 2011
    1. Advertisements

  3. Andre

    Andre Guest

    Le Fri, 26 Aug 2011 00:48:36 -0700, Thad Floryan a écrit :
    Many thanks for your answer.
    Andre, Aug 26, 2011
  4. Andre

    unruh Guest

    unruh, Aug 26, 2011
  5. Andre

    unruh Guest

    So not use a stratum one server unless you have permission from the
    owner of that server.

    Stratum one are totally unnecessary unless you really really need
    microsecond accuracy in your timing.

    pool.ntp.org is the best address to use. It is a grouping of many thousands of
    servers all of whom have given permission to have their meachines used
    as public servers. When you do a dns request on pool.ntp.org you will
    get one of those thousands of servers randomly.
    unruh, Aug 26, 2011
  6. Andre

    passion.rp Guest

    passion.rp, Mar 15, 2013
  7. Andre

    Jorgen Grahn Guest

    Doesn't your Linux distribution suggest NTP servers? Debian has

    Or google "public ntp time server".

    Jorgen Grahn, Mar 15, 2013
  8. Andre

    unruh Guest


    EVery time it is called it gives a new ntp source.
    unruh, Mar 15, 2013
  9. Don't you think a year and a half after he posted that he's either no
    longer interested, or has long ago figured out a solution?

    Just because google lets people reply to messages older than 30 days old
    doesn't mean people should. That post from August of 2011, your quote
    even shows the date of the original, even had a decent number and quality
    of replies. There's no reason to resurrect an old thread now.

    That said, I have no idea why the previous poster dug up the old thread,
    but he had nothing to say, he just quoted an old post, perhaps at random,
    and you replied to that.

    The guy may have been spamming, except he forgot to add his spam. I ahve
    seen instances of people replyging to old messages in order to spam.

    Michael Black, Mar 16, 2013
  10. Hello,

    unruh a écrit :
    Actually it appears to give 4 sources every 150 seconds.
    Pascal Hambourg, Mar 17, 2013
  11. Andre

    Moe Trin Guest

    More useful in "spreading the load" than anything else.
    [fermi ~]$ host ad.ntp.pool.org
    ad.ntp.pool.org has address
    [fermi ~]$ whois
    96 Mowat Avenue
    Toronto, ON M6K 3M1
    [fermi ~]$
    Physical distance does not reliably translate into network distance.
    Above, the last I looked neither Andorra or the Faroe Islands are
    located on or close to Mowat Avenue in Toronto, Canada.

    One need only play with tools like hping2, hping3, mtr, nmap,
    tracepath, traceroute and/or tcptraceroute to discover things about
    network distances which translate into timing delays. The man page
    for the original LBL traceroute (contained in the tarball at
    ftp://ftp.ee.lbl.gov/traceroute.tar.gz) has more details than the
    man page from the traceroute.sourceforge.net version found in many
    current distributions or the rewrite from Olaf Kirch then at Caldera.

    Further, you really do want to read and understand RFC5905

    5905 Network Time Protocol Version 4: Protocol and Algorithms
    Specification. D. Mills, J. Martin, Ed., J. Burbank, W. Kasch.
    June 2010. (Format: TXT=241096 bytes) (Obsoletes RFC1305,
    RFC4330) (Status: PROPOSED STANDARD)

    although the explanation in Appendix H of RFC1305

    1305 Network Time Protocol (Version 3) Specification, Implementation
    and Analysis. D. Mills. March 1992. (Format: TXT=307085,
    PDF=442493 bytes) (Obsoletes RFC0958, RFC1059, RFC1119)
    (Obsoleted by RFC5905) (Status: DRAFT STANDARD)

    may be more readable. The TimePrecision-HOWTO from the Linux Doc
    Project is also a useful document:

    -rw-rw-r-- 1 gferg ldp 43295 Nov 18 2005 TimePrecision-HOWTO

    Old guy
    Moe Trin, Mar 17, 2013
  12. Andre

    Chris Davies Guest

    I don't see anything in the original whois record that says
    itself is in Toronto. What you picked out is actually the address provided
    by the Tucows.com registrar (see the two lines above your SNIP mark).

    Now back to the question about the ntp.pool.org. The
    recommendation is to use your country code designation in the Pool,
    eg. {0,1,2,3}.uk.ntp.pool.org, but this isn't essential. The advantage
    is that if local servers become available they will rotate into the
    Pool. If no such servers are available then you're no worse off than if
    you'd just used the global ntp.pool.org anyway.

    See http://www.pool.ntp.org/en/use.html

    It may be important to be aware that the Pool does not guarantee to
    deliver time with an accuracy of better than one second (I can't find
    a reference to this; I think it was on the mailing list a year or
    so back.) That operators such as myself can usually deliver at NTP
    accuracies of considerably better than this is a bonus. Many of us
    are on ADSL links and the inherent assymetry upsets NTP's algorithms
    sufficiently that millisecond accuracy simply isn't possible.

    Chris Davies, Mar 18, 2013
  13. Andre

    Moe Trin Guest

    On Mon, 18 Mar 2013, in the Usenet newsgroup comp.os.linux.networking, in
    True enough - but my reply continued:

    ]One need only play with tools like hping2, hping3, mtr, nmap,
    ]tracepath, traceroute and/or tcptraceroute to discover things about
    ]network distances which translate into timing delays.

    and tracing via two different bandwidth providers here in Phoenix
    (about 360 miles/600 KM East of Los Angeles) takes me via two
    different backbones to routers at "mag01.yyz02.atlas.cogentco.com"
    (where YYZ is the IATA code for Toronto) or "Toronto1.Level3.net",
    thence to a router that isn't providing ICMP errors, then to a router
    with no PTR record on the 216.40.38.x subnet belonging to Tucows.com,
    thence to the above IP (with a PTR of url.hover.com). Tracing with
    UDP packets shows a significant scatter in the overall time delays.
    i.e. spreading the load - which is good. There is an advantage if
    the "local" server is actually on the same backbone. In some
    countries, there are effectively only one, and routing tends to be
    more efficient (possibly less convoluted). In other countries, all
    bets are off. Doing a trace from my house to Arizona State
    University (about 30 miles/48 km South) shows my packets being
    routed through Los Angeles - because my ISP and the university don't
    have connections to the same backbones. People also tend to forget
    that routing is not symmetrical. My packets go out via my default
    route, the ISP forwards them onto what appears (to them) to be the
    "best" route at the moment. The packets being sent in reply leave the
    server via the route that appears (to the bandwidth provider the
    server is connected to) to be the "best" route at the moment, but
    where there are multiple routes between "A" and "B", the route "to"
    is less likely to match the route "from".
    That's usually more than adequate for nearly all users. People tend
    to forget that the oscillators used for clock timing in computers are
    commodity grade, and are typically good to +/-100 ppm _overall_
    accuracy (includes "setting" and "thermal" errors). Even if the
    system clock is disciplined to an external reference, changes in
    temperatures INSIDE the computer can cause temporary errors. A mere
    11.6 ppm error is a second a day. For those few who actually require
    millisecond (or better) accuracy, satellite timing receivers are
    cheap and actually designed for that goal.

    Old guy
    Moe Trin, Mar 18, 2013
  14. Andre

    unruh Guest

    But that is really irrelevant, since the whole purpose of ntp is to
    discipline the oscillator, or more accurately the translation from the
    oscillator to the time ticks of the computer to far better than that.
    Thus under an ntp discipline, those "commercial grade" oscillators can
    deliver time to tens of micro (not milli) second accuracy.
    Thermal problems may create slow drifts, but the also get taken care of
    (nptd tends to be less accurate than say chrony because of its very slow
    response to changes like thermal changes).
    Except the thermal drifts tend to be significantly less than that (say
    1PPM) and ntpd or chrony will catch it long before a day.
    They still operate by disciplining the local clock on the computer. But
    if you have a high accuracy souce on your own network, you can easily
    get tens of micro second accuracy, and if you use a $30 GPS receiver,
    about 2 microsecond accuracy on that commercial grade computer

    Ie, the problem with time,keeping is NOT the computer oscillator. It is
    the network.
    unruh, Mar 18, 2013
  15. Andre

    Jorgen Grahn Guest

    See below.
    See below.
    Guilty as charged -- I never use Google Groups and I never reply to
    ancient postings, but I didn't spot the old date on the actual question.

    Jorgen Grahn, Mar 18, 2013
  16. Andre

    Chris Davies Guest

    Chris Davies, Mar 19, 2013
  17. Andre

    Moe Trin Guest

    On Mon, 18 Mar 2013, in the Usenet newsgroup comp.os.linux.networking, in
    Under good conditions - I won't disagree, but I don't think it can
    be guaranteed. Computers are meant to compute, not act as accurate
    time references.
    While the (local) temperatures inside the computer tend to be fairly
    stable (the computer acting somewhat like an oven around the crystal)
    it's still going to be moving. How often are you getting an NTP
    My Vectron and Bliley catalogs disagree with your numbers. I'm looking
    at some specs to a fairly typical oscillator (US$3.46 in onesies, less
    in production quantities) and they quote a setting accuracy of +/-50
    ppm, a thermal stability of +/-100ppm over the range 0 to +60C and
    similar values for supply voltage (+4.5 to +5.5 VDC). The so-called
    typical thermal curve shown is "S" shaped, and is about 3 ppm/degreeC
    at +40C, but at those prices I can almost guarantee that neither the
    initial setting or drift rates are tested, never mind adjusted if that
    were possible. ("Is it functioning?" "Yes" "Ship it!")
    Not the ones I've used.
    Haven't been in the business for over twenty years, but the units I
    worked with ("Timation"? Something like that) had a IRIG-A/B/G serial
    outputs as well as a IRIG PB1 parallel output - special interface card
    in the computer. We were looking for +/- 2 msec overall accuracy
    and 1 msec resolution - the PB1 does that.

    Old guy
    Moe Trin, Mar 19, 2013
  18. Andre

    unruh Guest

    But they are designed to compute by having a crystal clock the
    computations through the cpu. Ie, it does act as a clock.
    Actually it is the internal temperature that is the problem, not the
    room. When the computer is busy, the cpu makes more heat and the temp
    inside rises. When it is not busy, the temp come much closer to room
    temp. That can makea difference of 20-30C /

    At poll 10 (2^10 sec) it gets a new report every 1/4 hr. But ntp throws
    out about 7 of every 8 measurements, so ntp only looks at something like
    once ever 2 hr. If it finds that the rate has deviated it will decrease
    that by a factor of about 20. (ie every 10 min insteead of 2 hr). chrony
    keeps all of the measurements and that is one of the reasons it responds
    more quickly. If you use a gps, the standard is to measure every 16 sec.

    I think measurements trump data sheets. I have 8 computers that I

    Anyway, thermal effects are around 1PPM. and the quoted accuracy is
    irrelevant since the computer calibrates the oscillator ticking and does
    not simply assume that x ticks equals one second. It measures it.

    And my GPS ($30) on my computer (commercial grade) does about 3 microsecond accuracy.
    and my other machines connected via ethernet do about 10 microseconds.
    Ie 1000 times better than you are quoting.
    serial and parallel port output is incredibly slow, if you are actually
    using the data from them. If you use them for their interrupts, then you
    can get microsecond accuracy. FOr nanosecond accuracy, you need special
    unruh, Mar 19, 2013
  19. Andre

    Moe Trin Guest

    On Tue, 19 Mar 2013, in the Usenet newsgroup comp.os.linux.networking, in
    Ah, but those clocks are separate from the clock the computer uses
    to act as a time reference. Go back to the original IBM PC (4.77 MHz
    8088) and the CPU was clocked at 4.77 MHz. Time of day was sourced
    from a 1.8432 MHz crystal that was divided down to 18.0 Hz (IRQ 0). In
    the modern PC, the CPU clock rate may actually be variable - Pentium
    style CPUs throttle back the clock speed when they detect they're
    overheating. That would play hell if the same clock were used as a
    time of day function. Heck, my cell-phone has a clock in it as well,
    but that doesn't make it a precision timing source either.
    Actually when we started this racket, the boys a DIX had just
    invented Ethernet - this goes back to about 1970 and several PDP-11s.
    Network? Sure, you took the 10 inch reels of tape from one system
    to another (the 360/something back at the center, 55 miles away).
    The parallel data was 36 bits wide (9 bits "day of year" and 27 bits
    "milliseconds of day"). The serial data was slow - IRIG-B was one
    frame (100 bits) per second, giving BCD time of year to a second.
    IRIG-A was ten times that (and 1/10 second resolution) while IRIG-G
    was another ten times better. The serial stuff could easily be
    transmitted over a voice grade radio channel to the aircraft and
    facilities around the airfield. We didn't use it, but there were
    several other parallel standards that provided microsecond and
    nanosecond resolution (56 bits as I recall). If you're not familiar
    with "IRIG", that's the "Inter-Range Instrumentation Group" out of
    White Sands Missile Range, and their standards are used both by other
    government agencies and industry. When we started using PCs, there
    was a special interface card (with a humongous 78 pin "D" submin
    connector on the back) to mux the parallel data onto the ISA bus.
    Used differently - as the computer was inhaling data from various
    sources, it also took snapshots of the 36 bit time word. The data
    was also stuffed out onto 1/2" tape (along with those time words) so
    that post-flight processing could get more out of it than the PDPs
    had CPU cycles for in real-time. We used essentially the same
    setup/methods into the early 1990s. I'm told the separate parallel
    clock mechanism is also mandated by the US government for certain
    data archiving processes in the financial world.

    Old guy
    Moe Trin, Mar 20, 2013
  20. Andre

    unruh Guest

    But what I am saying is that the main problem with those consumer grade
    oscillators is that they are not tested to any great accuracy, but that
    is primarily a calibration problem, and when properly calibrated
    (differently for each crystaL) they are good to a muche beter than 1PPM
    except for temperature fluctuation, which gives you maybe 1PPM per C if
    bad, and that can also be calibrated out. (That is what ntpd does-- a
    running alcibration)
    Well, yes, in the past timekeeping was poorer. In 1600 you could get
    about 20 second accuracy from a sundial. In the 1700 about 1 sec from
    pendulum clocks and then spring wound clocks. By 1900 you were getting
    down to ms. Again the pendulum and spring clocks has to be calibrated
    against sundials occasionally since they had PPK to 10s of PPM rate
    drifts ( and with the navigation watches in the 1800s , down to PPM rate drifts).

    But now computers are down to microsecond accuracy for cheap crystals,
    and better than PPT (Parts per tera). for the better clocks.
    unruh, Mar 20, 2013
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.