Re: [ntp:questions] Accuracy of NTP - Advice Needed
On 29 Dec, 2011, at 23:26 , Terje Mathisen wrote: > Danny Mayer wrote: >> No, they use synchronized Cesium atomic clocks for time accuracy. GPS is >> only used to get a fix on the location and I'm not sure that 10's of >> centimeters is good enough for what they are trying to prove. I'd have >> to look closely at the methods used and the data to even have a clue as >> to what is needed and I have touched that stuff in years. > > Danny, how do you think they keep those atomic clocks synchronized? > > How do they _verify_ that they actually stay in sync (to a single-digit ns > level) over the entire length of the experiment(many months)? > > Even Hydrogen Masers won't give you that performance over a year or so, you > have to have some way to sync them either to each other or to UTC. Yes, they use GPS to compare the clocks to each other. One of the articles I read even identified the GPS receiver they use. I think it was a Septentrio PolaRx3eTR PRO (or maybe the older model which that one replaced). Those receivers take a 10 MHz and 1 PPS reference in from the atomic clock so that they can produce GPS carrier phase measurements with respect to the local clock's time. Making these measurements simultaneously at both locations gives you data you can post-process to determine the time difference between the two clocks, independent of the GPS system time. The GPS signals are used only as markers that can be measured at both locations. BIPM Circular T lists GPSPPP (that's two-frequency, all-in-view carrier phase measurements) as being accurate to 0.3 ns. The bigger error is the equipment calibration, which they estimate as 5 ns. The traveling atomic clock would have been used for the equipment calibration. Dennis Ferguson ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
People really do need to read the paper rather then guess. Yes, As some have said, normally GPS is not accurate enough for this level of work but they are not using GPS in the normal way. What they do is agree on ONE specific GPS satellite that happens to be visible at both locations. Each site measures the difference between its own Cesium atomic and the clock aboard the GPS sat.They need to account for Doppler shift, and path delay through the atmosphere. They can double check they got the path delay right by watching a second GPS that is in common view. The method works well because several sources are self canceling. Someone said that were simply using better and more expensive GPS receivers. No, that is NOT the case. (BTW very good GPS receivers are not expensive, cheaper than consumer car navigation GPSs because they don't need a graphic display, map data or a pretty box. (For example, these are only $60 each if you call and ask: http://www.synergy-gps.com/images/stories/pdf/m12mt_brochure.pdf ) This short introduction describes the method used to sync two clocks using "GPS common view" http://tf.nist.gov/time/commonviewgps.htm. It is short and easy to read. On Thu, Dec 29, 2011 at 7:26 AM, Terje Mathisen <"terje.mathisen at tmsw.no"@ntp.org> wrote: > Danny Mayer wrote: >> >> No, they use synchronized Cesium atomic clocks for time accuracy. GPS is >> only used to get a fix on the location and I'm not sure that 10's of >> centimeters is good enough for what they are trying to prove. I'd have >> to look closely at the methods used and the data to even have a clue as >> to what is needed and I have touched that stuff in years. > > > Danny, how do you think they keep those atomic clocks synchronized? > > How do they _verify_ that they actually stay in sync (to a single-digit ns > level) over the entire length of the experiment(many months)? > > Even Hydrogen Masers won't give you that performance over a year or so, you > have to have some way to sync them either to each other or to UTC. > > Terje > -- > - > "almost all programming can be viewed as an exercise in caching" > > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions -- Chris Albertson Redondo Beach, California ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
r...@panix.com (Rod Dorman) writes: >Isn't 802.11 a physical layer specification? Why would it be defining >transport layer behaviour? No - it's a MAC and PHY layer. It doesn't care about TCP or UDP, only MAC layer things like unicast and multicast, and the required management/control glue to make it all work. Have a look at section 6.1.1.3, which notes that most unicast traffic is ACKed, but broadcast and multicast is not. Section 9 describes a good bit of the MAC, and 9.2.8 the ACKing procedure. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
In article , David Malone wrote: >r...@panix.com (Rod Dorman) writes: > >>I did a quick scan of 802.11-2007.pdf and didn't see any requirement >>that UDP is treated as guaranteed by WiFi. > >>Could you give a page number or section reference? > >Look for the handling of unicast traffic. I'm still not finding it. Isn't 802.11 a physical layer specification? Why would it be defining transport layer behaviour? -- -- Rod -- rodd(at)polylogics(dot)com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
r...@panix.com (Rod Dorman) writes: >I did a quick scan of 802.11-2007.pdf and didn't see any requirement >that UDP is treated as guaranteed by WiFi. >Could you give a page number or section reference? Look for the handling of unicast traffic. David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
Dave Hart writes: >I recognize I'm suggesting a layer violation in wishing 802.11 devices >treated UDP differently from TCP, or even worse in terms of layer >violation, UDP 123 differently from UDP 53. It's not pretty, but it >would make a positive difference. The ideal number of retries for NTP >may be zero, assuming the radio layer loss rates are less than 87.5% >in practice. All QoS choices that are made at a low layer involve some amount of layering violation, so I don't actually find this objectionable. If the PHY rate selection algorithm is any good, then the loss rate will be less that 87% unless the network is really clogged up with a lot of busy stations and there are a lot of collisions. >> An alternative would >> be to use NTP's broadcast mode on a LAN, which would eliminate >> retries. >Right. There is one other cool thing you can do with timing and 802.11 broadcasts. Broadcasts really are broadcasts - you're not seeing copies of a packet as you would on a switch. If you can timestamp the arrival of a broadcast, it should provide you with a common reference point in time between a bunch of devices. It can be a fun way to watch the drift on the clocks on a bunch of devices. (The 802.11 cards often have relatively good time counters on them too, for backoff and "TSF" calculations. I've a version of the Atheros driver for FreeBSD that can work as the system timecounter. I've still to check how it compares to other hardware.) David. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
On Thu, Dec 29, 2011 at 19:35, Rod Dorman wrote: > I did a quick scan of 802.11-2007.pdf and didn't see any requirement > that UDP is treated as guaranteed by WiFi. > > Could you give a page number or section reference? My belief is 802.11 treats all unicast datagrams equally, and all multicast/broadcast datagrams equally, in terms of the ack/retransmit behavior. I'm not making any statement about standards compliance -- I am unfamiliar with 802.11 specs. My peanut gallery idea is perhaps UDP in general or NTP specifically would benefit from 802.11 not attempting retransmission. Cheers, Dave Hart ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
In article , Dave Hart wrote: >On Wed, Dec 28, 2011 at 18:58, Rod Dorman wrote: >> Is this defined in an RFC or some other standards document? > >http://standards.ieee.org/about/get/802/802.11.html I did a quick scan of 802.11-2007.pdf and didn't see any requirement that UDP is treated as guaranteed by WiFi. Could you give a page number or section reference? -- -- Rod -- rodd(at)polylogics(dot)com ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS NMEA offset with PPS
1. If you mark clocks as "true" you somehow fool yourself :-). Because now if the clocks are real falsetickers you won't even know about it and your system will be out of sync and for ex. will show low offset from some falseticker maybe. So you have to make clocks closer but don't mark them as "true". When comparing them ntpd will take into account large jitter of NMEA and maybe you may go forward even without increasing mindist. 2. NTPD can choose 2 of 3 clock sources but he can't choose 1 of 2 clocks. So you have to combine NMEA and PPS in one source or add another ntp server for selection algorithm to work. 3. When starting ntpd will at first STEP time to some clock source. I can suppose It will be NMEA. But later ntpd will choose PPS because of low jitter and spike detection algorithm can take place. It will wait for 15 minutes and then make another STEP. To skip this 15 minutes, set time1 to real value. That's just a wild guess. To be more specific, please, could you post your full config first of all, and then ntpq output of commands such as "pe", "rv", "cv" and so on short after restart and then after about half an hour? I think there's some problem in configs. C 2011/12/29 Tomi Lehto > Hi, > > Nickolay Orekhov wrote: > > 2011/12/29 Nickolay Orekhov > > > > Yes, you are right. Your system is synced with PPS and gets seconds from > > NMEA. > > You can set time1 to make NMEA offset closer to reality ( and to PPS ). > > > > Having NMEA offset close to zero, or leaving it at 350 ms, is there a > difference > how it affects the system clock if the pps pulse is working? > > > By the way, if you have only two clock sources, NMEA + PPS and offset > > between them is bigger then "mindist" they > > will be marked as falsetickers and there'll be no sync. > > You might want to increase it by specifying: "tos mindist _value_" in > your > > ntp.conf. > > > > Default mindist is 0.001s, so as a wild guess, I can suppose that you set > > your clock to "true" or already increased mindist or > > you have another one source, NTP maybe, otherwise they will be > > falsetickers. > > > > You are right; I forgot to point that I have set clocks to "true", > otherwise they would become falsetickers which now makes sense given the > large > offset NMEA+PPS are only sources are available. > I'll try 'tos mindist' later and see what happens. > > Next thing to figure out is when I restart ntpd, the PPS offset goes back > to > -350 ms and ntpd starts adjusting it to zero (and NMEA offset goes up to > ~350 ms. > That seems to take hours. It looks like the system clock runs away as soon > as > ntpd stops. > > Tomi > > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Off topic: using delay in routing protocols
Thanks for your reply, Dave. > Mills, D.L. The Fuzzball. Proc. ACM SIGCOMM 88 Symposium (Palo Alto CA, > August 1988), 115-122. > > Mills, D.L., and H.-W. Braun. The NSFNET Backbone Network. Proc. ACM > SIGCOMM 87 Symposium (Stoweflake VT, August 1987), 191-196. For the benefit of anyone researching delay metrics, I've also found the following two references helpful: D.L. Mills. DCN Local-Network Protocols. RFC 891. 1983. which describes in detail the routing protocol used by the Fuzzballs (including the metric), and: A. Khanna, J. Zinky. The revised ARPANET routing metric. Proc. SIGCOMM'89. 1989. which discusses the stability of delay metrics in routing in more detail than you've ever dreamed of. (In case anyone is wondering what I'm doing -- I'm currently working on a distance-vector routing protocol called Babel (RFC 6126) which is supposed to "just work" across a wide range of technologies: you plug a Babel router, and after listening for a few seconds it immediately starts routing, with no need for configuration. The more I look at previous work, the more I feel that DLM was just where I want to be some 30 years earlier.) -- Juliusz ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Off topic: using delay in routing protocols
Juliusz , The fuzzballs indeed used a delay metric. They made little nests at the earth stations in the SATnet program, as well as the routers used in the early NSFnet. In its original form, the ARPAnet also used a a node state metric like the fuzzballs, but switched to a link based metric like OpenSPF. So far as I know the fuzzballs used split horizon and hold-down before anybody else did. This was exemplified by the mantra "good news travels fast, but bad news travels forever." See below for additional references. Mills, D.L. The Fuzzball. Proc. ACM SIGCOMM 88 Symposium (Palo Alto CA, August 1988), 115-122. Mills, D.L., and H.-W. Braun. The NSFNET Backbone Network. Proc. ACM SIGCOMM 87 Symposium (Stoweflake VT, August 1987), 191-196. Dave Juliusz Chroboczek wrote: Hi, Sorry for the offtopic post, but I really don't see another place to ask this question. I hear that the Fuzzball routing protocol used packet delay as a routing metric. Does anyone recall if that's right? Was it the RTT, or was it attempting to perform an estimate of one-way delay? More generally, I'll be grateful for any pointers to papers on the subject of using delay in routing protocols. Thanks for your help, -- Juliusz Chroboczek ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Accuracy of NTP - Advice Needed
Danny Mayer wrote: No, they use synchronized Cesium atomic clocks for time accuracy. GPS is only used to get a fix on the location and I'm not sure that 10's of centimeters is good enough for what they are trying to prove. I'd have to look closely at the methods used and the data to even have a clue as to what is needed and I have touched that stuff in years. Danny, how do you think they keep those atomic clocks synchronized? How do they _verify_ that they actually stay in sync (to a single-digit ns level) over the entire length of the experiment(many months)? Even Hydrogen Masers won't give you that performance over a year or so, you have to have some way to sync them either to each other or to UTC. Terje -- - "almost all programming can be viewed as an exercise in caching" ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS NMEA offset with PPS
Hi, Nickolay Orekhov wrote: > 2011/12/29 Nickolay Orekhov > > Yes, you are right. Your system is synced with PPS and gets seconds from > NMEA. > You can set time1 to make NMEA offset closer to reality ( and to PPS ). > Having NMEA offset close to zero, or leaving it at 350 ms, is there a difference how it affects the system clock if the pps pulse is working? > By the way, if you have only two clock sources, NMEA + PPS and offset > between them is bigger then "mindist" they > will be marked as falsetickers and there'll be no sync. > You might want to increase it by specifying: "tos mindist _value_" in your > ntp.conf. > > Default mindist is 0.001s, so as a wild guess, I can suppose that you set > your clock to "true" or already increased mindist or > you have another one source, NTP maybe, otherwise they will be > falsetickers. > You are right; I forgot to point that I have set clocks to "true", otherwise they would become falsetickers which now makes sense given the large offset NMEA+PPS are only sources are available. I'll try 'tos mindist' later and see what happens. Next thing to figure out is when I restart ntpd, the PPS offset goes back to -350 ms and ntpd starts adjusting it to zero (and NMEA offset goes up to ~350 ms. That seems to take hours. It looks like the system clock runs away as soon as ntpd stops. Tomi ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] GPS NMEA offset with PPS
2011/12/29 Nickolay Orekhov > Yes, you are right. Your system is synced with PPS and gets seconds from > NMEA. > You can set time1 to make NMEA offset closer to reality ( and to PPS ). > > By the way, if you have only two clock sources, NMEA + PPS and offset > between them is bigger then "mindist" they > will be marked as falsetickers and there'll be no sync. > You might want to increase it by specifying: "tos mindist _value_" in your > ntp.conf. > > Default mindist is 0.001s, so as a wild guess, I can suppose that you set > your clock to "true" or already increased mindist or > you have another one source, NTP maybe, otherwise they will be > falsetickers. > > 2011/12/29 Tomi Lehto > >> Hello, >> >> >> I have ntpd set up with two time sources, GPS_NMEA and a PPS pulse, and I >> have a couple >> of perhaps basic questions. >> >> NMEA sentences are not read directly from a physical serial port but a >> "virtual" >> /dev/gps0 that is fed by a separate process. >> PPS pulse comes from the gps module and is handled by custom Linux kernel >> driver. >> >> With no time1 fudge values set for either of the drivers, I let the >> system run >> over night and it settled so that 'ntpq -p' shows >> >> remote refid st t when poll reach delay offset >> jitter >> >> == >> *GPS_NMEA(0) .GPS. 10 l 53 64 3770.000 335.809 >> 20.427 >> oPPS(0) .PPS.0 l6 16 3770.0000.005 >> 0.004 >> remote refid st t when poll reach delay offset >> jitter >> >> == >> *GPS_NMEA(0) .GPS. 10 l9 64 3770.000 331.531 >> 16.355 >> oPPS(0) .PPS.0 l 10 16 3770.0000.005 >> 0.004 >> remote refid st t when poll reach delay offset >> jitter >> >> == >> *GPS_NMEA(0) .GPS. 10 l 29 64 3770.000 331.531 >> 16.355 >> oPPS(0) .PPS.0 l 14 16 3770.0000.003 >> 0.00 >> >> running 'ppstest /dev/pps0' shows >> >> source 0 - assert 1325148282.96125, sequence: 985573 - clear >> 0.0, sequence: 0 >> source 0 - assert 1325148283.96770, sequence: 985580 - clear >> 0.0, sequence: 0 >> source 0 - assert 1325148284.95073, sequence: 985587 - clear >> 0.0, sequence: 0 >> source 0 - assert 1325148285.96346, sequence: 985594 - clear >> 0.0, sequence: 0 >> source 0 - assert 1325148286.95188, sequence: 985601 - clear >> 0.0, sequence: 0 >> >> >> Does that assert time of +/- ~5 usec within a second change tell that the >> system >> clock is running in sync (and in the same phase) with the pps pulse, or >> do I >> understand that completely wrong? >> >> Other thing is the GPS_NMEA offset in ntpq output; looking at the output >> from last >> night it varies between 300 and 350 ms. Does that matter, since the pps >> pulse >> tells when the second starts so having the time from the gps within the >> correct >> second should be enough, no? Or should I tweak fudge time1 value for the >> NMEA >> driver to 350 or so to get is near zero? (NMEA jitter stays under 20 ms >> most of >> the time, some larger peaks every now and then.) >> >> Thanks much, >> Tomi >> >> ___ >> questions mailing list >> questions@lists.ntp.org >> http://lists.ntp.org/listinfo/questions >> >> > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Windows and Wi-Fi - starts well, frequency steps?
Dave Hart wrote: > On Wed, Dec 28, 2011 at 21:54, David Malone > wrote: >> Modern hardware that supports 802.11e (or 802.11n, which requires >> much of the QoS part of 11e) can control things like the number of >> retries, and you could hack the driver to inspect the packets and >> if it is NTP to reduce the number of retires. > > I recognize I'm suggesting a layer violation in wishing 802.11 devices > treated UDP differently from TCP, or even worse in terms of layer > violation, UDP 123 differently from UDP 53. It's not pretty, but it > would make a positive difference. The ideal number of retries for NTP > may be zero, assuming the radio layer loss rates are less than 87.5% > in practice. When NTP wants special treatments of its packets, it should set the TOS/DiffServ field, e.g. to LOWDELAY or EF. Of course when that IP traffic is sent over untagged (not 802.1q) ethernet that information is lost anyway. But a directly connected 802.11 device could possibly look at it. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] GPS NMEA offset with PPS
Hello, I have ntpd set up with two time sources, GPS_NMEA and a PPS pulse, and I have a couple of perhaps basic questions. NMEA sentences are not read directly from a physical serial port but a "virtual" /dev/gps0 that is fed by a separate process. PPS pulse comes from the gps module and is handled by custom Linux kernel driver. With no time1 fudge values set for either of the drivers, I let the system run over night and it settled so that 'ntpq -p' shows remote refid st t when poll reach delay offset jitter == *GPS_NMEA(0) .GPS. 10 l 53 64 3770.000 335.809 20.427 oPPS(0) .PPS.0 l6 16 3770.0000.005 0.004 remote refid st t when poll reach delay offset jitter == *GPS_NMEA(0) .GPS. 10 l9 64 3770.000 331.531 16.355 oPPS(0) .PPS.0 l 10 16 3770.0000.005 0.004 remote refid st t when poll reach delay offset jitter == *GPS_NMEA(0) .GPS. 10 l 29 64 3770.000 331.531 16.355 oPPS(0) .PPS.0 l 14 16 3770.0000.003 0.00 running 'ppstest /dev/pps0' shows source 0 - assert 1325148282.96125, sequence: 985573 - clear 0.0, sequence: 0 source 0 - assert 1325148283.96770, sequence: 985580 - clear 0.0, sequence: 0 source 0 - assert 1325148284.95073, sequence: 985587 - clear 0.0, sequence: 0 source 0 - assert 1325148285.96346, sequence: 985594 - clear 0.0, sequence: 0 source 0 - assert 1325148286.95188, sequence: 985601 - clear 0.0, sequence: 0 Does that assert time of +/- ~5 usec within a second change tell that the system clock is running in sync (and in the same phase) with the pps pulse, or do I understand that completely wrong? Other thing is the GPS_NMEA offset in ntpq output; looking at the output from last night it varies between 300 and 350 ms. Does that matter, since the pps pulse tells when the second starts so having the time from the gps within the correct second should be enough, no? Or should I tweak fudge time1 value for the NMEA driver to 350 or so to get is near zero? (NMEA jitter stays under 20 ms most of the time, some larger peaks every now and then.) Thanks much, Tomi ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
