Re: [ntp:questions] Fwd: Re: Best ways to get the reference times from ntp
On Wed, May 07, 2014 at 07:40:28PM +, William Unruh wrote: On 2014-05-07, mike cook michael.c...@sfr.fr wrote: Le 7 mai 2014 ? 18:32, William Unruh a ?crit : The short answer is no, ntpd cannot play this game. You are trying to use A to discipline not only B but C as well but on machine B. My reading is that C is not being disciplined at all, but is to be used a reference (though non UTC) for B. That is my reading as well. But something must be done to determine those values of x and y (Ctime= xT+y where T is UTC). Either that can be done on C using something like chrony (better) or ntpd, or B could run something to determine x and y for C and use those to help discipline B. The OP said the frequency offset of C is known, so only y is unknown if I'm reading it right. But he also said that A and C are in the same network, so I'm not sure if the frequency of C can be tranferred to B with better accuracy than the frequency of A and if this idea of using A to estimate offset and using C to estimate frequency can give better results than just simply increasing the rate of polling of A. I think support for frequency only sources wouldn't be very difficult to add to chrony. Add a new selection option to bypass the selection algorithm and just combine its frequency with other sources by estimated skew. This could work with both NTP sources and reference clocks. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Fwd: Re: Best ways to get the reference times from ntp
First of all, sorry for the formatting issues. I will follow your recommendations and try to avoid this in the future. Answers to mike cook's and William Unruh's mails are below. mike cook wrote: The time_t stamps are available as the transmit time in all ntp packets coming from the peer. One way you could get them is to run ntpdate -d against the peers. You could do that in your program in a pipe and parse the stdout. I am still confused as to the current status. If I am following ,you are collecting timestamps (which are offsets from the moment of boot of a remote system) and with which you are populating shared memory attached to the shared memory refclock driver. At the moment these are absolute offsets (say with a base of 0 , or 00h00m00s 1 jan 1970 in the unix epoch), and you are saying that your system clock is synchronizing correctly by NTP with reference to that epoch . So your system should be now showing dates well in the past. Is that the case? Now you want to add a network ntp server to the config to get your system clock UTC sync'd. If that is the case, before starting NTP normally, you can set the system clock to that of a bunch of servers with either ntpdate, or ntpd -g. If you have no network at this point you will be able to detect it and take further action such as requesting that the date be set manually. That will give you a reasonable starting value sync'd to UTC. Then you can normalize your refclock timestamps by computing the offset with the now correct system clock value and adding that fixed delta to each of the new raw timestamps before populating the shared memory. Is that the plan? Or have I lost my paddle. Almost, if I understand you correctly. Here is a problem description that clarifies it hopefully: Let's assume in a simple setup we have 3 systems A, B, and C. A is a NTP server (stratum 1 or 2) on the internet, B is a local server with a standard oscillator, and C is a system in the same network as A with a temperature-stable oscillator (and a known frequency offset in ppm). C does not provide absolute timestamps but only timestamps relative to an unspecific epoch (e.g. its starting time). C sends B those timestamps and on arrival they may be passed to NTP or another program via a sufficient interface (e.g. shared memory). The system clock of B is synchronized via NTP with A as server. The accuracy (difference compared to UTC, under 1ms and lower even in the initial phase of NTP would be ideal) and stability (how closely the clock maintains its frequency) of the clock in B is to be improved. The initial idea was to use the relative timestamps of C in B (a) via PPS or (b) as a refclock via the shared memory interface. I have not figured out a way to approach (a) but am working (b). As the timestamps from C are likely relative to another epoch than 1. January 1900 and the clock in C drifts, before the timestamps are passed to NTP in B, an offset has to be determined. This offset has to be adjusted (each timestamp or frequently when out of a specific threshold) as the oscillator in C has a drift. For example: A simplified procedure works when I do not use an external NTP server but synchronize to the local clock via clock_gettime with CLOCK_REALTIME and an offset (to simulate another clock than the system clock). That is, determine the epoch offset by using two timestamps that were approximately generated at the same time (this should approximately be the difference of 1. January 1970 plus offset to the epoch used in C). The frequency drift in C I havn't respected in this setup. The quality of this solution I havn't determined. For receiving the timestamps of A I implemented a call to 'ntpq -c rv 0 clock'. What do 0, 1, 2, and so on for rv actually reference? When I look at the output of 'ntpq -c association' I get assid's with 5 digits. When using multiple servers in NTP, this procedure has to be adjusted, of course. Do you think (a) or (b) may be actually working? Do you have other ideas? I guess another option would be to buy a cheap GPS clock for B and use it as refclock and PPS source but that would be just too easy (and a little more expensive). William Unruh wrote: It is very unclear what your mean (and I do not just mean the formatting). Is this an external clock to the computer? Do you at least know that the clock starts on the second, or is the start time unknown even to the microsecond level? Why do you want to use that clock? It works well when setting its offset to the system clock What works well? Are you trying to get that relative clock to have the correct time, or is it providing the time? Yes, ntpd would find it very very difficult to use that clock as a reference. A PPS signal which has not seconds marker, at least is know to be accurate to the ms, and it can be used to discipline the system clock to the ms, if something else disciplines the seconds. Your give nothing except the rate, and ntpd
Re: [ntp:questions] Fwd: Re: Best ways to get the reference times from ntp
On 2014-05-07, Maximilian Brehm maximilian.br...@tu-ilmenau.de wrote: First of all, sorry for the formatting issues. I will follow your recommendations and try to avoid this in the future. Answers to mike cook's and William Unruh's mails are below. mike cook wrote: The time_t stamps are available as the transmit time in all ntp packets coming from the peer. One way you could get them is to run ntpdate -d against the peers. You could do that in your program in a pipe and parse the stdout. I am still confused as to the current status. If I am following ,you are collecting timestamps (which are offsets from the moment of boot of a remote system) and with which you are populating shared memory attached to the shared memory refclock driver. At the moment these are absolute offsets (say with a base of 0 , or 00h00m00s 1 jan 1970 in the unix epoch), and you are saying that your system clock is synchronizing correctly by NTP with reference to that epoch . So your system should be now showing dates well in the past. Is that the case? Now you want to add a network ntp server to the config to get your system clock UTC sync'd. If that is the case, before starting NTP normally, you can set the system clock to that of a bunch of servers with either ntpdate, or ntpd -g. If you have no network at this point you will be able to detect it and take further action such as requesting that the date be set manually. That will give you a reasonable starting value sync'd to UTC. Then you can normalize your refclock timestamps by computing the offset with the now correct system clock value and adding that fixed delta to each of the new raw timestamps before populating the shared memory. Is that the plan? Or have I lost my paddle. Almost, if I understand you correctly. Here is a problem description that clarifies it hopefully: Let's assume in a simple setup we have 3 systems A, B, and C. A is a NTP server (stratum 1 or 2) on the internet, B is a local server with a standard oscillator, and C is a system in the same network as A with a temperature-stable oscillator (and a known frequency offset in ppm). C does not provide absolute timestamps but only timestamps relative to an unspecific epoch (e.g. its starting time). C sends B those timestamps and on arrival they may be passed to NTP or another program via a sufficient interface (e.g. shared memory). The system clock of B is synchronized via NTP with A as server. The accuracy (difference compared to UTC, under 1ms and lower even in the initial phase of NTP would be ideal) and stability (how closely the clock maintains its frequency) of the clock in B is to be improved. The initial idea was to use the relative timestamps of C in B (a) via PPS or (b) as a refclock via the shared memory interface. I have not figured out a way to approach (a) but am working (b). As the timestamps from C are likely relative to another epoch than 1. January 1900 and the clock in C drifts, before the timestamps are passed to NTP in B, an offset has to be determined. This offset has to be adjusted (each timestamp or frequently when out of a specific threshold) as the oscillator in C has a drift. For example: A simplified procedure works when I do not use an external NTP server but synchronize to the local clock via clock_gettime with CLOCK_REALTIME and an offset (to simulate another clock than the system clock). That is, determine the epoch offset by using two timestamps that were approximately generated at the same time (this should approximately be the difference of 1. January 1970 plus offset to the epoch used in C). The frequency drift in C I havn't respected in this setup. The quality of this solution I havn't determined. For receiving the timestamps of A I implemented a call to 'ntpq -c rv 0 clock'. What do 0, 1, 2, and so on for rv actually reference? When I look at the output of 'ntpq -c association' I get assid's with 5 digits. When using multiple servers in NTP, this procedure has to be adjusted, of course. Do you think (a) or (b) may be actually working? Do you have other ideas? I guess another option would be to buy a cheap GPS clock for B and use it as refclock and PPS source but that would be just too easy (and a little more expensive). Not much more. But, lets play. The short answer is no, ntpd cannot play this game. You are trying to use A to discipline not only B but C as well but on machine B. Easiest would be to have A discipline C on C. Ie, C also runs ntpd to discipline itself. The biggest problem is that the way that ntpd disciplines the clock is to change its rate. It has not idea of a true rate except vial those offsets. But then C could discipline B. But this would also get rid of the much greater rate accuracy of C and what would be delivered to B would essentially be A's clock, filtered through C. So let us rephrase the question as follows-- We have a
Re: [ntp:questions] Fwd: Re: Best ways to get the reference times from ntp
Le 7 mai 2014 à 18:32, William Unruh a écrit : snip Not much more. But, lets play. The short answer is no, ntpd cannot play this game. You are trying to use A to discipline not only B but C as well but on machine B. My reading is that C is not being disciplined at all, but is to be used a reference (though non UTC) for B. snip ___ 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] Fwd: Re: Best ways to get the reference times from ntp
Le 7 mai 2014 à 16:23, Maximilian Brehm a écrit : First of all, sorry for the formatting issues. I will follow your recommendations and try to avoid this in the future. Answers to mike cook's and William Unruh's mails are below. mike cook wrote: The time_t stamps are available as the transmit time in all ntp packets coming from the peer. One way you could get them is to run ntpdate -d against the peers. You could do that in your program in a pipe and parse the stdout. I am still confused as to the current status.If I am following ,you are collecting timestamps (which are offsets from the moment of boot of a remote system) and with which you are populating shared memory attached to the shared memory refclock driver. At the moment these are absolute offsets (say with a base of 0 , or 00h00m00s 1 jan 1970 in the unix epoch), and you are saying that your system clock is synchronizing correctly by NTP with reference to that epoch . So your system should be now showing dates well in the past. Is that the case? Now you want to add a network ntp server to the config to get your system clock UTC sync'd. If that is the case, before starting NTP normally, you can set the system clock to that of a bunch of servers with either ntpdate, or ntpd -g. If you have no network at this point you will be able to detect it and take further action such as requesting that the date be set manually. That will give you a reasonable starting value sync'd to UTC. Then you can normalize your refclock timestamps by computing the offset with the now correct system clock value and adding that fixed delta to each of the new raw timestamps before populating the shared memory. Is that the plan? Or have I lost my paddle. Almost, if I understand you correctly. Here is a problem description that clarifies it hopefully: Let's assume in a simple setup we have 3 systems A, B, and C. A is a NTP server (stratum 1 or 2) on the internet, B is a local server with a standard oscillator, and C is a system in the same network as A with a temperature-stable oscillator (and a known frequency offset in ppm). C does not provide absolute timestamps but only timestamps relative to an unspecific epoch (e.g. its starting time). C sends B those timestamps and on arrival they may be passed to NTP or another program via a sufficient interface (e.g. shared memory). The system clock of B is synchronized via NTP with A as server. The accuracy (difference compared to UTC, under 1ms and lower even in the initial phase of NTP would be ideal) and stability (how closely the clock maintains its frequency) of the clock in B is to be improved. The initial idea was to use the relative timestamps of C in B (a) via PPS or (b) as a refclock via the shared memory interface. I have not figured out a way to approach (a) but am working (b). As the timestamps from C are likely relative to another epoch than 1. January 1900 and the clock in C drifts, before the timestamps are passed to NTP in B, an offset has to be determined. This offset has to be adjusted (each timestamp or frequently when out of a specific threshold) as the oscillator in C has a drift. For example: A simplified procedure works when I do not use an external NTP server but synchronize to the local clock via clock_gettime with CLOCK_REALTIME and an offset (to simulate another clock than the system clock). That is, determine the epoch offset by using two timestamps that were approximately generated at the same time (this should approximately be the difference of 1. January 1970 plus offset to the epoch used in C). The frequency drift in C I havn't respected in this setup. The quality of this solution I havn't determined. For receiving the timestamps of A I implemented a call to 'ntpq -c rv 0 clock'. What do 0, 1, 2, and so on for rv actually reference? When I look at the output of 'ntpq -c association' I get assid's with 5 digits. When using multiple servers in NTP, this procedure has to be adjusted, of course. Do you think (a) or (b) may be actually working? Do you have other ideas? I guess another option would be to buy a cheap GPS clock for B and use it as refclock and PPS source but that would be just too easy (and a little more expensive). Thanks for taking the time to clarify. Solution a), using GPS with a 1PPS source is going to get you better quality if you can get a good antenna sky view, and your system B has the hardware to take the interrupt. Using the NMEA strings can only get you so close, not usec precission IMHO. As to being more expensive, I am not so sure. How do you cost your time? Solution b) defining C as a shm refclock, via a driver which normalizes the timestamps from C should be doable( but may not hit the objectives ), and I think that you should let NTP do the hard work. How about this? As a first test compare the NTP stats of B with NTP referencing A (and
Re: [ntp:questions] Fwd: Re: Best ways to get the reference times from ntp
Maximilian Brehm wrote: Let's assume in a simple setup we have 3 systems A, B, and C. A is a NTP server (stratum 1 or 2) on the internet, B is a local server with a standard oscillator, and C is a system in the same network as A with a temperature-stable oscillator (and a known frequency offset in ppm). C does not provide absolute timestamps but only timestamps relative to an unspecific epoch (e.g. its starting time). C sends B those timestamps and on arrival they may be passed to NTP or another program via a sufficient interface (e.g. shared memory). The system clock of B is synchronized via NTP with A as server. I think most would just sync C to A B, however it seems you're trying to do something most would not (seemingly backwards remote sync?), for some reason beyond my current comprehension. You might checkout radclock, it can have multiple different software clocks IIRC, maybe you can rewrite its source to accomplish your goals. http://www.synclab.org/radclock/ http://www.cubinlab.ee.unimelb.edu.au/radclock/ -- E-Mail Sent to this address blackl...@anitech-systems.com will be added to the BlackLists. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Fwd: Re: Best ways to get the reference times from ntp
On 2014-05-07, mike cook michael.c...@sfr.fr wrote: Le 7 mai 2014 ? 18:32, William Unruh a ?crit : snip Not much more. But, lets play. The short answer is no, ntpd cannot play this game. You are trying to use A to discipline not only B but C as well but on machine B. My reading is that C is not being disciplined at all, but is to be used a reference (though non UTC) for B. That is my reading as well. But something must be done to determine those values of x and y (Ctime= xT+y where T is UTC). Either that can be done on C using something like chrony (better) or ntpd, or B could run something to determine x and y for C and use those to help discipline B. But neither ntpd or chrony has any way of doing it (unless you somehow use they simulation packages to do so. Ie, both have simulators which will simulte a clock and the discipline of that clock by ntpd/chrony. If you feed that simulator the readings from C by B and from A by B, then you could use that to estimate x and y. But basically it would require the user to code that up. snip ___ 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
