PSN-L Email List Message
Subject: Re: Network time standard
From: ian ian@...........
Date: Sun, 10 Apr 2005 08:40:50 +0100
Hi,
an interesting discussion. I note that a spec of <0.1 seconds has been
mentioned (below). Could I ask, how is this derived? Apologies if this
is documented somewhere on the psn site.
I only ask because I know that using specs that are higher than needed
can lead to costs that could have been avoided. I guess one would start
by determining what is a reasonable error in calculating epicentre
distance that can be tolerated and working back from there to derive a
time spec.
Another question is, which of the many factors influencing epicentre
calculation is the limiting one? I would imagine that the average speed
from the epicentre to a psn station would vary from station to station
since each station is (obviously) located on a different part of the
Earth and (presumably) the wave will travel through different parts of
the Earth at a slightly different speed for each direction.
If all the psn stations were locked in time to less than 0.1 seconds,
then the average speed of the wave would have to be no worse than this
for the data to benefit. For a teleseismic event which took, say, 15
minutes to arrive, all the "rays" would have to travel at the same
average speed to within about 0.01% of each other. Is this possible?!
Ian Smith
ChrisAtUpw@....... wrote:
> In a message dated 10/04/2005, shammon1@............. writes:
>
> My experience when working for TrueTime (Now a division of
> Symmetricom) was that you could achieve 10 milliseconds or so if
> the server was not too far away on the public internet. If you
> run a local time service on your own network, the timing is much
> better than that. It usually takes several messages to get there
> due to the filtering. Also, true NTP will perform much better if
> you give it more than one server to work with. The software makes
> some attempt to evaluate the stability of each source and choose
> the best.
>
> Hi Keith,
>
> I think that we maybe in danger of comparing grapes with bananas,
> if we are not careful. There is a fixed cycle time for the interrupt
> polling in a computer, both for the communications interface and for
> the program switching. Your multi tasking computer still only runs one
> program at a time - it just looks more capable since every cycle it
> polls a list to determine which are active. On one of the old IBM type
> computers that I checked, this was about every 10 milli sec, but it is
> likely to be more frequent on the current offerings. There are also
> different levels of interrupt priority.
> Then there are network response delays and digital transmission
> delays. Local phone networks are likely to be more accurate. I have
> measured transmission delays of 3 sec from the NIST clock over the
> internet to the 60 KHz radio time, but that was exceptional. The on
> line clock seems to have stated error bands of 0.5 to over 1.5 sec.
>
> I asked Steve what was the absolute accuracy that he had measured
> over the network time servers, but he didn't seem to fully understand
> my question. I quite believe that his own internal GPS network can
> detect a 1 mS error, but this is not an indication of how badly the
> network time servers and the communications programs are performing in
> practice.
>
> If you don't have a GPS, as I said, the software comes with an
> extensive
> list of network time servers that can be accessed via the Internet
> to obtain
> accurate time. Overall, the experience with this software package
> has been
> very positive and after 30-days of testing I'm now recommending it
> to other
> members of the Public Seismic Network.
>
> Does it give any timing accuracies in milli seconds for the
> various time servers?
>
> We do need to get a reasonable approximation to Universal Time,
> say better than 0.1 sec and this needs to be maintained at all times.
> We also need to remember that our filters can give very significant
> delays. A 6 pole 10 Hz Butterworth filter peaks at about 100 mS. A 6
> pole 10 Hz Bessel gives about 40 mS. However, if you reduce the
> cut-off to 1.5 Hz, the figures are about 500 and 260 mS respectively.
> Part of this difference is the result of defining the cut-off as the 3
> dB point, rather than matching up the ultimate slopes. The P waves may
> roll in at ~10 Km / sec.
>
> We wouldn't be having this discussion if computers were fitted
> with reasonably accurate clocks. The 4.194 MHz timing crystals can be
> trimmed to a few seconds per fortnight, but high precision temperature
> tracking modules can give 0.1 ppm. The lousy apology for a clock
> fitted to my current computer has drifted 8 sec in the last 2 hours.
> Even hourly updates would not give me anywhere near the precision
> required. You used to be able to buy boards with clock modules on
> them, but I haven't seen any about lately.
>
> Since you can get 60 KHz receiver modues and aerials, it would be
> helpful if A/D boards were able to read and update their clocks
> directly using WWVB signals. This should be maybe 1/3 the cost of a
> GPS system and you would not be dependant on having a permanent phone
> connection.
>
> Regards,
>
> Chris Chapman
Hi,
an interesting discussion. I note that a spec of <0.1 seconds has
been mentioned (below). Could I ask, how is this derived? Apologies
if this is documented somewhere on the psn site.
I only ask because I know that using specs that are higher than needed
can lead to costs that could have been avoided. I guess one would
start by determining what is a reasonable error in calculating
epicentre distance that can be tolerated and working back from there to
derive a time spec.
Another question is, which of the many factors influencing epicentre
calculation is the limiting one? I would imagine that the average
speed from the epicentre to a psn station would vary from station to
station since each station is (obviously) located on a different part
of the Earth and (presumably) the wave will travel through different
parts of the Earth at a slightly different speed for each direction.
If all the psn stations were locked in time to less than 0.1 seconds,
then the average speed of the wave would have to be no worse than this
for the data to benefit. For a teleseismic event which took, say, 15
minutes to arrive, all the "rays" would have to travel at the same
average speed to within about 0.01% of each other. Is this possible?!
Ian Smith
ChrisAtUpw@....... wrote:
My experience when working
for TrueTime (Now a division of Symmetricom) was that you could achieve
10 milliseconds or so if the server was not too far away on the public
internet. If you run a local time service on your own network, the
timing is much better than that. It usually takes several messages to
get there due to the filtering. Also, true NTP will perform much
better if you give it more than one server to work with. The software
makes some attempt to evaluate the stability of each source and choose
the best.
Hi Keith,
I think that we maybe in danger of comparing grapes with
bananas, if we are not careful. There is a fixed cycle time for the
interrupt polling in a computer, both for the communications interface
and for the program switching. Your multi tasking computer still only
runs one program at a time - it just looks more capable since every
cycle it polls a list to determine which are active. On one of the old
IBM type computers that I checked, this was about every 10 milli sec,
but it is likely to be more frequent on the current offerings. There
are also different levels of interrupt priority.
Then there are network response delays and digital
transmission delays. Local phone networks are likely to be more
accurate. I have measured transmission delays of 3 sec from the NIST
clock over the internet to the 60 KHz radio time, but that was
exceptional. The on line clock seems to have stated error bands of 0.5
to over 1.5 sec.
I asked Steve what was the absolute accuracy that he had
measured over the network time servers, but he didn't seem to fully
understand my question. I quite believe that his own internal GPS
network can detect a 1 mS error, but this is not an
indication of how badly the network time servers and the
communications programs are performing in practice.
If you don't have a GPS, as I said, the software comes with
an extensive
list of network time servers that can be accessed via the Internet to
obtain
accurate time. Overall, the experience with this software package has
been
very positive and after 30-days of testing I'm now recommending it to
other
members of the Public Seismic Network.
Does it give any timing accuracies in milli seconds for the
various time servers?
We do need to get a reasonable approximation to Universal
Time, say better than 0.1 sec and this needs to be maintained at
all times. We also need to remember that our filters can
give very significant delays. A 6 pole 10 Hz Butterworth filter peaks
at about 100 mS. A 6 pole 10 Hz Bessel gives about 40 mS. However, if
you reduce the cut-off to 1.5 Hz, the figures are about 500 and 260 mS
respectively. Part of this difference is the result of defining the
cut-off as the 3 dB point, rather than matching up the ultimate slopes.
The P waves may roll in at ~10 Km / sec.
We wouldn't be having this discussion if computers were
fitted with reasonably accurate clocks. The 4.194 MHz timing crystals
can be trimmed to a few seconds per fortnight, but high precision
temperature tracking modules can give 0.1 ppm. The lousy apology for a
clock fitted to my current computer has drifted 8 sec in the last 2
hours. Even hourly updates would not give me anywhere near
the precision required. You used to be able to buy boards with clock
modules on them, but I haven't seen any about lately.
Since you can get 60 KHz receiver modues and aerials, it
would be helpful if A/D boards were able to read and update their
clocks directly using WWVB signals. This should be maybe 1/3 the cost
of a GPS system and you would not be dependant on having a permanent
phone connection.
Regards,
Chris Chapman
[ Top ]
[ Back ]
[ Home Page ]