project ntp.br - NTP

This is a discussion on project ntp.br - NTP ; Dear Sirs: NIC.br is working on the project ntp.br, that has the goal of improving the quality of time synchronization in (brazilian) Internet hosts and networks and of provide legal brazilian time. Basically we intend to provide stratum 1 and ...

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

Thread: project ntp.br

  1. project ntp.br

    Dear Sirs:

    NIC.br is working on the project ntp.br, that has the goal of improving
    the quality of time synchronization in (brazilian) Internet hosts and
    networks and of provide legal brazilian time.

    Basically we intend to provide stratum 1 and stratum 2 servers,
    synchronized with legal brazilian time (that is kept by the observatorio
    nacional - www.on.br - and is, in last instance, UTC).

    We will have 3 of the following structure (at 3 different sites, at 3
    different cities: Sao Paulo, Rio de Janeiro, Brasilia):

    -----------------------------------------------------------
    Observatorio Nacional (Cesium clock)
    |
    |(periodically assures the
    | accuracy with the official
    | brazilian time - that is
    | in last instance UTC)
    #
    ** Rubidium clock **
    ** Stratum 0 **
    Symmetrycom
    |
    |(IRIG)
    #
    ** Stratum 1 Server **
    Appliance Spectracom ------------------
    or Appliance Symmetrycom |
    | |(Internet)
    |(Internet or LAN) |
    # #
    ** Stratum 2 Server ** (stratum 2 "clients")
    cluster with 2 Dell blade servers (autonomous systems)
    | (big networks)
    |(Internet)
    #
    (stratum 3 "clients")
    (home users, small
    and medium networks)
    -----------------------------------------------------------

    The Rubidium clocks and stratum 1 servers will be completely independent
    of each others, but each of the six stratum 2 servers will be
    synchronized by the three stratum 1 servers.

    The project will start with 2 complete sites (Sao Paulo, Rio de
    Janeiro). The third site (Brasilia) will have only the stratum 2
    servers, and in the next year the Rubidium clock and the stratum 1
    server will be added.

    The stratum 2 servers will be open to the Internet, intended to be used
    by home users, small and medium networks, to synchronize clients or
    stratum 3 servers..

    The stratum 1 servers will have their access restricted, intended to be
    used only by the Autonomous Systems and big networks to syncronize their
    own stratum 2 servers. We estimate about 600 clients for each stratum 1
    server.


    We need some help and advise in the following questions:

    1 - Is that a good structure or it needs to be improved or corrected?

    2 - The Stratum 1 Servers are appliances and do have some limitations at
    access control configuration. How can we provide access limitation by
    other means? We are studying the following possibilities:
    (a) A firewall between the Internet and the Stratum 1 servers, with a
    per client IP configuration.
    (b) A vpn (openvpn).
    What would be better? Is there any other alternative?

    3 - About cryptography:
    - We don´t fully understand the options and implications yet.
    - It seems to complicate a little the client side configuration. We
    fear that it will desincourage the potencial users.
    - It seems that the majority of the servers at public pool don´t uses it.
    Then:
    (a) What are the real risks of not implementing the cryptography?
    (b) What is more recommended: Autokey, or symmetrical keys? Why?
    (c) Is it possible to implement cryptography as an optional feature:
    the server configuration accepts clients with and without cryptography?

    4 - We are experiencing some degree of difficulty to fully understand
    Autokey. Is there any documentation with a working configuration example?

    5 - At the stratum 2 servers, what is the more advisable OS? FreeBSD?
    OpenBSD? Linux? Windows? We have read something about freebsd being the
    best choice, but without an explanation.

    6 - Regarding monitoring, we intend to use basically adapted versions of
    the scripts found at http://www.schlitt.net/scripts/ntp/ and at
    http://saturn.dennishilberg.com/gathering_data.php. But we would also
    like to have some statistics about quality of the clients
    synchronization, specially of the stratum 2 servers at the autonomous
    systems. Maybe get a "ntpq -c pe" for each one from time to time. Any
    advise regarding this?


    Sorry for the long post, and thanks in advance.

    --
    Antonio M. Moreiras
    Project Engineer at Brazilian Network Information Center - NIC.br
    moreiras@nic.br
    http://www.nic.br



    Posted Via Usenet.com Premium Usenet Newsgroup Services
    ----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
    ----------------------------------------------------------
    http://www.usenet.com

  2. Re: project ntp.br

    In article <1191513268_6661@sp12lax.superfeed.net>,
    Antonio M. Moreiras wrote:

    > |(periodically assures the
    > | accuracy with the official
    > | brazilian time - that is
    > | in last instance UTC)
    > #
    > ** Rubidium clock **


    How far is this allowed to get from UTC? If the maximum discrepancy isn't
    very small compared with the combination of "precision" and half minimum
    round trip time to a client, and given this is a high profile server, you
    should modify the source code to add the maximum error into the root
    dispersion calculation.

    If you don't do this, someone using your source and something more
    directly tied to UTC may find that the error bounds don't overlap, and
    one gets thrown out.

  3. Re: project ntp.br

    Antonio,

    You ask many good questions.

    Perhaps sadly, I do not have time right now to answer them.

    I will say that the answers to your questions either are or should be
    answered on http://support.ntp.org .

    H

  4. Re: project ntp.br - discrepancy from UTC

    The Cesium clock at observatorio nacional (ON) is UTC. In fact, the ON
    is one of the metrology laboratories that colaborates with the Bureau
    International des Poids et Measures (BIPM) in generating the UTC (as
    NIST does in USA, for example).

    The Rubidium clocks are synchronized with the UTC at least one time per
    year and the manufacturer says that the Rubidum reference has a monthly
    aging less than 5e-11 and a yearly aging less than 5e-10.

    It gives us a 16ms maximum discrepancy from UTC (31,536,000,000 ms/year
    * 5e-10 * 1 year = 15.765ms - is this correct?)

    After one year, with the discrepancy at 16ms it will be probabily of the
    same order than the half round trip time for the majority of the clients.

    Given this, do you you think it will be necessary any modification?

    If so, what would be the maximum discrepancy allowed to not need any
    modifications? As the primary servers are appliances from Symmetrycom or
    Spectracom probabily it will be very difficult to get customized
    firmware versions... Maybe we should study the possibility of
    synchronize the Rubidium reference clocks more frequently with UTC.

    I don´t know if I correctly understood what this discrepancy can cause.
    If a client is using other sources attached directly to GPSs, for
    example, there is a risk that our servers being considered falsetickers.
    Is it? Or is there other problems?

    A discrepancy of 16ms in a Internet NTP primary server is acceptable?

    In Brazil time stamps should be less than 100ms accurate to be legaly
    valid (for financial or government institutions, for example). I think
    it is the same in other parts of the world. Then, 16ms appears to
    reasonable for an Internet service.

    The majority of the Internet NTP primary servers are GPS based. For
    curiosity: what is the discrepancy of GPS time from UTC (without
    considering the leap seconds)?

    []s
    Antonio M. Moreiras.


    David Woolley escreveu:
    > In article <1191513268_6661@sp12lax.superfeed.net>,
    > Antonio M. Moreiras wrote:
    >
    >> |(periodically assures the
    >> | accuracy with the official
    >> | brazilian time - that is
    >> | in last instance UTC)
    >> #
    >> ** Rubidium clock **

    >
    > How far is this allowed to get from UTC? If the maximum discrepancy isn't
    > very small compared with the combination of "precision" and half minimum
    > round trip time to a client, and given this is a high profile server, you
    > should modify the source code to add the maximum error into the root
    > dispersion calculation.
    >
    > If you don't do this, someone using your source and something more
    > directly tied to UTC may find that the error bounds don't overlap, and
    > one gets thrown out.



    Posted Via Usenet.com Premium Usenet Newsgroup Services
    ----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
    ----------------------------------------------------------
    http://www.usenet.com

  5. Re: project ntp.br - questions

    Thank you Harlan. I don´t have previous experience with ntp, than since
    I was assigned to this project, a month ago, I´ve spent a lot of time
    reading the documentation from ntp.org, from David Mills website, some
    RFCs, papers, dissertations, etc.

    Even so, I have a lot of questions yet!

    This project is very important for us, because there is few public
    servers in Brazil, and fewer primary servers. Also the majority of the
    primary servers rely only on one source, the GPS system.

    Then, more than answers, we are seeking also for advises and
    considerations of how we can provide this service with high quality.

    []s
    Antonio M. Moreiras

    Harlan Stenn escreveu:
    > Antonio,
    >
    > You ask many good questions.
    >
    > Perhaps sadly, I do not have time right now to answer them.
    >
    > I will say that the answers to your questions either are or should be
    > answered on http://support.ntp.org .
    >
    > H
    > From - Thu


    Posted Via Usenet.com Premium Usenet Newsgroup Services
    ----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
    ----------------------------------------------------------
    http://www.usenet.com

  6. Re: project ntp.br

    On Thu, 04 Oct 2007 12:59:22 -0300, Antonio M. Moreiras wrote:

    Hi Antonio. I am a relative newbie to ntp but I will give you some
    pointers where I can.

    > Dear Sirs:
    >
    > NIC.br is working on the project ntp.br, that has the goal of improving
    > the quality of time synchronization in (brazilian) Internet hosts and
    > networks and of provide legal brazilian time.


    GREAT IDEA!!

    >
    > Basically we intend to provide stratum 1 and stratum 2 servers,
    > synchronized with legal brazilian time (that is kept by the observatorio
    > nacional - www.on.br - and is, in last instance, UTC).
    >
    > We will have 3 of the following structure (at 3 different sites, at 3
    > different cities: Sao Paulo, Rio de Janeiro, Brasilia):
    >
    > -----------------------------------------------------------
    > Observatorio Nacional (Cesium clock)
    > |
    > |(periodically assures the
    > | accuracy with the official
    > | brazilian time - that is
    > | in last instance UTC)
    > #
    > ** Rubidium clock **
    > ** Stratum 0 **
    > Symmetrycom
    > |
    > |(IRIG)
    > #
    > ** Stratum 1 Server **
    > Appliance Spectracom ------------------
    > or Appliance Symmetrycom |
    > | |(Internet)
    > |(Internet or LAN) |
    > # #
    > ** Stratum 2 Server ** (stratum 2 "clients")
    > cluster with 2 Dell blade servers (autonomous systems)
    > | (big networks)
    > |(Internet)
    > #
    > (stratum 3 "clients")
    > (home users, small
    > and medium networks)
    > -----------------------------------------------------------
    >
    > The Rubidium clocks and stratum 1 servers will be completely independent
    > of each others, but each of the six stratum 2 servers will be
    > synchronized by the three stratum 1 servers.
    >
    > The project will start with 2 complete sites (Sao Paulo, Rio de
    > Janeiro). The third site (Brasilia) will have only the stratum 2
    > servers, and in the next year the Rubidium clock and the stratum 1
    > server will be added.
    >
    > The stratum 2 servers will be open to the Internet, intended to be used
    > by home users, small and medium networks, to synchronize clients or
    > stratum 3 servers..
    >
    > The stratum 1 servers will have their access restricted, intended to be
    > used only by the Autonomous Systems and big networks to syncronize their
    > own stratum 2 servers. We estimate about 600 clients for each stratum 1
    > server.
    >
    >
    > We need some help and advise in the following questions:
    >
    > 1 - Is that a good structure or it needs to be improved or corrected?


    I will let the real experts answer this one.

    > 2 - The Stratum 1 Servers are appliances and do have some limitations at
    > access control configuration. How can we provide access limitation by
    > other means? We are studying the following possibilities:
    > (a) A firewall between the Internet and the Stratum 1 servers, with a
    > per client IP configuration.
    > (b) A vpn (openvpn).
    > What would be better? Is there any other alternative?
    >


    I would thik either one would work just fine and give you the needed
    security. I would prefer (a) using a firewall since it will easily give
    you the flexibility to allow some of your citizens to use the
    Stratum 1 servers.

    e.g. In Canada, NRC provides official Canadian time. NRC does allow
    certain citizens / companies to use the stratum 1 servers but you must
    make a special request. See the NRC website.

    >
    > 3 - About cryptography:
    > - We don´t fully understand the options and implications yet.


    Cryptography in ntp is ONLY used for authentication purposes.
    It does NOT encrypt the time or an other data.
    (Why would one want to make the time secret! :-) )

    > - It seems to complicate a little the client side configuration. We
    > fear that it will desincourage the potencial users.


    Yes, authentication would make life overly complicated for most of your
    citizens and it would be burdensome for the Brazilian government. You
    would need to issue NEW authentication certificates to your users EACH
    year.

    In Canada, I think the NRC has a good policy. If users want the comfort
    and assurance that you are getting time from NRC (and not from some rogue
    impersonating NRC), the user should pay for it. I think NRC charges $110
    for the initial certificate and $50 each year to replace the expired
    certificate.

    For links between your Stratum 1 and Stratum 2 servers, I WOULD use
    authentication as a extra layer of security.

    > - It seems that the majority of the servers at public pool don´t uses it.
    > Then:
    > (a) What are the real risks of not implementing the cryptography?


    For the servers exposed to the public, I don't see any major downsides.
    But a rogue might be able to impersonate your ntp servers and give the
    wrong time. (Very unlikely in my view). But if your users want the
    assurance and comfort that they are getting the time from the Brazil
    government, you will need the use authentication. (But it will be a
    burden to issue new certificates each year. You may want to consider
    charging users who want to use authentication).

    > (b) What is more recommended: Autokey, or symmetrical keys? Why?


    The symmetrical keys approach is weak. There are middleman attacks.

    Autokey is better. (Within autokey, there are various options -- IFF, GQ,
    MV etc. I would aks the experts which is better (assuming there is one
    which is better)).

    > (c) Is it possible to implement cryptography as an optional feature:
    > the server configuration accepts clients with and without cryptography?


    I believe the answer to this is yes. I believe NRC does it with its
    stratum 2 servers (and maybe even its stratum 1 servers).

    I have also set up a ntpd server on a LAN where both authenticated users
    and unauthenticated users can access the ntpd server.

    > 4 - We are experiencing some degree of difficulty to fully understand
    > Autokey. Is there any documentation with a working configuration example?


    Yes. See http://support.ntp.org/bin/view/Supp...iguringAutokey
    This is a great resource. Until I read it, I could never figure out
    autokey.

    > 5 - At the stratum 2 servers, what is the more advisable OS? FreeBSD?
    > OpenBSD? Linux? Windows? We have read something about freebsd being the
    > best choice, but without an explanation.


    NOT windows. Windows does not use NTP. Instead windows uses w32time.
    In my experience, w32time does a POOR job at keeping time. NTP is better.
    You can get a NTP port to run on windows. Even then the NTP port is not
    as good in my view. (I suspect the reason for the poor perforance lies
    with the Windows kernel. It likely does not have mods needed to keep good
    time. Apparently, most, if not all, of the modern Linux and BSD kernel do
    have the needed patches).

    I would think that either Linux or BSD will do equally well at keeping
    time. But I hope the real experts here will answer this question for you.

    If you are really concerned with security, I would go with OpenBSD.

    P.S. I tend to use Linux since I am more comfortable with it.

    >
    > 6 - Regarding monitoring, we intend to use basically adapted versions of
    > the scripts found at http://www.schlitt.net/scripts/ntp/ and at
    > http://saturn.dennishilberg.com/gathering_data.php. But we would also
    > like to have some statistics about quality of the clients
    > synchronization, specially of the stratum 2 servers at the autonomous
    > systems. Maybe get a "ntpq -c pe" for each one from time to time. Any
    > advise regarding this?
    >


    I will let the experts answer this one as well.

    I hope you found my comments uselful -- Rob

    > Sorry for the long post, and thanks in advance.
    >
    > --
    > Antonio M. Moreiras
    > Project Engineer at Brazilian Network Information Center - NIC.br
    > moreiras@nic.br
    > http://www.nic.br
    >
    >
    >
    > Posted Via Usenet.com Premium Usenet Newsgroup Services
    > ----------------------------------------------------------
    > ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
    > ----------------------------------------------------------
    > http://www.usenet.com



  7. Re: project ntp.br - discrepancy from UTC

    Antonio M. Moreiras wrote:
    > The Cesium clock at observatorio nacional (ON) is UTC. In fact, the ON
    > is one of the metrology laboratories that colaborates with the Bureau
    > International des Poids et Measures (BIPM) in generating the UTC (as
    > NIST does in USA, for example).
    >
    > The Rubidium clocks are synchronized with the UTC at least one time per
    > year and the manufacturer says that the Rubidum reference has a monthly
    > aging less than 5e-11 and a yearly aging less than 5e-10.
    >
    > It gives us a 16ms maximum discrepancy from UTC (31,536,000,000 ms/year
    > * 5e-10 * 1 year = 15.765ms - is this correct?)
    >
    > After one year, with the discrepancy at 16ms it will be probabily of the
    > same order than the half round trip time for the majority of the clients.
    >
    > Given this, do you you think it will be necessary any modification?


    Yes.

    An atomic clock with greater than 1 ms offset isn't really worth it's
    name. :-(

    In fact, with such a big slew rate, you would be much, much better off
    with a local GPS receiver to continually tune your Rb source.

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

  8. Re: project ntp.br

    Antonio M. Moreiras wrote:
    > Dear Sirs:
    >
    > NIC.br is working on the project ntp.br, that has the goal of improving
    > the quality of time synchronization in (brazilian) Internet hosts and
    > networks and of provide legal brazilian time.
    >
    > Basically we intend to provide stratum 1 and stratum 2 servers,
    > synchronized with legal brazilian time (that is kept by the observatorio
    > nacional - www.on.br - and is, in last instance, UTC).
    > We will have 3 of the following structure (at 3 different sites, at 3
    > different cities: Sao Paulo, Rio de Janeiro, Brasilia):
    >
    > -----------------------------------------------------------
    > Observatorio Nacional (Cesium clock)
    > |
    > |(periodically assures the
    > | accuracy with the official
    > | brazilian time - that is
    > | in last instance UTC)


    For real time purposes (as NTP), formally this is
    UTC(ONRJ), TA(ONSP) and TA(ONBR) (just formal, no
    practical consequences if only NTP is concerned).

    > #
    > ** Rubidium clock **
    > ** Stratum 0 **
    > Symmetrycom


    I cant see why you need a Rb clock here if UTC(ONRJ)
    (or a slightly degraded version in the case of the
    secondary observatories) is available locally.

    No remark on the structure below stratum 1, but from
    a metrological point of view, in my opinion, the
    complete structure could read like this :

    UTC
    |
    |Circular T BIPM
    |
    |
    UTC(ONRJ) ---------------> NTP st 1, id 0 ---> down to lower strata
    | |
    | peer
    | |
    |__________TA(ONSP) ---> NTP st 1, id 1---> down to lower strata
    | GPS link |
    | peer
    | |
    |__________TA(ONBR) ---> NTP st 1, id 2 ---> down to lower strata
    GPS link

    --
    François Meyer

  9. Re: project ntp.br - discrepancy from UTC

    In article <1191543815_6985@sp12lax.superfeed.net>,
    Antonio M. Moreiras wrote:

    > After one year, with the discrepancy at 16ms it will be probabily of the
    > same order than the half round trip time for the majority of the clients.
    >
    > Given this, do you you think it will be necessary any modification?


    Speaking personally, I would say definitely yes.

    > I don´t know if I correctly understood what this discrepancy can cause.
    > If a client is using other sources attached directly to GPSs, for
    > example, there is a risk that our servers being considered falsetickers.


    It can certainly declare you a falseticker.

    > Is it? Or is there other problems?


    At least for some configurations, it could declare all the external servers
    (maybe all the servers) as falsetickers. It could also hop between the
    two versions of the time.

    > A discrepancy of 16ms in a Internet NTP primary server is acceptable?


    It would exceed modern expectations, even if not necessary for most
    applications. People expect this sort of accuracy on end nodes.

    > The majority of the Internet NTP primary servers are GPS based. For
    > curiosity: what is the discrepancy of GPS time from UTC (without
    > considering the leap seconds)?


    50 nano seconds at about the 50 percentile, is the official specification.
    The constellation needs to be in synch with each other to rather better
    than this for GPS to work at all, although it is not strictly necessary
    that they match UTC. Even if they don't match UTC exactly, the offset
    will be available.

    I seem to remember that typical NTP servers can lock to this to
    microsecond accuracies, although typical network delays will degrade
    this to around 1 ms.


  10. Re: project ntp.br

    François Meyer escreveu:

    > For real time purposes (as NTP), formally this is
    > UTC(ONRJ), TA(ONSP) and TA(ONBR) (just formal, no
    > practical consequences if only NTP is concerned).


    Could you indicate some sources (books, websites) where I could learn
    more about that? We are writing some documentation in portuguese and I
    would like to get all the formalities correctly handled.

    >
    > I cant see why you need a Rb clock here if UTC(ONRJ)
    > (or a slightly degraded version in the case of the
    > secondary observatories) is available locally.
    >


    There are issues regarding the ONRJ Internet connections. Because of
    this, the primary and secondary ntp servers are in other site (althought
    it is also in Rio de Janeiro).

    > No remark on the structure below stratum 1, but from
    > a metrological point of view, in my opinion, the
    > complete structure could read like this :
    >
    > UTC
    > |
    > |Circular T BIPM
    > |
    > |
    > UTC(ONRJ) ---------------> NTP st 1, id 0 ---> down to lower strata
    > | |
    > | peer
    > | |
    > |__________TA(ONSP) ---> NTP st 1, id 1---> down to lower strata
    > | GPS link |
    > | peer
    > | |
    > |__________TA(ONBR) ---> NTP st 1, id 2 ---> down to lower strata
    > GPS link
    >


    Thanks for the suggestion! We are studying alternatives, including this
    one, as we see that our proposed structure have big problems.

    []s
    Antonio M. Moreiras.

    Posted Via Usenet.com Premium Usenet Newsgroup Services
    ----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
    ----------------------------------------------------------
    http://www.usenet.com

  11. Re: ntp.br project - how to calculate the discrepancy?

    David Woolley escreveu:

    >> A discrepancy of 16ms in a Internet NTP primary server is acceptable?

    >
    > It would exceed modern expectations, even if not necessary for most
    > applications. People expect this sort of accuracy on end nodes.


    I have understood that 16ms is unnaceptable and I will review the project.

    But I need help to know, at first, if I calculated this 16ms correctly.

    The rubidum clock manufacturer says that:
    mensal ageing < 5e-11
    anual ageing < 5e-10

    What would be the correct way to calculate the discrepancy in seconds
    after a given elapsed time?

    I calculated the error as 31,536,000,000 ms (1 year) * 5e-10 =
    15.765ms, but I think this is not correct, because the 5e-10 is the
    frequency error after 1 year. This calculation would be correct if the
    5e-10 were a constant frequency error along all the year, what is not
    the case.

    Calculating in a mensal basis (but considering 5e-11 as a constant freq
    error within the month, what is wrong too but with a smaller
    overestimated error):

    Month Accum Ageing Err(ms) Tot Error(ms)
    1 0,00000000005 0,130 0,130
    2 0,00000000010 0,259 0,389
    3 0,00000000015 0,389 0,778
    4 0,00000000020 0,518 1,296
    5 0,00000000025 0,648 1,944
    6 0,00000000030 0,778 2,722
    7 0,00000000035 0,907 3,629
    8 0,00000000040 1,037 4,666
    9 0,00000000045 1,166 5,832
    10 0,00000000050 1,296 7,128
    11 0,00000000055 1,426 8,554
    12 0,00000000060 1,555 10,109

    If this is correct, it means that whith 3 calibrations per year, it
    would be possible to keep the discrepancy < 1ms. And if we calibrate the
    system in a monthly basis, the discrepancy would be less than 150us.

    We are studying, as suggested by some people, using GPS as time
    reference, but one of primary requisites to our project is to have the
    servers in sync with the official brazilian time, that is UTC(ONRJ).

    Considering that we could completely trust the GPS system (can we? it is
    a us military system...) there would be no practical differences, but
    yet there would be some legal differences. So we are looking for
    alternatives to synchronize to UTC(ONRJ) with an acceptable accuracy.

    The studied alternatives include using cesium reference clocks, instead
    of rubidium, or calibrate the rubidium ones within shorter periods of time.

    >> what is the discrepancy of GPS time from UTC (without
    >> considering the leap seconds)?

    >
    > 50 nano seconds at about the 50 percentile, is the official specification.
    > The constellation needs to be in synch with each other to rather better
    > than this for GPS to work at all, although it is not strictly necessary
    > that they match UTC. Even if they don't match UTC exactly, the offset
    > will be available.
    >
    > I seem to remember that typical NTP servers can lock to this to
    > microsecond accuracies, although typical network delays will degrade
    > this to around 1 ms.


    Thanks.

    []s
    Antonio M. Moreiras


    Posted Via Usenet.com Premium Usenet Newsgroup Services
    ----------------------------------------------------------
    ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
    ----------------------------------------------------------
    http://www.usenet.com

  12. Re: project ntp.br

    Antonio M. Moreiras wrote:
    > Dear Sirs:
    >


    > NIC.br is working on the project ntp.br, that has the goal of improving


    > the quality of time synchronization in (brazilian) Internet hosts and


    > networks and of provide legal brazilian time.
    >


    > Basically we intend to provide stratum 1 and stratum 2 servers,


    > synchronized with legal brazilian time (that is kept by the observatorio


    > nacional - www.on.br - and is, in last instance, UTC).
    >


    > We will have 3 of the following structure (at 3 different sites, at 3
    > different cities: Sao Paulo, Rio de Janeiro, Brasilia):
    >



    Does that mean a cesium clock at each site? That would be the best
    implementation.

    > -----------------------------------------------------------
    > Observatorio Nacional (Cesium clock)
    > |
    > |(periodically assures the
    > | accuracy with the official
    > | brazilian time - that is
    > | in last instance UTC)
    > #
    > ** Rubidium clock **
    > ** Stratum 0 **
    > Symmetrycom
    > |
    > |(IRIG)
    > #
    > ** Stratum 1 Server **
    > Appliance Spectracom ------------------
    > or Appliance Symmetrycom |
    > | |(Internet)
    > |(Internet or LAN) |
    > # #
    > ** Stratum 2 Server ** (stratum 2 "clients")
    > cluster with 2 Dell blade servers (autonomous systems)
    > | (big networks)
    > |(Internet)
    > #
    > (stratum 3 "clients")
    > (home users, small
    > and medium networks)
    > -----------------------------------------------------------
    >


    > The Rubidium clocks and stratum 1 servers will be completely independent
    > of each others, but each of the six stratum 2 servers will be


    > synchronized by the three stratum 1 servers.
    >


    > The project will start with 2 complete sites (Sao Paulo, Rio de
    > Janeiro). The third site (Brasilia) will have only the stratum 2
    > servers, and in the next year the Rubidium clock and the stratum 1
    > server will be added.
    >


    > The stratum 2 servers will be open to the Internet, intended to be used
    > by home users, small and medium networks, to synchronize clients or


    > stratum 3 servers..
    >


    > The stratum 1 servers will have their access restricted, intended to be
    > used only by the Autonomous Systems and big networks to syncronize their
    > own stratum 2 servers. We estimate about 600 clients for each stratum 1
    > server.
    >


    >


    > We need some help and advise in the following questions:
    >


    > 1 - Is that a good structure or it needs to be improved or corrected?
    >



    We generally recommend that at least 4 servers are used for each ntp
    node because if one of the servers goes down or become unavailable you
    only have two servers and ntpd has no way of deciding which server is
    providing better time.

    > 2 - The Stratum 1 Servers are appliances and do have some limitations at


    > access control configuration. How can we provide access limitation by


    > other means? We are studying the following possibilities:
    > (a) A firewall between the Internet and the Stratum 1 servers, with a


    > per client IP configuration.
    > (b) A vpn (openvpn).
    > What would be better? Is there any other alternative?
    >



    Don't use a vpn. There are multiple issues with vpn's including that
    they don't work with autokey and you have additional overhead in
    processing packets which leads to additional delays in sending and
    receiving ntp packets.

    Choose a firewall and make sure that you configure it to allow the ntp
    packets in both directions on the 123/UDP port. Also, since you need a
    firewall make sure it supports EDNS0 (for DNS) so that you don't have
    DNS lookup delays as well, though that's a DNS issue rather than a NTP
    issue.

    > 3 - About cryptography:
    > - We don´t fully understand the options and implications yet.
    > - It seems to complicate a little the client side configuration. We


    > fear that it will desincourage the potencial users.


    Authentication is optional for the client. If they don't need to
    authenticate the server they don't need to and they can still use the
    server and get their time service.

    > - It seems that the majority of the servers at public pool don´t use

    s it.
    > Then:
    > (a) What are the real risks of not implementing the cryptography?


    You cannot be assured that the packet is coming from the server that it
    says it is. UDP packets are particularly easy to forge.

    > (b) What is more recommended: Autokey, or symmetrical keys? Why?


    Autokey. You have much greater control over usage, is less susceptible
    to being broken and with the latest changes that Dave has implemented
    you get even more flexibility.

    > (c) Is it possible to implement cryptography as an optional feature:


    > the server configuration accepts clients with and without cryptography?
    >



    Yes. See above. An added benefit is that you can then provide the
    autokeys to paying clients who want to assure themselves that they are
    talking to valid servers that are providing them time service.

    > 4 - We are experiencing some degree of difficulty to fully understand


    > Autokey. Is there any documentation with a working configuration example?
    >



    You need to explain what you are trying to understand. For practical
    implementation I recommend that you visit:
    http://support.ntp.org/bin/view/Supp...iguringAutokey which has a
    lot of detail on how to set up and implement autokey.

    > 5 - At the stratum 2 servers, what is the more advisable OS? FreeBSD?


    > OpenBSD? Linux? Windows? We have read something about freebsd being the


    > best choice, but without an explanation.
    >



    Don't use Windows. Apart from the cost of buying a license for the
    software there's a great deal of overhead in running windows and it
    frequently can lose interrupts. Linux has also been in this position
    though I don't know if that's been fixed. FreeBSD is known to always
    work well, as does Solaris. I'm less clear on the other OS's.

    > 6 - Regarding monitoring, we intend to use basically adapted versions of


    > the scripts found at http://www.schlitt.net/scripts/ntp/ and at


    > http://saturn.dennishilberg.com/gathering_data.php. But we would also


    > like to have some statistics about quality of the clients


    > synchronization, specially of the stratum 2 servers at the autonomous


    > systems. Maybe get a "ntpq -c pe" for each one from time to time. Any


    > advise regarding this?
    >



    One possibility that you could use is to set up an ntp server which has
    a server list of all the servers you want to monitor. Then use ntpq -p
    against that server to get a list of the current status of each server
    that you are interested in.

    Danny
    >


    > Sorry for the long post, and thanks in advance.
    >


    > --
    > Antonio M. Moreiras
    > Project Engineer at Brazilian Network Information Center - NIC.br
    > moreiras@nic.br
    > http://www.nic.br


  13. Re: ntp.br project - how to calculate the discrepancy?

    Antonio M. Moreiras wrote:
    > Calculating in a mensal basis (but considering 5e-11 as a constant freq
    > error within the month, what is wrong too but with a smaller
    > overestimated error):
    >
    > Month Accum Ageing Err(ms) Tot Error(ms)
    > 1 0,00000000005 0,130 0,130
    > 2 0,00000000010 0,259 0,389
    > 3 0,00000000015 0,389 0,778
    > 4 0,00000000020 0,518 1,296
    >
    > If this is correct, it means that whith 3 calibrations per year, it
    > would be possible to keep the discrepancy < 1ms. And if we calibrate the
    > system in a monthly basis, the discrepancy would be less than 150us.
    >
    > We are studying, as suggested by some people, using GPS as time
    > reference, but one of primary requisites to our project is to have the
    > servers in sync with the official brazilian time, that is UTC(ONRJ).


    This is an easy problem to solve: You engineer the system to use a SW
    clock, saving the offset between UTC(GPS) and UTC(BR) on each
    calibration, then in the 1-12 months between those calibrations you use
    the GPS PPS signal to frequency-lock your Rb-supplied time.

    > Considering that we could completely trust the GPS system (can we? it is
    > a us military system...) there would be no practical differences, but
    > yet there would be some legal differences. So we are looking for
    > alternatives to synchronize to UTC(ONRJ) with an acceptable accuracy.


    If you make sure that the maximum slew rate of your Rb oscillator, when
    steered by GPS PPS signals, is something like 2e-10 (twice the specified
    aging rate) or less, then you can "legally" guarantee that you pass out
    time with a maximum error of 64 ms after a year without any calibration
    directly from UTC(BR).

    >
    > The studied alternatives include using cesium reference clocks, instead
    > of rubidium, or calibrate the rubidium ones within shorter periods of time.



    I have another suggestion:

    Instead of calibrating every N months, why not use the same approach as
    is currently used to generate UTC in the first place, and to calibrate
    UTC(BR) vs UTC itself:

    Use common-view observation of the same GPS sats as UTC(BR), this would
    allow you to stay within a small number of ns of your legal reference,
    at all times.

    For a much cheaper/easier alternative: Run your clock with direct GPS
    PPS steering. UTC(BR), which is probably using common-view GPS for time
    transfer anyway, can tell you weekly what the current offset is between
    UTC(USNO) (i.e. GPS time) and UTC(BR).

    I.e. the only thing you require is a way to sound the alarm in your
    national laboratory if UTC(GPS) should ever start to drift, in which
    case you can simply disconnect the GPS PPS signal and allow your NTP
    server to coast along on the internal Rb clock.

    Please notice that even if GPS should ever start drifting, as long as
    the slew rate is less than the free-running slew rate of your Rb clock,
    you are still better off trusting GPS between the visits from your
    UTC(BR) representative!

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

  14. Re: project ntp.br - discrepancy from UTC

    On Oct 5, 2:28 am, "Antonio M. Moreiras"
    wrote:
    >
    > The majority of the Internet NTP primary servers are GPS based. For
    > curiosity: what is the discrepancy of GPS time from UTC (without
    > considering the leap seconds)?


    See the link "GPS Time vs. UTC via USNO Master Clock" at
    http://tycho.usno.navy.mil/gps_datafiles.html.

    Paul


  15. Re: project ntp.br - discrepancy from UTC

    Antonio M. Moreiras wrote:
    > The Cesium clock at observatorio nacional (ON) is UTC. In fact, the ON
    > is one of the metrology laboratories that colaborates with the Bureau
    > International des Poids et Measures (BIPM) in generating the UTC (as
    > NIST does in USA, for example).
    >


    > The Rubidium clocks are synchronized with the UTC at least one time per
    > year and the manufacturer says that the Rubidum reference has a monthly


    > aging less than 5e-11 and a yearly aging less than 5e-10.
    >


    > It gives us a 16ms maximum discrepancy from UTC (31,536,000,000 ms/year


    > * 5e-10 * 1 year = 15.765ms - is this correct?)
    >


    > After one year, with the discrepancy at 16ms it will be probabily of the


    > same order than the half round trip time for the majority of the clients.
    >


    > Given this, do you you think it will be necessary any modification?
    >


    > If so, what would be the maximum discrepancy allowed to not need any


    > modifications? As the primary servers are appliances from Symmetrycom or


    > Spectracom probabily it will be very difficult to get customized


    > firmware versions... Maybe we should study the possibility of


    > synchronize the Rubidium reference clocks more frequently with UTC.
    >


    > I don´t know if I correctly understood what this discrepancy can cause.


    > If a client is using other sources attached directly to GPSs, for


    > example, there is a risk that our servers being considered falsetickers.


    > Is it? Or is there other problems?
    >


    > A discrepancy of 16ms in a Internet NTP primary server is acceptable?
    >


    > In Brazil time stamps should be less than 100ms accurate to be legaly


    > valid (for financial or government institutions, for example). I think


    > it is the same in other parts of the world. Then, 16ms appears to


    > reasonable for an Internet service.
    >


    > The majority of the Internet NTP primary servers are GPS based. For


    > curiosity: what is the discrepancy of GPS time from UTC (without


    > considering the leap seconds)?
    >




    Be aware that GPS is run by US satellites and their clocks are
    synchronized to US UTC provided by the US Government agency NIST. I have
    no idea how this may differ from that provided by the Braziian
    Government ot BIPM for that matter.

    Danny

    > []s
    > Antonio M. Moreiras.


  16. Re: project ntp.br

    Antonio M. Moreiras wrote:
    > François Meyer escreveu:
    >
    > > For real time purposes (as NTP), formally this is
    > > UTC(ONRJ), TA(ONSP) and TA(ONBR) (just formal, no
    > > practical consequences if only NTP is concerned).

    >
    > Could you indicate some sources (books, websites) where I could learn
    > more about that? We are writing some documentation in portuguese and I
    > would like to get all the formalities correctly handled.


    You might want to browse the time section ftp server
    of the BIPM at :

    http://www.bipm.org/jsp/en/TimeFtp.jsp

    The publication section will give you access to a
    wide panel of data (Circular T's, UTC-UTC(k), UTC-
    GPSTime and so on ; note that there is no UTC(GPS),
    but a scale called "GPS time" that is steered to
    within +- 10 ns of UTC(USNO), though official
    specifications are something like 1 us).
    That might give you an ensemble view.

    From a formal point of view, UTC(X) is a physical
    realization of the paper clock UTC. In order to
    deserve its UTC labelling, the clock(s) involved in
    the realization of a UTC(x) is(are) supposed to
    contribute to TAI via the BIPM and UTC(x) is
    supposed to be maintained within +-100 ns of UTC (or
    at least that there is an involvement of the
    institute x to fulfill these specifications).
    Circular T's show that UTC(ONRJ) hax no particular
    concern regarding this.

    Though it might seem easy to achieve, maintaining a
    UTC realization within these bounds is not an easy
    matter since UTC(x) is supposed to be a real time
    realization of a time scale that will only be
    available 1 month later. This generally involves a
    reasonable number of individual clocks and careful
    steering. Just to emphasize that the UTC(x) naming
    is not to be used lightly in a formal context.

    TA(k) (atomic time) is a more generic name that does
    not bear the involvement of a UTC(x) (though TA(x)
    may have a specific meaning in some countries as you
    can see in the section 2 of the circular T : TA(F)
    for example is a paper clock with an optimized
    frequency stability at a few days, while UTC(OP) is
    the real-time french realization of UTC.

    Circular T also shows there is a TA(ONRJ) that
    significantly differs from UTC(ONRJ) (by about 1.5
    us) ; a foot note in circular T 222 reads :

    "(1) ONRJ: TA(ONRJ) is an independent local atomic
    time scale computed by ONRJ."

    Anyway, the point here is that TA(ONSP) and TA(ONBR)
    may well designate the time scale realized by any of
    the atomic clocks present on these sites.

    >>
    >> I cant see why you need a Rb clock here if UTC(ONRJ)
    >> (or a slightly degraded version in the case of the
    >> secondary observatories) is available locally.
    >>

    >
    > There are issues regarding the ONRJ Internet connections. Because of
    > this, the primary and secondary ntp servers are in other site (althought
    > it is also in Rio de Janeiro).


    Ok. That does not simplify things. Formally you
    cannot rely on GPS Time as a source of traceability
    to UTC(ONRJ). In the international GPS comparisons
    used by the BIPM, GPS is just an intermediate ; the
    obvious solution is a 'CGGTTS aware' GPS receiver
    that can output files following the BIPM schedule ;
    this will give you the possibility to continuously
    monitor your Rb clocks vs UTC(ONRJ) and to maintain
    the difference in a given interval of say +- 100
    us). The need for yearly calibration with a clock
    travel or something similar disappears and after two
    years the investment in the GPS receivers is wiped
    out at the cost of some additionnal procedures to
    ensure both proper monitoring of the systems and
    data processing.

    --
    François Meyer

  17. Re: ntp.br project - how to calculate the discrepancy?

    Antonio,

    Look carefully at your rubidium oscillator manual. A rubidium oscillator
    is not a primary standard and must be adjusted with respect to a primary
    standard such as a Cesium oscillator. Assuming that has been done by the
    manufacturer, the limits you state are on the departure (mostly ageing)
    from the nominal frequency. At an ageing rate of 5e-10, the error after
    one year is about 15 ms.

    Dave

    Antonio M. Moreiras wrote:
    > David Woolley escreveu:
    >
    >>> A discrepancy of 16ms in a Internet NTP primary server is acceptable?

    >>
    >>
    >> It would exceed modern expectations, even if not necessary for most
    >> applications. People expect this sort of accuracy on end nodes.

    >
    >
    > I have understood that 16ms is unnaceptable and I will review the project.
    >
    > But I need help to know, at first, if I calculated this 16ms correctly.
    >
    > The rubidum clock manufacturer says that:
    > mensal ageing < 5e-11
    > anual ageing < 5e-10
    >
    > What would be the correct way to calculate the discrepancy in seconds
    > after a given elapsed time?
    >
    > I calculated the error as 31,536,000,000 ms (1 year) * 5e-10 =
    > 15.765ms, but I think this is not correct, because the 5e-10 is the
    > frequency error after 1 year. This calculation would be correct if the
    > 5e-10 were a constant frequency error along all the year, what is not
    > the case.
    >
    > Calculating in a mensal basis (but considering 5e-11 as a constant freq
    > error within the month, what is wrong too but with a smaller
    > overestimated error):
    >
    > Month Accum Ageing Err(ms) Tot Error(ms)
    > 1 0,00000000005 0,130 0,130
    > 2 0,00000000010 0,259 0,389
    > 3 0,00000000015 0,389 0,778
    > 4 0,00000000020 0,518 1,296
    > 5 0,00000000025 0,648 1,944
    > 6 0,00000000030 0,778 2,722
    > 7 0,00000000035 0,907 3,629
    > 8 0,00000000040 1,037 4,666
    > 9 0,00000000045 1,166 5,832
    > 10 0,00000000050 1,296 7,128
    > 11 0,00000000055 1,426 8,554
    > 12 0,00000000060 1,555 10,109
    >
    > If this is correct, it means that whith 3 calibrations per year, it
    > would be possible to keep the discrepancy < 1ms. And if we calibrate the
    > system in a monthly basis, the discrepancy would be less than 150us.
    >
    > We are studying, as suggested by some people, using GPS as time
    > reference, but one of primary requisites to our project is to have the
    > servers in sync with the official brazilian time, that is UTC(ONRJ).
    >
    > Considering that we could completely trust the GPS system (can we? it is
    > a us military system...) there would be no practical differences, but
    > yet there would be some legal differences. So we are looking for
    > alternatives to synchronize to UTC(ONRJ) with an acceptable accuracy.
    >
    > The studied alternatives include using cesium reference clocks, instead
    > of rubidium, or calibrate the rubidium ones within shorter periods of time.
    >
    >>> what is the discrepancy of GPS time from UTC (without considering the
    >>> leap seconds)?

    >>
    >>
    >> 50 nano seconds at about the 50 percentile, is the official
    >> specification.
    >> The constellation needs to be in synch with each other to rather better
    >> than this for GPS to work at all, although it is not strictly necessary
    >> that they match UTC. Even if they don't match UTC exactly, the offset
    >> will be available.
    >>
    >> I seem to remember that typical NTP servers can lock to this to
    >> microsecond accuracies, although typical network delays will degrade
    >> this to around 1 ms.

    >
    >
    > Thanks.
    >
    > []s
    > Antonio M. Moreiras
    >
    >
    > Posted Via Usenet.com Premium Usenet Newsgroup Services
    > ----------------------------------------------------------
    > ** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
    > ----------------------------------------------------------
    > http://www.usenet.com


  18. Re: project ntp.br - discrepancy from UTC

    Guys,

    To be accurate, there are two national timescales in the US, UTC(USNO)
    kept by the US Naval Observatory in Washington, DC, and UTC(NIST), kept
    by the National Institute of Standards and Technology in Boulder, CO. I
    am told the holy grail is to discipline these timescales with each other
    and other standards laboratories within one nanosecond. Twenty years ago
    the grail was one microsecond and may still be in some parts of the world.

    With an ageing rate of 5e-11, the residual error after one day is 4.3
    microseconds, somewhat more than would ordinarily be expected of a
    national timescale. Our dedicated public NTP primary servers here
    typically keep within this nominal offset and jitter relative to a GPS
    with PPS.

    Other timescales derived from UTC(USNO) include UTC(LORAN) and GPS. GPS
    does not run on UTC and has no leap seconds. It runs on International
    Atomic Time (TAI) with a 5-s constant offset. However, what you see in
    your GPS receiver is UTC as corrected by the GPS navigation message.

    Dave

    Danny Mayer wrote:

    > Antonio M. Moreiras wrote:
    >
    >>The Cesium clock at observatorio nacional (ON) is UTC. In fact, the ON
    >>is one of the metrology laboratories that colaborates with the Bureau
    >>International des Poids et Measures (BIPM) in generating the UTC (as
    >>NIST does in USA, for example).
    >>

    >
    >
    >>The Rubidium clocks are synchronized with the UTC at least one time per
    >>year and the manufacturer says that the Rubidum reference has a monthly

    >
    >
    >>aging less than 5e-11 and a yearly aging less than 5e-10.
    >>

    >
    >
    >>It gives us a 16ms maximum discrepancy from UTC (31,536,000,000 ms/year

    >
    >
    >>* 5e-10 * 1 year =5.765ms - is this correct?)
    >>

    >
    >
    >>After one year, with the discrepancy at 16ms it will be probabily of the

    >
    >
    >>same order than the half round trip time for the majority of the clients.
    >>

    >
    >
    >>Given this, do you you think it will be necessary any modification?
    >>

    >
    >
    >>If so, what would be the maximum discrepancy allowed to not need any

    >
    >
    >>modifications? As the primary servers are appliances from Symmetrycom or

    >
    >
    >>Spectracom probabily it will be very difficult to get customized

    >
    >
    >>firmware versions... Maybe we should study the possibility of

    >
    >
    >>synchronize the Rubidium reference clocks more frequently with UTC.
    >>

    >
    >
    >>I don´t know if I correctly understood what this discrepancy can cause.

    >
    >
    >>If a client is using other sources attached directly to GPSs, for

    >
    >
    >>example, there is a risk that our servers being considered falsetickers.

    >
    >
    >>Is it? Or is there other problems?
    >>

    >
    >
    >>A discrepancy of 16ms in a Internet NTP primary server is acceptable?
    >>

    >
    >
    >>In Brazil time stamps should be less than 100ms accurate to be legaly

    >
    >
    >>valid (for financial or government institutions, for example). I think

    >
    >
    >>it is the same in other parts of the world. Then, 16ms appears to

    >
    >
    >>reasonable for an Internet service.
    >>

    >
    >
    >>The majority of the Internet NTP primary servers are GPS based. For

    >
    >
    >>curiosity: what is the discrepancy of GPS time from UTC (without

    >
    >
    >>considering the leap seconds)?
    >>

    >
    >
    >
    >
    > Be aware that GPS is run by US satellites and their clocks are
    > synchronized to US UTC provided by the US Government agency NIST. I have
    > no idea how this may differ from that provided by the Braziian
    > Government ot BIPM for that matter.
    >
    > Danny
    >
    >
    >>[]s
    >>Antonio M. Moreiras.

    >
    >


  19. Re: project ntp.br - discrepancy from UTC

    One possibly relevant note is that a lot of standard/metrology labs
    don't ever adjust their oscillators, but instead monitor the rate and
    deal with that in data reduction. There are a bunch of good reasons
    (some of which were recently discussed over on time-nuts) such as
    maintaining continuity of data, hysteresis and other bad effects from
    making adjustments, etc.

    Modern Cs and Masers have synthesizers that can adjust frequency, rather
    than brute-force adjustment of magnetic fields that older units require.
    But even in that case, there may be reasons to leave the thing alone
    once it's put into service. (There are also nifty devices like
    microsteppers that can slew the phase of an input signal at rates of
    pico (or femto) seconds per second).

    So the lab may be very happy with those Rbs, even if their raw PPS is
    off by a microsecond a week.

    John
    ----

    David L. Mills wrote:
    > Guys,
    >
    > To be accurate, there are two national timescales in the US, UTC(USNO)
    > kept by the US Naval Observatory in Washington, DC, and UTC(NIST), kept
    > by the National Institute of Standards and Technology in Boulder, CO. I
    > am told the holy grail is to discipline these timescales with each other
    > and other standards laboratories within one nanosecond. Twenty years ago
    > the grail was one microsecond and may still be in some parts of the world.
    >
    > With an ageing rate of 5e-11, the residual error after one day is 4.3
    > microseconds, somewhat more than would ordinarily be expected of a
    > national timescale. Our dedicated public NTP primary servers here
    > typically keep within this nominal offset and jitter relative to a GPS
    > with PPS.
    >
    > Other timescales derived from UTC(USNO) include UTC(LORAN) and GPS. GPS
    > does not run on UTC and has no leap seconds. It runs on International
    > Atomic Time (TAI) with a 5-s constant offset. However, what you see in
    > your GPS receiver is UTC as corrected by the GPS navigation message.


  20. Re: project ntp.br - discrepancy from UTC

    John,

    Thanks for the headsup. I have three Cs clocks, all of which predate
    GPS. However, two of the three have expired tubes and I nurse the third
    by only occasionally switching the beam on. For awhile I was buying used
    tubes, but now GPS sans SA is so good I don't need the Cs clocks. I do
    have a Rb oscillator, but I use that primarily to calibrate the
    frequency synthesizers for my radios.

    If I were running a cesium farm I wouldn't want to adjust the clocks
    either and would rather run a paper timescale. This means that GPS,
    LORAN-C and simiilar services have to run their own cesia and microsteppers.

    Once upon a time it was tough to get a really good local UTC lab
    standard. Before GPS I used LORAN-C; before that I used WWV, CHU, WWVB
    and Omega. The first NTP servers used the power line, which is
    synchronized within a few seconds east of the Rockies except Texas. My
    how things have changed since then.

    Good cheer.

    Dave

    John Ackermann N8UR wrote:

    > One possibly relevant note is that a lot of standard/metrology labs
    > don't ever adjust their oscillators, but instead monitor the rate and
    > deal with that in data reduction. There are a bunch of good reasons
    > (some of which were recently discussed over on time-nuts) such as
    > maintaining continuity of data, hysteresis and other bad effects from
    > making adjustments, etc.
    >
    > Modern Cs and Masers have synthesizers that can adjust frequency,
    > rather than brute-force adjustment of magnetic fields that older units
    > require. But even in that case, there may be reasons to leave the
    > thing alone once it's put into service. (There are also nifty devices
    > like microsteppers that can slew the phase of an input signal at rates
    > of pico (or femto) seconds per second).
    >
    > So the lab may be very happy with those Rbs, even if their raw PPS is
    > off by a microsecond a week.
    >
    > John
    > ----
    >
    > David L. Mills wrote:
    >
    >> Guys,
    >>
    >> To be accurate, there are two national timescales in the US,
    >> UTC(USNO) kept by the US Naval Observatory in Washington, DC, and
    >> UTC(NIST), kept by the National Institute of Standards and Technology
    >> in Boulder, CO. I am told the holy grail is to discipline these
    >> timescales with each other and other standards laboratories within
    >> one nanosecond. Twenty years ago the grail was one microsecond and
    >> may still be in some parts of the world.
    >>
    >> With an ageing rate of 5e-11, the residual error after one day is 4.3
    >> microseconds, somewhat more than would ordinarily be expected of a
    >> national timescale. Our dedicated public NTP primary servers here
    >> typically keep within this nominal offset and jitter relative to a
    >> GPS with PPS.
    >>
    >> Other timescales derived from UTC(USNO) include UTC(LORAN) and GPS.
    >> GPS does not run on UTC and has no leap seconds. It runs on
    >> International Atomic Time (TAI) with a 5-s constant offset. However,
    >> what you see in your GPS receiver is UTC as corrected by the GPS
    >> navigation message.

    >
    >


+ Reply to Thread
Page 1 of 2 1 2 LastLast