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    






In a message dated 10/04/2005, shammon1@............. writes:
<=
FONT=20
  style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size=
=3D2>My experience when working for TrueTime (Now a=20
  division of Symmetricom) was that you could achieve 10 milliseconds or so=20=
if=20
  the server was not too far away on the public internet.  If you run a=
=20
  local time service on your own network, the timing is much better than=20
  that.  It usually takes several messages to get there due to the=20
  filtering.  Also, true NTP will perform much better if you give it mo=
re=20
  than one server to work with.  The software makes some attempt to=20
  evaluate the stability of each source and choose the=20
best.

Hi Keith,
 
    I think that we maybe in danger of comparing gr=
apes=20
with bananas, if we are not careful. There is a fixed cycle time for the=20
interrupt polling in a computer, both for the communications interface and f=
or=20
the program switching. Your multi tasking computer still only runs one progr=
am=20
at a time - it just looks more capable since every cycle it polls a list to=20
determine which are active. On one of the old IBM type computers that I=
=20
checked, this was about every 10 milli sec, but it is likely to be more=
=20
frequent on the current offerings. There are also different levels of interr=
upt=20
priority. 
    Then there are network response delays and digi=
tal=20
transmission delays. Local phone networks are likely to be more accurat=
e. I=20
have measured transmission delays of 3 sec from the NIST clock over the inte=
rnet=20
to the 60 KHz radio time, but that was exceptional. The on line clock s=
eems=20
to have stated error bands of 0.5 to over 1.5 sec.   
 
    I asked Steve what was the absolute accuracy th=
at=20
he had measured over the network time servers, but he didn't seem to fully=20
understand my question. I quite believe that his own internal GPS network ca=
n=20
detect a 1 mS error, but this is not an=20
indication of how badly the network time servers and the=20
communications programs are performing in practice. 

<=
FONT=20
  style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000 size=
=3D2>If you=20
  don't have a GPS, as I said, the software comes with an extensive
list=20=
of=20
  network time servers that can be accessed via the Internet to=20
  obtain
accurate time. Overall, the experience with this software packag=
e=20
  has been
very positive and after 30-days of testing I'm now recommendin=
g it=20
  to other
members of the Public Seismic Network.


    Does it give any timing accuracies in mill=
i=20
seconds for the various time servers? 
 
    We do need to get a reasonable approximati=
on=20
to Universal Time, say better than 0.1 sec and this needs to be maintained=20
at all times. We also need to remember that o=
ur=20
filters can give very significant delays. A 6 pole 10 Hz Butterworth filter=20
peaks at about 100 mS. A 6 pole 10 Hz Bessel gives about 40 mS. However, if=20=
you=20
reduce the cut-off to 1.5 Hz, the figures are about 500 and 260 mS respectiv=
ely.=20
Part of this difference is the result of defining the cut-off as the 3=20=
dB=20
point, rather than matching up the ultimate slopes. The P waves may roll in=20=
at=20
~10 Km / sec.
 
    We wouldn't be having this discussion if comput=
ers=20
were fitted with reasonably accurate clocks. The 4.194 MHz timing crystals c=
an=20
be trimmed to a few seconds per fortnight, but high precision temperature=20
tracking modules can give 0.1 ppm. The lousy apology for a clock fitted=
 to=20
my current computer has drifted 8 sec in the last 2 hours. Even hourly updat=
es=20
would not give me anywhere near=20
the precision required. You used to be able to buy boards with clo=
ck=20
modules on them, but I haven't seen any about lately.
 
    Since you can get 60 KHz receiver modues and=20
aerials, it would be helpful if A/D boards were able to read and update thei=
r=20
clocks directly using WWVB signals. This should be maybe 1/3 the cost o=
f a=20
GPS system and you would not be dependant on having a permanent phone=20
connection.
 
    Regards,
 
    Chris=20
Chapman