PSN-L Message - Subject: RE: Network time standard

Hi Chris, sorry for note being more direct. >> Does it give any timing accuracies in milli seconds for the various time servers? To answer your question, no it does not. The best analysis I could provide you was within a few milliseconds which I know is not that accurate and that was by estimating and deduction as I stated. The software does not provide a means for that level of analysis. However, if you read the help file I attached, you will see that it attempts to determine the network delay and adjust the clock accordingly. It would be nice if the software posted the information or facilitated a means to measure it. But it does not. Once again I will state, because I'm certain you don't understand, this software package is a simple network time standard for keeping "all" the systems on your network in time. I now realized that any confusion is due to my weak usage statement. I think you believed that I intended the software to provide a detailed time standard for a seismic system without a GPS. I did not. I originally stated that the software was compatible with WinSDR using a Motorola GPS for providing a time standard for the PC's in your network. It has solved all my network time issues with having file dates and times over/under and even days off and I'm very happy with its compatibility with WinSDR. That's why I think it does the job. In reading your analysis below, I have to agree with you that the PC hardware impact the results and my experience tells me that every PC has been different and will drift accordingly. In the past, I used Right Time which had a self learning feature to help resolve PC clock drift. It accuracy was close, but no banana... When I converted to WinSDR, I thought I would use the HP 58503A. It has a frequency accuracy when locked to better than 1 X 10 to the -12th for a one day average from 0 to 50 degrees C. However, because of software incompatibility, when I configured the system to use this hardware time standard and the GPScon software to set the system clock, I was forced to configure WinSDR to use the system clock to obtain event timing. I found that the timing of the event files were drifting so badly that the data was unusable. The best solution I have found is to use an internally connected Motorola GPS, Larry's hardware package and WinSDR because it time stamps the data before it reaches the PC. Once I installed the Motorola GPS as Larry suggested I didn't have too many time issues with the seismic data. However occasionally for some unknown reason, the WinSDR software gets set to ADD mode and adds 4 or 5 min. to the data. I need to read the manual and see what I'm doing wrong. I must be hitting a button or somewhere along the way. But when its working correctly, the data timing is much better than anything I've ever used before. If you are interested in its accuracy, I know that Larry has done some work in this area and can provide the details. Again, sorry for any confusion I may have caused you, but I'm really happy with Net Time and its operational stability. I highly recommend it. Regards, Steve Hammond Aptos CA Public Seismic Network San Jose http://www.publicseismicnetwork.com -----Original Message----- From: psn-l-request@.............. [mailto:psn-l-request@................. Behalf Of ChrisAtUpw@....... Sent: Saturday, April 09, 2005 9:15 PM To: psn-l@.............. Subject: Re: Network time standard 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 Chris, sorry for note being = more=20 direct.

>> = Does it=20 give any timing accuracies in milli seconds for the various time = servers?=20

To answer your question, no = it does=20 not. The best analysis I could provide you was within a=20 few milliseconds which I know is not that accurate and that=20 was by estimating and deduction as I stated. The=20 software does not provide a means for that level = of analysis.=20 However, if you read the help file I attached, you will see that it = attempts to=20 determine the network delay and adjust the clock accordingly. It would = be nice=20 if the software posted the information or facilitated a means to measure = it. But=20 it does not.

Once again I will = state, because=20 I'm certain you don't understand, this software package is a simple = network=20 time standard for keeping "all" the systems on your network in time. I = now=20 realized that any confusion is due to my weak usage statement. I = think you=20 believed that I intended the software to provide a detailed time = standard for a=20 seismic system without a GPS. I did not. I originally stated that the = software=20 was compatible with WinSDR using a Motorola GPS for providing a time = standard=20 for the PC's in your network. It has solved all my network time = issues with=20 having file dates and times over/under and even days off and = I'm very happy=20 with its compatibility with WinSDR. That's why I think it does the=20 job.

In reading your analysis = below, I have=20 to agree with you that the PC hardware impact the results = and my=20 experience tells me that every PC has been different and will = drift=20 accordingly. In the past, I used Right Time which had a = self=20 learning feature to help resolve PC clock drift. It accuracy was close, = but no=20 banana... When I converted to WinSDR, I thought I would use the HP = 58503A. It=20 has a frequency accuracy when locked to better than 1 X 10 to the -12th = for a=20 one day average from 0 to 50 degrees C. However, because of software=20 incompatibility, when I configured the system to use this hardware time = standard=20 and the GPScon software to set the system clock, I was forced=20 to configure WinSDR to use the system clock to = obtain event=20 timing. I found that the timing of the event files were = drifting so=20 badly that the data was unusable. The best solution I have found is = to=20 use an internally connected Motorola GPS, Larry's = hardware package and=20 WinSDR because it time stamps the data before it reaches the = PC. Once=20 I installed the Motorola GPS as Larry suggested I=20 didn't have too many time issues with the seismic data. = However=20 occasionally for some unknown reason, the WinSDR software gets set to = ADD mode=20 and adds 4 or 5 min. to the data. I need to read the manual and see what = I'm=20 doing wrong. I must be hitting a button or somewhere along the way. But = when its=20 working correctly, the data timing is much better than anything I've = ever used=20 before. If you are interested in its accuracy, I know that Larry has = done some=20 work in this area and can provide the details.

Again, sorry for any confusion I = may have=20 caused you, but I'm really happy with Net Time and its operational = stability. I=20 highly recommend it.

Regards, Steve Hammond Aptos = CA

Public Seismic Network San=20 Jose

http://www.publicseismicnetw= ork.com

-----Original Message-----
From:=20 psn-l-request@.............. = [mailto:psn-l-request@...............On Behalf=20 Of ChrisAtUpw@.......
Sent: Saturday, April 09, 2005 = 9:15=20 PM
To: psn-l@..............
Subject: Re: Network = time=20 standard

In a message dated 10/04/2005, shammon1@............. = writes:
My experience when working for TrueTime = (Now a=20 division of Symmetricom) was that you could achieve 10 milliseconds = or so 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 more=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=20 grapes with bananas, if we are not careful. There is a fixed cycle = time for=20 the interrupt polling in a computer, both for the communications = interface and=20 for the program switching. Your multi tasking computer still only runs = one=20 program at a time - it just looks more capable since every cycle it = polls a=20 list to determine which are active. On one of the old IBM type = computers=20 that I checked, this was about every 10 milli sec, but it is likely = to be=20 more frequent on the current offerings. There are also different = levels of=20 interrupt priority.

Then there are network response delays = and=20 digital transmission delays. Local phone networks are likely to = be more=20 accurate. I have measured transmission delays of 3 sec from the NIST = clock=20 over the internet to the 60 KHz radio time, but that was = exceptional. The=20 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=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 can=20 detect a 1 mS error, but this is not an=20 indication of how badly the network time servers and the = communications programs are performing in practice.

If you don't = have a GPS, as=20 I said, the software comes with an extensive
list of network time = servers=20 that can be accessed via the Internet to obtain
accurate time. = Overall,=20 the experience with this software package has been
very positive = and=20 after 30-days of testing I'm now recommending it to other
members = of the=20 Public Seismic Network.

Does it give any timing accuracies = in milli=20 seconds for the various time servers?

We do need to get a reasonable = approximation=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 our=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 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=20 cut-off as the 3 dB point, rather than matching up the ultimate = slopes. The P=20 waves may roll in at ~10 Km / sec.

We wouldn't be having this discussion if=20 computers were fitted with reasonably accurate clocks. The 4.194 MHz = timing=20 crystals can be trimmed to a few seconds per fortnight, but high = precision=20 temperature tracking modules can give 0.1 ppm. The lousy apology = for a=20 clock fitted to my current computer has drifted 8 sec in the last 2 = hours.=20 Even hourly updates would not give me anywhere=20 near the precision required. You used to be = able to=20 buy boards with clock modules on them, but I haven't seen any about=20 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 their=20 clocks directly using WWVB signals. This should be maybe 1/3 the = cost of=20 a GPS system and you would not be dependant on having a permanent = phone=20 connection.

Regards,

Chris=20 Chapman

PSN-L Email List Message