Re: [ntp:questions] Time server question
On 24/07/2019 08:07, William Unruh wrote: On 2019-07-24, Jakob Bohm wrote: On 21/07/2019 16:02, Terje Mathisen wrote: William Unruh wrote: ... 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. The hardware under consideration can time the pulse arrivals more precisely than the interrupt delivery time, thanks to special hardware. 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". Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
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. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
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
Re: [ntp:questions] Time server question
On 07/21/19 15: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 Some of the vendors of more modern ntp servers make the point of saying that the 10MHz reference output is synchronised (phase locked ?) to the pps leading edge, but not sure about older units. What is clear is that the ntp is a very smart piece of code under the hood. Am reading the docs, but haven't looked the code yet, so only scratching the surface as far as understanding how it all works. The main interest is to get the system in a state accurate and consistent enough to join an ntp pool, but also satisfy the need for a 10MHz standard for the the lab test gear, which is where the gps do journey started. At present, the experimental setup consists of three older network time servers, collected over the years, spares or repairs state, all needing work. There's a Datum TS2100, a time tools 9860D and a Truetime nts-100. The server host is an intel atom box, mini itx with two network ports, one that will be internet facing and the other for the time server subnet. Running FreeBSD 12 with the current ntp package. PPS is currently to the serial port dcd, but will change to the parallel port ack once the driver and receiver hw are in place. Other ideas include using a stripped down kernel FreeBSD like nanobsd, to minimise cpu load. Typical output from ntpq is: root@ntp-host:/ # ntpq -p -c readvar -c clockvar remote refid st t when poll reach delay offset jitter oPPS(0) .PPS. 0 l58 3770.000 0.000 0.002 +192.9.200.167 .GPS. 1 u- 64 3775.145 -0.412 0.349 *192.9.200.168 .GPS. 1 u 29 64 3770.175 0.001 0.025 +192.9.200.169 .GPS. 1 u 33 64 3770.361 0.001 0.042 -ntp0.uk.uu.net .GPS. 1 u 36 64 377 32.104 3.624 0.691 Datum = .167, time tools = .168 and nts-100 = .169. The last item is to provide at least 1 external source. The .168 is prefer to the pps source associd=0 status=011d leap_none, sync_pps, 1 event, kern, version="ntpd 4.2.8p12-a (1)", processor="amd64", system="FreeBSD/12.0-RELEASE-p6", leap=00, stratum=1, precision=-21, rootdelay=0.000, rootdisp=1.075, refid=PPS, reftime=e0df1ca6.6e8d1281 Sun, Jul 21 2019 18:17:26.431, clock=e0df1cac.2997c50c Sun, Jul 21 2019 18:17:32.162, peer=42481, tc=3, mintc=3, offset=-0.000270, frequency=-49.547, sys_jitter=0.001526, clk_jitter=0.002, clk_wander=0.001, tai=37, leapsec=20170101, expire=20171228 associd=0 status= no events, clk_unspec, device="PPS Clock Discipline", timecode="", poll=86832, noreply=0, badformat=0, baddata=0, stratum=16, refid=80.80.83.0, flags=6 Thanks for all the feedback on this, any suggestions welcome... Chris ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
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 -- - "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
On 2019-07-20, Chris wrote: > On 07/19/19 21:47, William Unruh wrote: > >> 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 >> > > I think we are at cross purposes here. What i'm saying is that if there > are 2 sources of pps signals, say from 2 time servers, there will be a > slight offset between the two, so how to determine which is the accurate > one ?. With 3 or more pps sources, those with the least offset > could be chosen for analysis, to find a median value. Again, IF your system really reacted to the PPS signal instantly, thenthe question you ask makes sense. But since both PPS signals come in at the same time (<1us difference) the way the system reacts to them becomes crucial In that case, the first IRQ the system reacts to blocks the other for a few usec. > > Of course, host processing must introduce uncertainty, but would assume > that ntp is designed to mitigate that ?. No, it is not. ntp works by interupts, and the first thing that ntp asks the interrupt handler to do is to read the system clock. That takes a while, and also blocks any further interrupts while it is reading the system clock. Once it has rad that, it releases the itnerrupts for another to take over if it wants, because it has the only time seneistive data it needs. (or at least that is how a good handler behaves Whether for example ldattach behaves properly is unclear to me. It looked to me when I once looked at it like there is a large amount of processing that goes on in the interrupt handler). > >>> > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On 07/19/19 21:47, William Unruh wrote: 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 I think we are at cross purposes here. What i'm saying is that if there are 2 sources of pps signals, say from 2 time servers, there will be a slight offset between the two, so how to determine which is the accurate one ?. With 3 or more pps sources, those with the least offset could be chosen for analysis, to find a median value. Of course, host processing must introduce uncertainty, but would assume that ntp is designed to mitigate that ?. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On Sat, Jul 20, 2019 at 2:26 AM Gabs Ricalde wrote: > > On Wed, Jul 17, 2019 at 7:59 PM William Unruh wrote: > > I suspect it will be a bad outcome. The rpoblem is that you get > > interrupt contention, and the two interrups will put in time delays into > > the second one processed. > > > > That was my observation when I did some tests years ago with a single core > Atom. > > With a dual core CPU, the interrupts can be simultaneously handled by > both cores. In the attached plot, the parallel port timestamps are > ahead by around 3 us, probably due to the RS232 line driver/receiver. > > When only one core is enabled, the serial port is handled first > followed by the parallel port which causes a delay of around 10 us. > The delay disappears when the serial port source is disconnected. It seems the attachments were too large, trying again. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
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 > >> >> Writing a special interrupt handler (eg for the parallel port) whose >> first action is to read the system clock, and it can then allow other >> interrupts to be handled. That will be good to about 1us. (time to have >> the interrupt hadler to be loaded into memory, and for it to read the >> system clock). > > Don't know enough about FreeBSD, but perhaps there is some way to > specify interrupt priority for a device to minimise latency. It's There are harddware priorities (parallel port is higher priority to serial) and there is how much work the computer has to do to anser the interrupts. (I get the feeling serial is messier than parallel.) > certainly possible to do that at hardware level, but there's still > the data pathway uncertainty between the h/w interrupt and the ntp code. > Signals, shared memory, process priority etc, all introduce uncertainty. > None of these os's were designed for real time work, but clearly good > enough for the task... > >> >> I think the main problem witht he serial port is that it seems to take >> longer to read that the interrupt has occurred. But I did my >> experiments 20 years ago. > > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
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. Writing a special interrupt handler (eg for the parallel port) whose first action is to read the system clock, and it can then allow other interrupts to be handled. That will be good to about 1us. (time to have the interrupt hadler to be loaded into memory, and for it to read the system clock). Don't know enough about FreeBSD, but perhaps there is some way to specify interrupt priority for a device to minimise latency. It's certainly possible to do that at hardware level, but there's still the data pathway uncertainty between the h/w interrupt and the ntp code. Signals, shared memory, process priority etc, all introduce uncertainty. None of these os's were designed for real time work, but clearly good enough for the task... I think the main problem witht he serial port is that it seems to take longer to read that the interrupt has occurred. But I did my experiments 20 years ago. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On Wed, Jul 17, 2019 at 7:59 PM William Unruh wrote: > I suspect it will be a bad outcome. The rpoblem is that you get > interrupt contention, and the two interrups will put in time delays into > the second one processed. > That was my observation when I did some tests years ago with a single core Atom. With a dual core CPU, the interrupts can be simultaneously handled by both cores. In the attached plot, the parallel port timestamps are ahead by around 3 us, probably due to the RS232 line driver/receiver. When only one core is enabled, the serial port is handled first followed by the parallel port which causes a delay of around 10 us. The delay disappears when the serial port source is disconnected. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On 2019-07-17, Chris wrote: > On 07/17/19 12:59, William Unruh wrote: > > > I had some indication that the parallel port was faster. > > That would make sense, since the rs232 devices tend to be slew > rate limited for noise rejection. Found some DS8921 driver / receiver > devices, originally designed for hard drive data path use. Delay > around 10-15 nS or so, which should be more than good enough. > Single 5 volt rail as well. > > > I suspect it will be a bad outcome. The rpoblem is that you get > > interrupt contention, and the two interrups will put in time delays into > > the second one processed. > > Remember hand optimising 6502 asm interrupt handlers years > ago to tune timer accuracy, but that was a 1uS cycle machine, > with handlers stretching out to 100uS or more. > Don't have data, but modern cpus are much faster and in > any case, there are other interrupt sources within the system > which may contribute to jitter. Don't know enough to say, but > perhaps ntp will average out the two to give a more accurate > result ?. Would be interesting to hook it up and see what > happens anyway... 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. Writing a special interrupt handler (eg for the parallel port) whose first action is to read the system clock, and it can then allow other interrupts to be handled. That will be good to about 1us. (time to have the interrupt hadler to be loaded into memory, and for it to read the system clock). I think the main problem witht he serial port is that it seems to take longer to read that the interrupt has occurred. But I did my experiments 20 years ago. > > Chris > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On 07/13/19 16:38, Chris wrote: On 06/20/19 23:39, Chris wrote: Have a couple of surplus gps based ntp servers that have been used for time sync in the lab for few years. They are on a UPS with several hours backup and seems like a good idea to use them to contribute to the ntp global network. Don't want to expose them directly to the net, so plan to isolate them, either via a Solaris zone or FreeBSD jail. This will have 2 network interfaces, ntp subnet facing and the other to internet via the firewall. The ntp side will run ntp client, internet side runs ntp server. Question is, will such an intermediate machine degrade the time served, or will it still be reported as a stratum 1 source. Seems a waste otherwise. ntpq -p currently reports: remote refid st t when poll reach delay offset disp = *chronos .GPS. 1 u 23 64 377 0.18 -0.018 0.03 +nts100 .GPS. 1 u 21 64 377 0.46 -0.071 0.08 Thanks, Chris Got back to this project and have what seems to be at last partially working system. FreeBSD 12 on a minix mini pc with 2 network ports. Also 3 network ntp servers, collected over the years, each with a 1pps output. Rebuilt the kernel with the pps support and added the 1pps hardware wiring. The 1pps from a timeserver has a positive edge, which then goes to an rs232 converter, an inversion, which is then connected to the dcd line on the mini pc serial port, also an inversion, so the leading edge of the 1pps signal to the dcd line is a positive edge. Initially, was getting a false ticker flag on the 1pps, but did a bit more digging and found that at least one of the time sources needs to have the prefer keyword. Chose the .168 source,as that provides the 1 pps. Restart ntpd and get the following: remote refid st t when poll reach delay offset jitter = oPPS(0) .PPS. 0 l 3 8 17 0.000 -0.993 0.316 +192.9.200.167 .GPS. 1 u 31 64 1 5.131 4.095 1.533 *192.9.200.168 .GPS. 1 u 30 64 1 0.174 4.467 0.475 +192.9.200.169 .GPS. 1 u 29 64 1 0.516 4.242 0.583 -ntp0.uk.uu.net .GPS. 1 u 32 64 1 33.061 9.896 0.248 After 24 hours or so: remote refid st t when poll reach delay offset jitter = oPPS(0) .PPS. 0 l 5 8 377 0.000 0.001 0.000 +192.9.200.167 .GPS. 1 u 12 64 377 5.156 4.584 1.049 *192.9.200.168 .GPS. 1 u 1 64 377 0.178 5.007 0.054 +192.9.200.169 .GPS. 1 u 7 64 377 0.393 4.982 1.791 -ntp0.uk.uu.net .GPS. 1 u 19 64 177 31.756 9.495 0.084 So it looks like it's working. The only other question relates to the 1pps signal. Depending on the time server in use, the pulse may be positive or negative going, but the leading edge is the timing point, not the trailing edge some time later. There's a fudge factor to define the edge in use and have that set for a rising positive edge, but can't find anything in the docs that discuss that. If the wrong edge is used, the 1pps would be out by the width so assume that needs to be right. At present, am using the serial port for the 1pps, but have some differential driver / receiver devices that will be tested on the parallel port some time next week hopefully. Meantime can anyone suggest other tests to check accuracy, correct operation, statistics etc ?... Thanks, Chris A bit more experimentation, the offset from pps for the network time server suggested wrong polarity edge was being used. Measured the pps pulse width, which turned out to be around 5mS, which more or less confirmed it. Selected the other edge and after 24 hours, get the following: root@ntp-host:/etc # ntpq -p remote refid st t when poll reach delay offset jitter = oPPS(0) .PPS. 0 l-8 3770.000 -0.001 0.001 +192.9.200.167 .GPS. 1 u 55 64 3775.103 -0.390 0.359 *192.9.200.168 .GPS. 1 u 40 64 3770.181 -0.002 0.060 +192.9.200.169 .GPS. 1 u 65 64 3770.373 -0.008 0.054 -ntp0.uk.uu.net .GPS. 1 u 27 64 377 31.3943.272 0.244 The .168 server offset from pps is almost zero, so wrong polarity was selected. Originally thinking with hardware hat on, the rs232 receiver on the uart dcd input is an inversion and had assumed that the input to the uart itself defined the edge, when in fact, the edge is defined by the rs232 input side. I guess that makes sense. Next thing to try is the parallel port ack line pps and would be interesting to add a second pps signal to see how that affects the result. Interesting project for the summer anyway... Chris ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On 07/17/19 12:59, William Unruh wrote: > I had some indication that the parallel port was faster. That would make sense, since the rs232 devices tend to be slew rate limited for noise rejection. Found some DS8921 driver / receiver devices, originally designed for hard drive data path use. Delay around 10-15 nS or so, which should be more than good enough. Single 5 volt rail as well. > I suspect it will be a bad outcome. The rpoblem is that you get > interrupt contention, and the two interrups will put in time delays into > the second one processed. Remember hand optimising 6502 asm interrupt handlers years ago to tune timer accuracy, but that was a 1uS cycle machine, with handlers stretching out to 100uS or more. Don't have data, but modern cpus are much faster and in any case, there are other interrupt sources within the system which may contribute to jitter. Don't know enough to say, but perhaps ntp will average out the two to give a more accurate result ?. Would be interesting to hook it up and see what happens anyway... Chris ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On 2019-07-17, Chris wrote: > > Next thing to try is the parallel port ack line pps and would be I had some indication that the parallel port was faster. > interesting to add a second pps signal to see how that affects the > result. Interesting project for the summer anyway... I suspect it will be a bad outcome. The rpoblem is that you get interrupt contention, and the two interrups will put in time delays into the second one processed. > > Chris > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On 06/20/19 23:39, Chris wrote: Have a couple of surplus gps based ntp servers that have been used for time sync in the lab for few years. They are on a UPS with several hours backup and seems like a good idea to use them to contribute to the ntp global network. Don't want to expose them directly to the net, so plan to isolate them, either via a Solaris zone or FreeBSD jail. This will have 2 network interfaces, ntp subnet facing and the other to internet via the firewall. The ntp side will run ntp client, internet side runs ntp server. Question is, will such an intermediate machine degrade the time served, or will it still be reported as a stratum 1 source. Seems a waste otherwise. ntpq -p currently reports: remote refid st t when poll reach delay offset disp = *chronos .GPS. 1 u 23 64 377 0.18 -0.018 0.03 +nts100 .GPS. 1 u 21 64 377 0.46 -0.071 0.08 Thanks, Chris Got back to this project and have what seems to be at last partially working system. FreeBSD 12 on a minix mini pc with 2 network ports. Also 3 network ntp servers, collected over the years, each with a 1pps output. Rebuilt the kernel with the pps support and added the 1pps hardware wiring. The 1pps from a timeserver has a positive edge, which then goes to an rs232 converter, an inversion, which is then connected to the dcd line on the mini pc serial port, also an inversion, so the leading edge of the 1pps signal to the dcd line is a positive edge. Initially, was getting a false ticker flag on the 1pps, but did a bit more digging and found that at least one of the time sources needs to have the prefer keyword. Chose the .168 source,as that provides the 1 pps. Restart ntpd and get the following: remote refid st t when poll reach delay offset jitter = oPPS(0) .PPS. 0 l38 170.000 -0.993 0.316 +192.9.200.167 .GPS. 1 u 31 6415.1314.095 1.533 *192.9.200.168 .GPS. 1 u 30 6410.1744.467 0.475 +192.9.200.169 .GPS. 1 u 29 6410.5164.242 0.583 -ntp0.uk.uu.net .GPS. 1 u 32 641 33.0619.896 0.248 After 24 hours or so: remote refid st t when poll reach delay offset jitter = oPPS(0) .PPS. 0 l58 3770.0000.001 0.000 +192.9.200.167 .GPS. 1 u 12 64 3775.1564.584 1.049 *192.9.200.168 .GPS. 1 u1 64 3770.1785.007 0.054 +192.9.200.169 .GPS. 1 u7 64 3770.3934.982 1.791 -ntp0.uk.uu.net .GPS. 1 u 19 64 177 31.7569.495 0.084 So it looks like it's working. The only other question relates to the 1pps signal. Depending on the time server in use, the pulse may be positive or negative going, but the leading edge is the timing point, not the trailing edge some time later. There's a fudge factor to define the edge in use and have that set for a rising positive edge, but can't find anything in the docs that discuss that. If the wrong edge is used, the 1pps would be out by the width so assume that needs to be right. At present, am using the serial port for the 1pps, but have some differential driver / receiver devices that will be tested on the parallel port some time next week hopefully. Meantime can anyone suggest other tests to check accuracy, correct operation, statistics etc ?... Thanks, Chris ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On 06/25/19 19:35, William Unruh wrote: On 2019-06-25, Chris wrote: ... Thanks again for the replies. Did a bit of digging this morning and find that the 1pps sync stuff has been done before. Well, many years ago in fact and more or less how I had visualised it - ntp data augmented by the 1 pps signal. Several pointers to the way forward and it's also supported in the FreeBSD kernel, using either a pin on a serial or parallel port for the 1 pps. Probably go for the parallel port, as that avoids the hardware to convert 1 pps ttl to rs232 levels. Except most serial ports actually used on computers handle ttl levels just fine. True, but would not rely on that sort of hack for anything serious, as it won't have good noise immunity for what is a nS scale timing signal. The 1pps from the gps is at ttl or cmos level on a different piece of kit in another box. A diff line driver and receiver might be the best way, though that would need a bit more hardware. Devil is in the detail as usual, but just need to get it working to start with. Stratum 1 says nothing about accuracy. You could have stratum 1 come off smoke signals and have an accuracy of minutes, and a stratum 7 have an accuracy of usec. All it indicates is how many steps the time server is from a hardware time source. It says nothing about how good that time source is, or how good the connection is between servers. The docs i've looked at seem to say that stratum 1 is generally assumed to be caesium or gps, though the number of links would affect it. Just trying work it out so what appears on the net is as good as the standard it refers to... Chris ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On 06/21/19 15:48, Jakob Bohm wrote: On 21/06/2019 15:14, Thomas Laus wrote: On 2019-06-21, David Woolley wrote: On 21/06/2019 12:26, Thomas Laus wrote: Will either isolation solution have direct access to the computer CPU? The GPS clock will need the ability to directly adjust the frequency of the CPU to achieve expected results for a Stratum 1 serve I'm not aware of anything in ntpd that directly adjusts the CPU frequency and there generally isn't any fine grained way of doing that. ntpd normally works by adjusting how many cycles of a fixed frequency represent a certain time period, and that is a software operation. I guess that I should have stated this reply a little differently. I meant to say that ntpd will need direct access to the hardware that it runs on. That means a hardware serial port for pulse per second and the running system clock frequency. The ntpd program does not perform well when running on a virtual machine nor in a isolated security environment similar to a freebsd jail. My advice to the original poster is to get ntpd running as a stratum 1 source and then connect it to the internet with the fewest number of inter- mediate hops in between. I doubt that this is possible if the Stratum 1 time source can be connected through any buffer device to the internet and still serve Stratum 1 time. The deeper problem here is that the NTP protocol doesn't clearly distinguish between a stratum 2 server running dozens of low quality hops from it's time sources and a stratum 2 server that sits a single hop from a solid stratum 1 source. On the other hand, a GPS, WWVB or other radio clock isn't really a stratum 1, as it receives remote time over a non-NTP protocol, so that sort of cancels out the stratum 2 reported due to the stacking. Running the Internet-exposed ntp server in a bastion host separate from the difficult-to-upgrade old hardware makes perfect sense, and an ntpd server without same machine precision time sources only needs the permissions to use port 123 and to adjust the local clock (including it's speed) via the various privileged system calls. Running the computer clocks in such a bastion host from a quality crystal rather than a cheap ceramic oscillator would also help reduce time errors, but this is in the hardware buying phase and not a detail typically provided by computer vendors. I suspect the ntp servers run by national time services and synced to their reference Cs and maser clocks are also receiving the time via some kind of internal network, either ntp with stratum fudge, PTP low latency Ethernet distribution or an amplified low latency coax distribution of the 1Hz or 10MHz reference (the latter would be most precise and offer no data channel for a compromised server to attack the actual clock). Enjoy Jakob Thanks for all the replies. I guess the next thing to do is to build a working system, then evaluate to see how it can be improved. All the kit is in the same rack and with dedicated hardware interfaces, network latency shouldn't be a problem. This is effectively a real time requirement, so any code running needs to be consistent in terms of response time to minimise jitter on the timing. Need to get a feel for acceptable delay and response times, so will look to see what others have done in the past. I like the idea of using a 1 pps signal from the gps for fine tuning. Rough time and date via the network ntp and the 1pps to fine tune it. That could maintain the stratum 1 timing quality, as the 1pps is generally within 10's of nS of UTC, but need to look into how ntpd would handle that and also how to introduce that into the system. Already use an ex telco gps for a lab frequency standard, but of course, frequency != time of day. A dedicated embedded solution might be the best bet, but other options might include a cheap netgear router to provide the isolation, as it would only be handling ntp packets at low and consistent system and network load. Nothing is ever as easy as it seems, as usual... Chris ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On 06/25/19 10:52, David Taylor wrote: On 25/06/2019 01:33, Chris wrote: [] Thanks for all the replies. I guess the next thing to do is to build a working system, then evaluate to see how it can be improved. All the kit is in the same rack and with dedicated hardware interfaces, network latency shouldn't be a problem. This is effectively a real time requirement, so any code running needs to be consistent in terms of response time to minimise jitter on the timing. Need to get a feel for acceptable delay and response times, so will look to see what others have done in the past. I like the idea of using a 1 pps signal from the gps for fine tuning. Rough time and date via the network ntp and the 1pps to fine tune it. That could maintain the stratum 1 timing quality, as the 1pps is generally within 10's of nS of UTC, but need to look into how ntpd would handle that and also how to introduce that into the system. Already use an ex telco gps for a lab frequency standard, but of course, frequency != time of day. A dedicated embedded solution might be the best bet, but other options might include a cheap netgear router to provide the isolation, as it would only be handling ntp packets at low and consistent system and network load. Nothing is ever as easy as it seems, as usual... Chris Chris, would one or more of these help? http://www.leobodnar.com/shop/index.php?main_page=product_info_id=272 No OS to get in the way. Thanks, neat looking box, but already have the gps ntp servers. The question was how to maintain the stratum one accuracy while going through a firewall device to the net. looks like all the hard work has been done though. Open source comes to the rescue yet again... Chris ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On 06/25/19 11:34, William Unruh wrote: On 2019-06-25, Chris wrote: On 06/21/19 15:48, Jakob Bohm wrote: On 21/06/2019 15:14, Thomas Laus wrote: On 2019-06-21, David Woolley wrote: On 21/06/2019 12:26, Thomas Laus wrote: Will either isolation solution have direct access to the computer CPU? The GPS clock will need the ability to directly adjust the frequency of the CPU to achieve expected results for a Stratum 1 serve I'm not aware of anything in ntpd that directly adjusts the CPU frequency and there generally isn't any fine grained way of doing that. ntpd normally works by adjusting how many cycles of a fixed frequency represent a certain time period, and that is a software operation. I guess that I should have stated this reply a little differently. I meant to say that ntpd will need direct access to the hardware that it runs on. That means a hardware serial port for pulse per second and the running system clock frequency. The ntpd program does not perform well when running on a virtual machine nor in a isolated security environment similar to a freebsd jail. My advice to the original poster is to get ntpd running as a stratum 1 source and then connect it to the internet with the fewest number of inter- mediate hops in between. I doubt that this is possible if the Stratum 1 time source can be connected through any buffer device to the internet and still serve Stratum 1 time. The deeper problem here is that the NTP protocol doesn't clearly distinguish between a stratum 2 server running dozens of low quality hops from it's time sources and a stratum 2 server that sits a single hop from a solid stratum 1 source. On the other hand, a GPS, WWVB or other radio clock isn't really a stratum 1, as it receives remote time over a non-NTP protocol, so that sort of cancels out the stratum 2 reported due to the stacking. Running the Internet-exposed ntp server in a bastion host separate from the difficult-to-upgrade old hardware makes perfect sense, and an ntpd server without same machine precision time sources only needs the permissions to use port 123 and to adjust the local clock (including it's speed) via the various privileged system calls. Running the computer clocks in such a bastion host from a quality crystal rather than a cheap ceramic oscillator would also help reduce time errors, but this is in the hardware buying phase and not a detail typically provided by computer vendors. I suspect the ntp servers run by national time services and synced to their reference Cs and maser clocks are also receiving the time via some kind of internal network, either ntp with stratum fudge, PTP low latency Ethernet distribution or an amplified low latency coax distribution of the 1Hz or 10MHz reference (the latter would be most precise and offer no data channel for a compromised server to attack the actual clock). Enjoy Jakob Thanks for all the replies. I guess the next thing to do is to build a working system, then evaluate to see how it can be improved. All the kit is in the same rack and with dedicated hardware interfaces, network latency shouldn't be a problem. This is effectively a real time requirement, so any code running needs to be consistent in terms of response time to minimise jitter on the timing. Need to get a feel for acceptable delay and response times, so will look to see what others have done in the past. I like the idea of using a 1 pps signal from the gps for fine tuning. Rough time and date via the network ntp and the 1pps to fine tune it. That could maintain the stratum 1 timing quality, as the 1pps is generally within 10's of nS of UTC, but need to look into how ntpd Well, yes and no. That may be when a certain point inthe transition of the pps signal occurs (although youwoillo have to be really careful about the line from the gps to the computer, and the terminations of the lines. Also that tends to be the corrected time (for the sawtooth running). Also it is really hard to get your computer to process the signal to 0ns. A more resonable estimate is 1microsecond Taking intoaccunt the computer's interrupt latency, time to read system time, etc. To do better is going to take a lot of work. Note the gps ALSO delivers the seconds information in the gps time signal. (Ie labelling the seconds). would handle that and also how to introduce that into the system. Already use an ex telco gps for a lab frequency standard, but of course, frequency != time of day. A dedicated embedded solution might be the best bet, but other options might include a cheap netgear router to provide the isolation, as it would only be handling ntp packets at low and consistent system and network load. Nothing is ever as easy as it seems, as usual... Depends on what you want out of the system, or rather what you need. No point is spending months and tens of thousands of dollars when all you really need is resultion to the second. Chris Hi, Thanks again for the replies. Did a bit of digging
Re: [ntp:questions] Time server question
On 21/06/2019 15:14, Thomas Laus wrote: On 2019-06-21, David Woolley wrote: On 21/06/2019 12:26, Thomas Laus wrote: Will either isolation solution have direct access to the computer CPU? The GPS clock will need the ability to directly adjust the frequency of the CPU to achieve expected results for a Stratum 1 serve I'm not aware of anything in ntpd that directly adjusts the CPU frequency and there generally isn't any fine grained way of doing that. ntpd normally works by adjusting how many cycles of a fixed frequency represent a certain time period, and that is a software operation. I guess that I should have stated this reply a little differently. I meant to say that ntpd will need direct access to the hardware that it runs on. That means a hardware serial port for pulse per second and the running system clock frequency. The ntpd program does not perform well when running on a virtual machine nor in a isolated security environment similar to a freebsd jail. My advice to the original poster is to get ntpd running as a stratum 1 source and then connect it to the internet with the fewest number of inter- mediate hops in between. I doubt that this is possible if the Stratum 1 time source can be connected through any buffer device to the internet and still serve Stratum 1 time. The deeper problem here is that the NTP protocol doesn't clearly distinguish between a stratum 2 server running dozens of low quality hops from it's time sources and a stratum 2 server that sits a single hop from a solid stratum 1 source. On the other hand, a GPS, WWVB or other radio clock isn't really a stratum 1, as it receives remote time over a non-NTP protocol, so that sort of cancels out the stratum 2 reported due to the stacking. Running the Internet-exposed ntp server in a bastion host separate from the difficult-to-upgrade old hardware makes perfect sense, and an ntpd server without same machine precision time sources only needs the permissions to use port 123 and to adjust the local clock (including it's speed) via the various privileged system calls. Running the computer clocks in such a bastion host from a quality crystal rather than a cheap ceramic oscillator would also help reduce time errors, but this is in the hardware buying phase and not a detail typically provided by computer vendors. I suspect the ntp servers run by national time services and synced to their reference Cs and maser clocks are also receiving the time via some kind of internal network, either ntp with stratum fudge, PTP low latency Ethernet distribution or an amplified low latency coax distribution of the 1Hz or 10MHz reference (the latter would be most precise and offer no data channel for a compromised server to attack the actual clock). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On 2019-06-21, David Woolley wrote: > On 21/06/2019 12:26, Thomas Laus wrote: >> Will either isolation solution have direct access to the computer >> CPU? The GPS clock will need the ability to directly adjust the >> frequency of the CPU to achieve expected results for a Stratum 1 >> serve > > I'm not aware of anything in ntpd that directly adjusts the CPU > frequency and there generally isn't any fine grained way of doing that. > ntpd normally works by adjusting how many cycles of a fixed frequency > represent a certain time period, and that is a software operation. > I guess that I should have stated this reply a little differently. I meant to say that ntpd will need direct access to the hardware that it runs on. That means a hardware serial port for pulse per second and the running system clock frequency. The ntpd program does not perform well when running on a virtual machine nor in a isolated security environment similar to a freebsd jail. My advice to the original poster is to get ntpd running as a stratum 1 source and then connect it to the internet with the fewest number of inter- mediate hops in between. I doubt that this is possible if the Stratum 1 time source can be connected through any buffer device to the internet and still serve Stratum 1 time. -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On 2019-06-20, Chris wrote: > Have a couple of surplus gps based ntp servers that have been > used for time sync in the lab for few years. They are on a UPS > with several hours backup and seems like a good idea to use > them to contribute to the ntp global network. > > Don't want to expose them directly to the net, so plan to > isolate them, either via a Solaris zone or > FreeBSD jail. This will have 2 network interfaces, ntp subnet > facing and the other to internet via the firewall. The ntp > side will run ntp client, internet side runs ntp server. > Will either isolation solution have direct access to the computer CPU? The GPS clock will need the ability to directly adjust the frequency of the CPU to achieve expected results for a Stratum 1 server. > Question is, will such an intermediate machine degrade the > time served, or will it still be reported as a stratum 1 > source. Seems a waste otherwise. > > ntpq -p currently reports: > > remote refid st t when poll reach delay offset disp >= > *chronos .GPS. 1 u 23 64 377 0.18 -0.0180.03 > +nts100.GPS. 1 u 21 64 377 0.46 -0.0710.08 > That looks like a good billboard and should make a good S1 time server if you can resolve your concerns about making it available as an internet host. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Time server question
Have a couple of surplus gps based ntp servers that have been used for time sync in the lab for few years. They are on a UPS with several hours backup and seems like a good idea to use them to contribute to the ntp global network. Don't want to expose them directly to the net, so plan to isolate them, either via a Solaris zone or FreeBSD jail. This will have 2 network interfaces, ntp subnet facing and the other to internet via the firewall. The ntp side will run ntp client, internet side runs ntp server. Question is, will such an intermediate machine degrade the time served, or will it still be reported as a stratum 1 source. Seems a waste otherwise. ntpq -p currently reports: remote refid st t when poll reach delay offset disp = *chronos .GPS. 1 u 23 64 377 0.18 -0.0180.03 +nts100.GPS. 1 u 21 64 377 0.46 -0.0710.08 Thanks, Chris ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On 2019-06-25, Chris wrote: > On 06/25/19 19:35, William Unruh wrote: >> On 2019-06-25, Chris wrote: >> ... >>> >>> Thanks again for the replies. Did a bit of digging this morning and >>> find that the 1pps sync stuff has been done before. Well, many >>> years ago in fact and more or less how I had visualised it - ntp >>> data augmented by the 1 pps signal. Several pointers to the way >>> forward and it's also supported in the FreeBSD kernel, using either a >>> pin on a serial or parallel port for the 1 pps. Probably go for >>> the parallel port, as that avoids the hardware to convert 1 pps >>> ttl to rs232 levels. >> >> Except most serial ports actually used on computers handle ttl levels >> just fine. >> > > True, but would not rely on that sort of hack for anything serious, > as it won't have good noise immunity for what is a nS scale timing > signal. The 1pps from the gps is at ttl or cmos level on a different > piece of kit in another box. A diff line driver and receiver might > be the best way, though that would need a bit more hardware. Devil > is in the detail as usual, but just need to get it working to start > with. Not clear what you mean. Note that a driver would introduce its own delays, and line termination also has effect. > > >> >> Stratum 1 says nothing about accuracy. You could have stratum 1 come off >> smoke signals and have an accuracy of minutes, and a stratum 7 have an >> accuracy of usec. All it indicates is how many steps the time server is >> from a hardware time source. It says nothing about how good that time >> source is, or how good the connection is between servers. > > The docs i've looked at seem to say that stratum 1 is generally > assumed to be caesium or gps, though the number of links would affect It is basically any hardware. It could be WWV radio signals. Yes most of the time it is probably gps, but then you do not know how long the line from the gps receiver to the computer is,or how rapidly the computer responds to interrupts, etc. Ie, stratum 1 does not imply accuracy. > it. Just trying work it out so what appears on the net is as good > as the standard it refers to... > > Chris > > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On 2019-06-25, Chris wrote: ... > > Thanks again for the replies. Did a bit of digging this morning and > find that the 1pps sync stuff has been done before. Well, many > years ago in fact and more or less how I had visualised it - ntp > data augmented by the 1 pps signal. Several pointers to the way > forward and it's also supported in the FreeBSD kernel, using either a > pin on a serial or parallel port for the 1 pps. Probably go for > the parallel port, as that avoids the hardware to convert 1 pps > ttl to rs232 levels. Except most serial ports actually used on computers handle ttl levels just fine. > > Have a Minix mini-itx box with two network ports which only draws > about 12 watts. It has headers for the parallel and serial ports, > so looks ideal to experiment with. Already has FreeBSD 11.2, but > will reinstall 12 at minimum level to get the job done. Not after > perfection, but engineers always want the best result at minimum > cost and timescales :-). A few uS should be more than good enough to > maintain stratum 1 accuracy afaics, as network variables are Stratum 1 says nothing about accuracy. You could have stratum 1 come off smoke signals and have an accurcyof minutes, and a stratum 7 have an accuracy of usec. All it indicates is how many steps the time server is from a hardware time source. It says nothing about how good that time source is, or how good the connection is between servers. > orders of magnitude greater than that. Fun project anyway and > will document once it's working... > > > Chris > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On 2019-06-25, Chris wrote: > On 06/21/19 15:48, Jakob Bohm wrote: >> On 21/06/2019 15:14, Thomas Laus wrote: >>> On 2019-06-21, David Woolley wrote: On 21/06/2019 12:26, Thomas Laus wrote: > Will either isolation solution have direct access to the computer > CPU? The GPS clock will need the ability to directly adjust the > frequency of the CPU to achieve expected results for a Stratum 1 > serve I'm not aware of anything in ntpd that directly adjusts the CPU frequency and there generally isn't any fine grained way of doing that. ntpd normally works by adjusting how many cycles of a fixed frequency represent a certain time period, and that is a software operation. >>> I guess that I should have stated this reply a little differently. I >>> meant to say that ntpd will need direct access to the hardware that >>> it runs on. That means a hardware serial port for pulse per second >>> and the running system clock frequency. The ntpd program does not >>> perform well when running on a virtual machine nor in a isolated >>> security environment similar to a freebsd jail. My advice to the >>> original poster is to get ntpd running as a stratum 1 source and >>> then connect it to the internet with the fewest number of inter- >>> mediate hops in between. I doubt that this is possible if the >>> Stratum 1 time source can be connected through any buffer device >>> to the internet and still serve Stratum 1 time. >>> >>> >> >> The deeper problem here is that the NTP protocol doesn't clearly >> distinguish between a stratum 2 server running dozens of low quality >> hops from it's time sources and a stratum 2 server that sits a single >> hop from a solid stratum 1 source. >> >> On the other hand, a GPS, WWVB or other radio clock isn't really a >> stratum 1, as it receives remote time over a non-NTP protocol, so that >> sort of cancels out the stratum 2 reported due to the stacking. >> >> Running the Internet-exposed ntp server in a bastion host separate >> from the difficult-to-upgrade old hardware makes perfect sense, and >> an ntpd server without same machine precision time sources only needs >> the permissions to use port 123 and to adjust the local clock (including >> it's speed) via the various privileged system calls. Running the >> computer clocks in such a bastion host from a quality crystal rather >> than a cheap ceramic oscillator would also help reduce time errors, but >> this is in the hardware buying phase and not a detail typically provided >> by computer vendors. >> >> I suspect the ntp servers run by national time services and synced to >> their reference Cs and maser clocks are also receiving the time via >> some kind of internal network, either ntp with stratum fudge, PTP low >> latency Ethernet distribution or an amplified low latency coax >> distribution of the 1Hz or 10MHz reference (the latter would be most >> precise and offer no data channel for a compromised server to attack the >> actual clock). >> >> >> Enjoy >> >> Jakob > > Thanks for all the replies. I guess the next thing to do is to build > a working system, then evaluate to see how it can be improved. All > the kit is in the same rack and with dedicated hardware interfaces, > network latency shouldn't be a problem. This is effectively a real > time requirement, so any code running needs to be consistent in terms > of response time to minimise jitter on the timing. Need to get > a feel for acceptable delay and response times, so will look to see > what others have done in the past. > > I like the idea of using a 1 pps signal from the gps for fine tuning. > Rough time and date via the network ntp and the 1pps to fine tune it. > That could maintain the stratum 1 timing quality, as the 1pps is > generally within 10's of nS of UTC, but need to look into how ntpd Well, yes and no. That may be when a certain point inthe transition of the pps signal occurs (although youwoillo have to be really careful about the line from the gps to the computer, and the terminations of the lines. Also that tends to be the corrected time (for the sawtooth running). Also it is really hard to get your computer to process the signal to 0ns. A more resonable estimate is 1microsecond Taking intoaccunt the computer's interrupt latency, time to read system time, etc. To do better is going to take a lot of work. Note the gps ALSO delivers the seconds information in the gps time signal. (Ie labelling the seconds). > would handle that and also how to introduce that into the system. > Already use an ex telco gps for a lab frequency standard, but of > course, frequency != time of day. A dedicated embedded solution might > be the best bet, but other options might include a cheap netgear > router to provide the isolation, as it would only be handling ntp > packets at low and consistent system and network load. > > Nothing is ever as easy as it seems, as usual... Depends on what you want out of the system, or rather what
Re: [ntp:questions] Time server question
On 25/06/2019 01:33, Chris wrote: [] Thanks for all the replies. I guess the next thing to do is to build a working system, then evaluate to see how it can be improved. All the kit is in the same rack and with dedicated hardware interfaces, network latency shouldn't be a problem. This is effectively a real time requirement, so any code running needs to be consistent in terms of response time to minimise jitter on the timing. Need to get a feel for acceptable delay and response times, so will look to see what others have done in the past. I like the idea of using a 1 pps signal from the gps for fine tuning. Rough time and date via the network ntp and the 1pps to fine tune it. That could maintain the stratum 1 timing quality, as the 1pps is generally within 10's of nS of UTC, but need to look into how ntpd would handle that and also how to introduce that into the system. Already use an ex telco gps for a lab frequency standard, but of course, frequency != time of day. A dedicated embedded solution might be the best bet, but other options might include a cheap netgear router to provide the isolation, as it would only be handling ntp packets at low and consistent system and network load. Nothing is ever as easy as it seems, as usual... Chris Chris, would one or more of these help? http://www.leobodnar.com/shop/index.php?main_page=product_info_id=272 No OS to get in the way. -- Cheers, David Web: http://www.satsignal.eu ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Time server question
On 21/06/2019 12:26, Thomas Laus wrote: Will either isolation solution have direct access to the computer CPU? The GPS clock will need the ability to directly adjust the frequency of the CPU to achieve expected results for a Stratum 1 serve I'm not aware of anything in ntpd that directly adjusts the CPU frequency and there generally isn't any fine grained way of doing that. ntpd normally works by adjusting how many cycles of a fixed frequency represent a certain time period, and that is a software operation. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
