Re: [ntp:questions] Time server question
William Unruh wrote: On 2019-07-24, Jakob Bohm wrote: On 24/07/2019 08:07, William Unruh wrote: On 2019-07-24, Jakob Bohm wrote: ... A good timing-optimized gps unit, like the original Oncore, have a sw mechanism to offset the PPS event away from the actual top of the second, as well as a way for the sw protocol that numbers the PPS signals to also specify how far away this particular pulse is from the actual event. I.e. with an internal 10 MHz clock, PPS signals will be synced to one of those 100 ns-wide periods, so it can/will be at least up to +/-50 ns away from the proper moment, but when the driver knows about this, it can adjust perfectly for that effect. Terje I happen to have a GPS unit (not yet connected) that is documented to do this too: The PPS pulse occurs at an edge of the internal crystal clock, but a special NMEA statement states (based on the 4D GPS solution) how many ns it is off for each pulse. I have yet to find the point to pass this offset to ntpd after capturing the PPS arrival time. The problem is this is largely irrelevant. The time it takes the computer to respond to an interrupt id far far larger (and variable) than that offset of the pulse which is on the at most 10s of nsec scale. The computer responds on the usec scale (que the interrupt, the comp responds to the que and loads or branches to the interrupt service routine. The routine reads the system clock. All that takes time and a variable amount of time. Ie, you need specialised hardware to make use of that information, and, I thought, usually that infomation was delivered by the gps unit a lond time after the pulse itself. Ie, it is useful for rewriting history, not for the immediate time. The hardware under consideration can time the pulse arrivals more precisely than the interrupt delivery time, thanks to special hardware. Does that hardware read the local clock of the computer, or its own internal clock, which then means you have to also figure out what the relation is between that hardware clock and the system time. It also means that you have to be careful of termination resistances in the lines from the gps to that hardware and drive power from the clock. Remember the "faster than light" neutrinos, which cam down to a bad fibre optics connection from the gps to the underground detector, making the underground clock sightly late, making it look like neutrinos got there faster than than they did. The application of the corrections should all get handled in an ntp driver for the gps unit, which can apply the corrections and deliver the corrected readings to ntpd. ntpd has about 50 different refclock drivers and one might well cover your case. Otherwise one might need to be written. Once that has been set up (in the future), the next problem becomes applying the higher precision offset to the time source data input to the ntp algorithms. At a higher abstraction level this means telling ntp that "at hhmmss.x (local clock), a time stamp of hhmmss.y arrived from this hardware time source". OK, that should work. The main problem is that usually that correction comes long (seconds) after the actual pulse itself as I understand. Depending upon the gps (chipset) you either get a message just before: "At the time of the PPS signal, the clock will be 14:25:51.00015" or just after: "The previous PPS signal occured at 14:25:50.99975" In either case the driver simply combines the internal timestamp (i.e. when did it see the PPS signal, measured using the local clock) and the exact/external time signalled by the GPS. The order in which these two signals arrived doesn't really matter since NTPD is exclusively using the measured offsets and the time of measurement as the inputs to the PLL/FLL hybrid control loop. The maximum frequency offset is 500 ppm and by the time you start to worry about PPS offsets, you have to be down in the low tens or single digits, right? At that point it really doesn't matter if individual measurements arrive one or two seconds late, the clock can only drift a few nanoseconds over that time period. 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] Time server question
> Le 24 juil. 2019 à 11:19, William Unruh a écrit : >> >> The hardware under consideration can time the pulse arrivals more >> precisely than the interrupt delivery time, thanks to special hardware. That tickled a grey cell. There was/is a timing product family bc635/637 time and frequency processors sold by Microsemi which can timestamp a PPS input event to 100ns resolution. Various OS drivers are available, but no ntp refclock driver AFAIK. > > Does that hardware read the local clock of the computer, or its own > internal clock, which then means you have to also figure out what the > relation is between that hardware clock and the system time. > It also means that you have to be careful of termination resistances in > the lines from the gps to that hardware and drive power from the clock. > Remember the "faster than light" neutrinos, which cam down to a bad > fibre optics connection from the gps to the underground detector, making > the underground clock sightly late, making it look like neutrinos got > there faster than than they did. > > The application of the corrections should all get handled in an > ntp driver for the gps unit, which can > apply the corrections and deliver the corrected readings to ntpd. ntpd > has about 50 different refclock drivers and one might well cover your > case. Otherwise one might need to be written. > > >> >> Once that has been set up (in the future), the next problem becomes >> applying the higher precision offset to the time source data input to >> the ntp algorithms. >> >> At a higher abstraction level this means telling ntp that "at >> hhmmss.x (local clock), a time stamp of hhmmss.y >> arrived from this hardware time source". > > OK, that should work. The main problem is that usually that correction > comes long (seconds) after the actual pulse itself as I understand. > >> >> >> >> Enjoy >> >> Jakob > > ___ > questions mailing list > questions@lists.ntp.org > http://lists.ntp.org/listinfo/questions « What’s the point? » J.C. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On 2019-07-24, Jakob Bohm wrote: > On 24/07/2019 08:07, William Unruh wrote: >> On 2019-07-24, Jakob Bohm wrote: ... A good timing-optimized gps unit, like the original Oncore, have a sw mechanism to offset the PPS event away from the actual top of the second, as well as a way for the sw protocol that numbers the PPS signals to also specify how far away this particular pulse is from the actual event. I.e. with an internal 10 MHz clock, PPS signals will be synced to one of those 100 ns-wide periods, so it can/will be at least up to +/-50 ns away from the proper moment, but when the driver knows about this, it can adjust perfectly for that effect. Terje >>> >>> I happen to have a GPS unit (not yet connected) that is documented to do >>> this too: The PPS pulse occurs at an edge of the internal crystal clock, >>> but a special NMEA statement states (based on the 4D GPS solution) how >>> many ns it is off for each pulse. I have yet to find the point to pass >>> this offset to ntpd after capturing the PPS arrival time. >> >> The problem is this is largely irrelevant. The time it takes the >> computer to respond to an interrupt id far far larger (and variable) >> than that offset of the pulse which is on the at most 10s of nsec scale. >> The computer responds on the usec scale (que the interrupt, the comp >> responds to the que and loads or branches to the interrupt service >> routine. The routine reads the system clock. All that takes time and a >> variable amount of time. Ie, you need specialised hardware to make use >> of that information, and, I thought, usually that infomation was >> delivered by the gps unit a lond time after the pulse itself. Ie, it is >> useful for rewriting history, not for the immediate time. >> >> > > The hardware under consideration can time the pulse arrivals more > precisely than the interrupt delivery time, thanks to special hardware. Does that hardware read the local clock of the computer, or its own internal clock, which then means you have to also figure out what the relation is between that hardware clock and the system time. It also means that you have to be careful of termination resistances in the lines from the gps to that hardware and drive power from the clock. Remember the "faster than light" neutrinos, which cam down to a bad fibre optics connection from the gps to the underground detector, making the underground clock sightly late, making it look like neutrinos got there faster than than they did. The application of the corrections should all get handled in an ntp driver for the gps unit, which can apply the corrections and deliver the corrected readings to ntpd. ntpd has about 50 different refclock drivers and one might well cover your case. Otherwise one might need to be written. > > Once that has been set up (in the future), the next problem becomes > applying the higher precision offset to the time source data input to > the ntp algorithms. > > At a higher abstraction level this means telling ntp that "at > hhmmss.x (local clock), a time stamp of hhmmss.y > arrived from this hardware time source". OK, that should work. The main problem is that usually that correction comes long (seconds) after the actual pulse itself as I understand. > > > > Enjoy > > Jakob ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On 2019-07-24, Jakob Bohm wrote: > On 21/07/2019 16:02, Terje Mathisen wrote: >> William Unruh wrote: >>> On 2019-07-19, Chris wrote: On 07/18/19 11:13, William Unruh wrote: > > Sure, but I do not have faith in the "averaging" If one is always 30us > after the other, then the average will always be out by 15us. One would expect a difference, but how can you tell which one is right using just 2 pps ?. With three, you could choose the closest to average and discard the outlier, or if it was outside a defined window. Ok, it's a bit nitpicking, but would still be interesting to try it. >>> >>> No. The mechanism is clear. While one is answering its interrupt the >>> other gets to wait. So, it is the earliest one that is closest to >>> "right" Ie, do not try to use more than one interrupt on the same >>> computer. It does not work >> >> A good timing-optimized gps unit, like the original Oncore, have a sw >> mechanism to offset the PPS event away from the actual top of the >> second, as well as a way for the sw protocol that numbers the PPS >> signals to also specify how far away this particular pulse is from the >> actual event. >> >> I.e. with an internal 10 MHz clock, PPS signals will be synced to one of >> those 100 ns-wide periods, so it can/will be at least up to +/-50 ns >> away from the proper moment, but when the driver knows about this, it >> can adjust perfectly for that effect. >> >> Terje >> > > I happen to have a GPS unit (not yet connected) that is documented to do > this too: The PPS pulse occurs at an edge of the internal crystal clock, > but a special NMEA statement states (based on the 4D GPS solution) how > many ns it is off for each pulse. I have yet to find the point to pass > this offset to ntpd after capturing the PPS arrival time. The problem is this is largely irrelevant. The time it takes the computer to respond to an interrupt id far far larger (and variable) than that offset of the pulse which is on the at most 10s of nsec scale. The computer responds on the usec scale (que the interrupt, the comp responds to the que and loads or branches to the interrupt service routine. The routine reads the system clock. All that takes time and a variable amount of time. Ie, you need specialised hardware to make use of that information, and, I thought, usually that infomation was delivered by the gps unit a lond time after the pulse itself. Ie, it is useful for rewriting history, not for the immediate time. > > Enjoy > > Jakob ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
