To All,
How do you demonstrate the traceability of the NTP solution to BIPM
UTC?
Tom R
|
|
0
|
|
|
|
Reply
|
Tom
|
3/12/2009 4:06:20 PM |
|
Tom <tom_e_tek@hotmail.com> writes:
>To All,
>How do you demonstrate the traceability of the NTP solution to BIPM
>UTC?
That is what the stratum is all about. It tells you how far away your clock
is, in terms of servers, from some server which claims to synchronized by a
hardware type clock to UTC. The root dispersion is a conservative estimate
of how far off yo ucould be.
Of course it is possible that your particular route is such that at its
base is a refclock which is someone looking at his $10 wristwatch.
There is no guarentee that the stratum 1 source to which your machine can
trace its time is a good source, but if you have multiple sources, the
chances are high that that one will be regarded as a false ticker.
>Tom R
|
|
0
|
|
|
|
Reply
|
Unruh
|
3/12/2009 5:12:15 PM
|
|
Tom wrote:
> To All,
>
> How do you demonstrate the traceability of the NTP solution to BIPM
> UTC?
>
> Tom R
Most of us do not trace anything to BIPM (Bureau International des Poids
et Mesures). Those of us who live and work in the U.S.A. would usually
be satisfied to trace their time to NIST (National Institute of
Standards and Technology).
FWIW, I believe that most national standards agencies operate their own
atomic clocks which are synchronized with each other and with the BIPM.
|
|
0
|
|
|
|
Reply
|
Richard
|
3/12/2009 8:00:41 PM
|
|
Tom wrote:
> To All,
>
> How do you demonstrate the traceability of the NTP solution to BIPM
> UTC?
>
> Tom R
You can use ntptrace to get to the stratum 1 server if that's what you
are asking. The stratum 1 server gets its time in various ways from a
refclock depending on what that server is connected to.
Is that what you are after?
Danny
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
|
|
0
|
|
|
|
Reply
|
mayer
|
3/12/2009 8:29:15 PM
|
|
On Thu, Mar 12, 2009 at 11:06 AM, Tom <tom_e_tek@hotmail.com> wrote:
> To All,
>
> How do you demonstrate the traceability of the NTP solution to BIPM
> UTC?
>
For "hard" tracability, you really need your own reference clock
(typically GPS) that you control, along with several internet based
sources as a sanity check against it.
If you don't want a reference clock, but want "tracable" time from
internet-based sources, you need to use some form of NTP
authentication. Typically, this means sharing a "signing" key with at
least one (more are better) upstream servers run by organizations that
are known to provide good time tracable to UTC. The NTP Autokey
protocol was designed to do this without sharing secrets, but is not
widely used, and does not work if there is network address translation
involved.
Is this a regulatory requirement? If so, what nation/regulation are we
talking about? Some may require the use of a local reference clock of
some type.
In the USA, for eample, you may be able to get authenticated time
directly from NIST:
http://tf.nist.gov/service/auth_ntp.htm
--
RPM
|
|
0
|
|
|
|
Reply
|
malayter
|
3/12/2009 10:00:39 PM
|
|
On Mar 12, 10:06=A0am, Tom <tom_e_...@hotmail.com> wrote:
> To All,
>
> How do you demonstrate the traceability of the NTP solution to BIPM
> UTC?
>
Hello,
This is a rather complicated question. The answer depends on these
preliminary issues:
1. Do you need technical traceability, which would be adequate to
provide a time reference derived from national time standards or do
you need *legal* traceability in which you must be prepared to
convince
a jury in an adversary proceeding that your time was correct at some
instant?
2. What level of accuracy/uncertainty do you need in the time
stamps?
3. What level of reliability do you need in the process? That is,
suppose
the system that provided the time stamps were to fail. How long could
you
wait for it to be repaired?
4. Each of these questions is going to have a cost/benefit trade-
off.
How much are you willing to spend (in time or money or ...) to achieve
your requirement?
I would be happy to discuss these issues in this forum or off-line.
Judah Levine
Time and Frequency Division
NIST Boulder
|
|
0
|
|
|
|
Reply
|
jlevine
|
3/13/2009 1:58:35 PM
|
|
Until it gets too far afield, wouldn't this be an appropriate discussion
for the forum? I have been asked the same question (sort of) before and
could only give a rudimentary response based on a lot of my own
assumptions.
Phil
> I would be happy to discuss these issues in this forum or off-line.
|
|
0
|
|
|
|
Reply
|
Phil
|
3/13/2009 4:22:18 PM
|
|
>>> In article <9d204ee3-1274-490e-b4af-e21ba41d20a3@g38g2000yqd.googlegroups.com>, jlevine <jlevine@boulder.nist.gov> writes:
jlevine> On Mar 12, 10:06=A0am, Tom <tom_e_...@hotmail.com> wrote:
>> To All,
>>=20
>> How do you demonstrate the traceability of the NTP solution to BIPM UTC?
>>=20
jlevine> Hello, This is a rather complicated question. The answer depends on
jlevine> these preliminary issues:
jlevine> 1. Do you need technical traceability, which would be adequate
jlevine> to provide a time reference derived from national time standards or
jlevine> do you need *legal* traceability in which you must be prepared to
jlevine> convince a jury in an adversary proceeding that your time was
jlevine> correct at some instant? 2. What level of accuracy/uncertainty do
jlevine> you need in the time stamps? 3. What level of reliability do you
jlevine> need in the process? That is, suppose the system that provided the
jlevine> time stamps were to fail. How long could you wait for it to be
jlevine> repaired? 4. Each of these questions is going to have a
jlevine> cost/benefit trade- off. How much are you willing to spend (in
jlevine> time or money or ...) to achieve your requirement? I would be
jlevine> happy to discuss these issues in this forum or off-line.
I'd be very happy to see this discussed here, and I'm happy to work on
getting this information onto appropriate pages at support.ntp.org .
--=20
Harlan Stenn <stenn@ntp.org>
http://ntpforum.isc.org - be a member!
|
|
0
|
|
|
|
Reply
|
Harlan
|
3/14/2009 6:34:41 AM
|
|
Hello,
> I'd be very happy to see this discussed here, and I'm happy to work on
> getting this information onto appropriate pages at support.ntp.org .
As used by the standards community, "traceability" means that there
is an unbroken chain of measurements from the end-user application
back to a national measurement institute or timing laboratory. In the
US,
this means either NIST or the US Naval Observatory. Each link in the
chain must be evaluated and characterized with an uncertainty.
In the case of timing, this evaluation must included the offset and
jitter in the application that receives a time stamp from a system
clock and applies it to some event. Any time jitter in the detection
of the
event must also be included. This evaluation must generally be
ongoing,
since the characteristics of the links may change with time.
The overall uncertainty in the process is typically computed as the
square root of the sum of the squares of the individual uncertainties.
The consequence of this method is that the largest uncertainty tends
to dominate the result, and improving links whose uncertainties are
already small tends to have only a small effect on the result.
"Technical" traceability is a weaker concept. It generally means
that a user has followed generally accepted practices and is using
a method that has been tested in other configurations. However, the
actual system that links the final application to the national
metrology
insittute or timing laboratory has not been evaluated. The implicit
assumption is that the user has implemented the method correctly,
that all of the links are functioning properly, and that the system is
typical of others using the same method.
"Legal" traceability is a stronger concept. It means that the
user has implemented traceability and in addition has added
reporting and monitoring functions so that it is possible to
prove traceability in a legal adversary procedure. In general,
the user will have to maintain log files to prove traceability
at some point in the past.
It is also possible to establish traceability using a
disinterested
third party to monitor the system. For example, NIST has a number
of agreements to monitor remote systems and provide periodic
reports. These agreements are based on the individual requirements
of the user, and the cost depends on the details of the procedure.
The question of how much of this any user should implement must
be decided based on the user's requirements. In particular, a user
who needs "legal" traceability should get professional legal advice.
I am happy to answer more specific questions either through this
forum
or by direct e-mail. However, it may be difficult to provde
quantitative answers
about a configuration without a more detailed analysis. If you need
this sort
of detailed study, you will probably have to pay for it.
Judah Levine
Time and Frequency Division
NIST Boulder
|
|
0
|
|
|
|
Reply
|
jlevine
|
3/16/2009 2:58:49 PM
|
|
|
8 Replies
168 Views
(page loaded in 0.134 seconds)
|