Re: [ntp:questions] Slow convergence loopstats (but nice results)
On 2013-11-22, schmidt.r...@gmail.com wrote: > I have just written a PHC driver for NTP and tested it on this system: > Supermicro SYS-50150EHF-D525 which has a pair of Intel 82574L NICs which > have IEEE 1588 hardware-based timestamping. I'm using NTP dev 4.2.7p397 on > Linux kernel 3.12 with linuxptp. One of the PHCs is sync'd via PTP to an FEI > Zyfer Gsync GrandMaster, which is in turn synced via 5MHz to the USNO Master > Clock #2. > > I'm running ptp4l to sync PHC1 to the GrandMaster. Then NTP is reading the > refclocks PHC0, PHC1 and an NTP server on the LAN ptp2: > > ntpq -p > remote refid st t when poll reach delay offset jitter >== > +PHC(0) .PTP.0 l 15 16 3770.0000.000 0.000 > *PHC(1) .PTP.0 l2 16 3770.000 -0.001 0.000 > +ptp2.IRIG. 1 u 38 64 3770.1230.018 0.007 > > After about 15 hours the loopstats shows a s.d. of +/- 0.579 microsec with > peak-peak 2.52 microsec (3,073 points). Very superb. > > However, it took fully 75 minutes at start to converge. It took that long to > remove 20ms of phase error. I have never seen such a slow convergence. Very > smooth too. I have tested the NMEA/ATOM drivers on this system and the > convergence was the normal few minutes. Any suggestions? Can email plots. David Mills has always stated that rate of convergence is not a problem he cares about at all. Stability of running is. ntpd is NOT designed to converge quickly. If you want faster convergence ( and better clock discipline although possibly slightly higher drift noise) use chrony. Certainly a SD of .5us is far better than any standard PC can get from an interrupt driven stratum 0 source due to interrupt latency fluctuations. I am surprized you can get such good results from a NIC based solution (even with hardware timestamping). > > Rich Schmidt > Time Service Dept > US Naval Observatory ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Slow convergence loopstats (but nice results)
On 2013-11-22 09:19, schmidt.r...@gmail.com wrote: I have just written a PHC driver for NTP and tested it on this system: Supermicro SYS-50150EHF-D525 which has a pair of Intel 82574L NICs which have IEEE 1588 hardware-based timestamping. I'm using NTP dev 4.2.7p397 onLinux kernel 3.12 with linuxptp. One of the PHCs is sync'd via PTP to an FEIZyfer Gsync GrandMaster, which is in turn synced via 5MHz to the USNO Master Clock #2. I'm running ptp4l to sync PHC1 to the GrandMaster. Then NTP is reading the refclocks PHC0, PHC1 and an NTP server on the LAN ptp2: ntpq -p remote refid st t when poll reach delay offset jitter == +PHC(0) .PTP.0 l 15 16 3770.0000.000 0.000 *PHC(1) .PTP.0 l2 16 3770.000 -0.001 0.000 +ptp2.IRIG. 1 u 38 64 3770.1230.018 0.007 After about 15 hours the loopstats shows a s.d. of +/- 0.579 microsec with peak-peak 2.52 microsec (3,073 points). Very superb. However, it took fully 75 minutes at start to converge. It took that long to remove 20ms of phase error. I have never seen such a slow convergence. Very smooth too. I have tested the NMEA/ATOM drivers on this system and the convergence was the normal few minutes. Any suggestions? Can email plots.. Rich Schmidt Time Service Dept US Naval Observatory You do not appear to be delivering PPS via kernel PPS, an ATOM driver, or user mode PPS, with PHC0/1 as your prefer peer. You want to see o before your ref clock, so that may explain slow convergence compared to using the ATOM driver! Does Linux PTP have an interface to provide timestamp interrupts to Linux kernel PPS, and can you set that up, or add user mode PPS to your driver? There are example user mode PPS patches for Raspberry Pi Raspian Linux NTP, and in ports/winnt/ntpd/ntp_iocompletionport.c. You could compare your loopstats to your ref clock peerstats, and also your driver clockstats if you are generating them? Loopstats offset/jitter should track your ref clock peerstats offset/jitter exactly, and comparing to your clockstats may point you to causes. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Slow convergence loopstats (but nice results)
On Friday, November 22, 2013 12:38:36 PM UTC-5, unruh wrote: > On 2013-11-22, schmidt.r...@gmail.com wrote: > > > I have just written a PHC driver for NTP and tested it on this system: > > > Supermicro SYS-50150EHF-D525 which has a pair of Intel 82574L NICs which > > > have IEEE 1588 hardware-based timestamping. I'm using NTP dev 4.2.7p397 on > > Linux kernel 3.12 with linuxptp. One of the PHCs is sync'd via PTP to an > > FEI Zyfer Gsync GrandMaster, which is in turn synced via 5MHz to the USNO > > Master Clock #2. > > > > > > I'm running ptp4l to sync PHC1 to the GrandMaster. Then NTP is reading the > > refclocks PHC0, PHC1 and an NTP server on the LAN ptp2: > > > > > > ntpq -p > > > remote refid st t when poll reach delay offset > > jitter > > >== > > > +PHC(0) .PTP.0 l 15 16 3770.0000.000 > > 0.000 > > > *PHC(1) .PTP.0 l2 16 3770.000 -0.001 > > 0.000 > > > +ptp2.IRIG. 1 u 38 64 3770.1230.018 > > 0.007 > > > > > > After about 15 hours the loopstats shows a s.d. of +/- 0.579 microsec with > > peak-peak 2.52 microsec (3,073 points). Very superb. > > > > > > However, it took fully 75 minutes at start to converge. It took that long > > to remove 20ms of phase error. I have never seen such a slow convergence. > > Very smooth too. I have tested the NMEA/ATOM drivers on this system and > > the convergence was the normal few minutes. Any suggestions? Can email > > plots. > > > > David Mills has always stated that rate of convergence is not a problem > > he cares about at all. Stability of running is. ntpd is NOT designed to > > converge quickly. If you want faster convergence ( and better clock > > discipline although possibly slightly higher drift noise) use chrony. > > Certainly a SD of .5us is far better than any standard PC can get from > > an interrupt driven stratum 0 source due to > > interrupt latency fluctuations. I am surprized you can get such good > > results from a NIC based solution (even with hardware timestamping). > > > > > > > > Rich Schmidt > > > Time Service Dept > > > US Naval Observatory Understood. Yes, just curious. Currently my loopstats looks like this: 56618 69198.256 0.00157 -4.038 0.00483 0.45 4 56618 69214.256 0.00141 -4.038 0.00482 0.44 4 56618 69230.255 0.00123 -4.038 0.00482 0.42 4 56618 69246.255 0.00137 -4.038 0.00481 0.41 4 56618 69262.256 0.00271 -4.038 0.00481 0.47 4 56618 69278.255 -0.00120 -4.038 0.00480 0.45 4 56618 69294.255 0.00063 -4.038 0.00480 0.43 4 56618 69310.255 -0.00200 -4.038 0.00479 0.45 4 56618 69326.255 0.00045 -4.038 0.00479 0.43 4 56618 69342.255 0.00018 -4.038 0.00479 0.40 4 56618 69358.256 0.00052 -4.038 0.00479 0.38 4 56618 69374.256 -0.00409 -4.038 0.00478 0.48 4 56618 69390.256 -0.00176 -4.038 0.00478 0.48 4 56618 69406.256 -0.00826 -4.038 0.00503 0.83 4 56618 69422.256 -0.00668 -4.038 0.00500 0.98 4 56618 69438.255 -0.01028 -4.039 0.00497 0.000126 4 56618 69454.256 -0.00961 -4.039 0.00494 0.000146 4 56618 69470.256 -0.00898 -4.039 0.00492 0.000156 4 56618 69486.255 -0.00908 -4.039 0.00490 0.000167 4 56618 69502.255 -0.00916 -4.040 0.00489 0.000173 4 56618 69518.256 -0.00660 -4.040 0.00487 0.000173 4 56618 69534.255 -0.00817 -4.040 0.00486 0.000176 4 56618 69550.255 -0.00319 -4.040 0.00488 0.000167 4 56618 69566.254 -0.00368 -4.040 0.00486 0.000159 4 56618 69582.255 -0.00257 -4.040 0.00485 0.000151 4 56618 69598.256 -0.00152 -4.040 0.00484 0.000142 4 56618 69614.255 -0.00218 -4.040 0.00483 0.000134 4 56618 69630.256 0.00032 -4.040 0.00482 0.000125 4 56618 69646.255 -0.00193 -4.040 0.00482 0.000118 4 56618 69662.255 -0.00076 -4.040 0.00481 0.000111 4 56618 69678.255 0.00197 -4.040 0.00481 0.000105 4 56618 69694.255 0.00438 -4.040 0.00480 0.000105 4 56618 69710.256 0.00031 -4.040 0.00480 0.98 4 56618 69726.256 0.00220 -4.040 0.00479 0.93 4 56618 69742.254 0.00779 -4.040 0.00490 0.000112 4 56618 69758.255 0.00721 -4.040 0.00488 0.000120 4 56618 69774.256 0.00349 -4.040 0.00487 0.000117 4 56618 69790.255 0.00612 -4.039 0.00486 0.000122 4 56618 69806.255 0.00637 -4.039 0.00485 0.000126 4 56618 69822.255 0.00353 -4.039 0.00484 0.000123 4 56618 69838.256 0.00660 -4.039 0.00483 0.000127 4 56618 69854.255 0.00179 -4.039 0.00483 0.000120 4 56618 69870.256 0.00327 -4.039 0.00482 0.000115 4 56618 69886.256 0.00252 -4.039 0.00481 0.000110 4 56618 69902.256 0.00306 -4.039 0.00481 0
Re: [ntp:questions] Slow convergence loopstats (but nice results)
On 2013-11-22, Brian Inglis wrote: > On 2013-11-22 09:19, schmidt.r...@gmail.com wrote: >> I have just written a PHC driver for NTP and tested it on this system: >> Supermicro SYS-50150EHF-D525 which has a pair of Intel 82574L NICs which >> have >> IEEE 1588 hardware-based timestamping. I'm using NTP dev 4.2.7p397 onLinux >> kernel 3.12 with linuxptp. One of the PHCs is sync'd via PTP to an FEIZyfer >> Gsync GrandMaster, which is in turn synced via 5MHz to the USNO Master Clock >> #2. >> >> I'm running ptp4l to sync PHC1 to the GrandMaster. Then NTP is reading the >> refclocks PHC0, PHC1 and an NTP server on the LAN ptp2: >> >> ntpq -p >> remote refid st t when poll reach delay offset >> jitter >> == >> +PHC(0) .PTP.0 l 15 16 3770.0000.000 >> 0.000 >> *PHC(1) .PTP.0 l2 16 3770.000 -0.001 >> 0.000 >> +ptp2.IRIG. 1 u 38 64 3770.1230.018 >> 0.007 >> >> After about 15 hours the loopstats shows a s.d. of +/- 0.579 microsec with >> peak-peak 2.52 microsec (3,073 points). Very superb. >> >> However, it took fully 75 minutes at start to converge. It took that long to >> remove 20ms of phase error. I have never seen such a slow convergence. Very >> smooth too. I have tested the NMEA/ATOM drivers on this system and the >> convergence was the normal few minutes. Any suggestions? Can email plots.. >> >> Rich Schmidt >> Time Service Dept >> US Naval Observatory > > You do not appear to be delivering PPS via kernel PPS, an ATOM driver, or > user mode > PPS, with PHC0/1 as your prefer peer. You want to see o before your ref > clock, so > that may explain slow convergence compared to using the ATOM driver! > > Does Linux PTP have an interface to provide timestamp interrupts to Linux > kernel PPS, > and can you set that up, or add user mode PPS to your driver? There are > example user > mode PPS patches for Raspberry Pi Raspian Linux NTP, and in > ports/winnt/ntpd/ntp_iocompletionport.c. He says he is using a NIC which has hardware timestamping on it. Thus the interrupt is irrelevant. The timestamping is already done before the computer ever gets the packet. He wrote a driver (whever PCH stands for). I guess the key problem with a hardware timestamp NIC is to get a good estimate of the time difference between the NIC clock and the system clock. > > You could compare your loopstats to your ref clock peerstats, and also your > driver > clockstats if you are generating them? > Loopstats offset/jitter should track your ref clock peerstats offset/jitter > exactly, > and comparing to your clockstats may point you to causes. ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Slow convergence loopstats (but nice results)
Rich, Improving convergence time is important to the NTP Project. If there's a bug in the code or in the algorithms let's identify and fix it. If there is a known "offset to true time" then let's increase support for http://nwtime.org/projects/timestamp-api/ so it can start being deployed and applications can benefit from the available new information. There are good reasons the current system clock libraries cannot and should not be expected to return the best known time in any given moment. Different applications have different needs. If you need an API that produces a timestamp that can tell you the best idea of correct time, along with any expected offset between the system clock and the correct time, the expected and maximum errors, the timescale, a count of the number of discontinuities of the timeline, etc. then you want to support this new project. -- Harlan Stenn http://networktimefoundation.org - be a member! ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Slow convergence loopstats (but nice results)
On 2013-11-22 14:12, unruh wrote: On 2013-11-22, Brian Inglis wrote: On 2013-11-22 09:19, schmidt.r...@gmail.com wrote: I have just written a PHC driver for NTP and tested it on this system: Supermicro SYS-50150EHF-D525 which has a pair of Intel 82574L NICs which have IEEE 1588 hardware-based timestamping. I'm using NTP dev 4.2.7p397 onLinux kernel 3.12 with linuxptp. One of the PHCs is sync'd via PTP to an FEIZyfer Gsync GrandMaster, which is in turn synced via 5MHz to the USNO Master Clock #2. I'm running ptp4l to sync PHC1 to the GrandMaster. Then NTP is reading the refclocks PHC0, PHC1 and an NTP server on the LAN ptp2: ntpq -p remote refid st t when poll reach delay offset jitter == +PHC(0) .PTP.0 l 15 16 3770.0000.000 0.000 *PHC(1) .PTP.0 l2 16 3770.000 -0.001 0.000 +ptp2.IRIG. 1 u 38 64 3770.1230.018 0.007 After about 15 hours the loopstats shows a s.d. of +/- 0.579 microsec with peak-peak 2.52 microsec (3,073 points). Very superb. However, it took fully 75 minutes at start to converge. It took that long to remove 20ms of phase error. I have never seen such a slow convergence. Very smooth too. I have tested the NMEA/ATOM drivers on this system and the convergence was the normal few minutes. Any suggestions? Can email plots.. Rich Schmidt Time Service Dept US Naval Observatory You do not appear to be delivering PPS via kernel PPS, an ATOM driver, or user mode PPS, with PHC0/1 as your prefer peer. You want to see o before your ref clock, so that may explain slow convergence compared to using the ATOM driver! Does Linux PTP have an interface to provide timestamp interrupts to Linux kernel PPS, and can you set that up, or add user mode PPS to your driver? There are example user mode PPS patches for Raspberry Pi Raspian Linux NTP, and in ports/winnt/ntpd/ntp_iocompletionport.c. He says he is using a NIC which has hardware timestamping on it. Thus the interrupt is irrelevant. The timestamping is already done before the computer ever gets the packet. He wrote a driver (whever PCH stands for). I guess the key problem with a hardware timestamp NIC is to get a good estimate of the time difference between the NIC clock and the system clock. My point is that without other indicators, these are just another bunch of ref clock timestamps being delivered into the discipline control loop. When these are known to be high quality samples, that needs to be indicated to ntpd by adapting the PPS and/or kernel APIs, as those appear to be the only ways to influence ntpd, as documented at http://www.eecis.udel.edu/~mills/ntp/html/extern.html under External Clock Discipline. -- Take care. Thanks, Brian Inglis ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Slow convergence loopstats (but nice results)
On Saturday, November 23, 2013 1:20:37 AM UTC-5, Brian Inglis wrote: > On 2013-11-22 14:12, unruh wrote: > My point is that without other indicators, these are just another bunch of > ref clock > > timestamps being delivered into the discipline control loop. > > When these are known to be high quality samples, that needs to be indicated > to ntpd > > by adapting the PPS and/or kernel APIs, as those appear to be the only ways to > > influence ntpd, as documented at > http://www.eecis.udel.edu/~mills/ntp/html/extern.html > > under External Clock Discipline. > > -- > > Take care. Thanks, Brian Inglis Well Brian, if what you say above was a correct understanding of Mill's documentation, USNO could not have influenced the NTP stratum 1 business since back in 1996. In truth NTP is designed to obtain time of day from refclocks via the refclock_process() routine which allows one to stuff a refclockproc structure with time of day from a clock, and this is what USNO has always done. My new prototype driver refclock_phc() uses as its clock the PTP Hardware Clock (PHC) found on one of the newer LAN NICs which are PTP (IEEE 1588) aware. This driver is producing phenomenal results (under LINUX 3.12 with linuxPTP): the overlapping Allan deviation computed from loopstats phase offsets alone reaches a stability of 6e-12 in under 2e5 seconds, and the modified Allan deviation reaches 2e-13. This is quite useful, as eventually most all NICs will be PTP-enabled, and can be used as slaves as above, or even GrandMasters (with GPS, for example). I will ship my driver to Network Time Foundation when it is completed. This is a practical realization of PTP-NTP partnering in a refclock driver! Regards, Rich Schmidt ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Slow convergence loopstats (but nice results)
schmidt.r...@gmail.com wrote: My new prototype driver refclock_phc() uses as its clock the PTP Hardware Clock (PHC) found on one of the newer LAN NICs which are PTP (IEEE 1588) aware. This driver is producing phenomenal results (under LINUX 3.12 with linuxPTP): the overlapping Allan deviation computed from loopstats phase offsets alone reaches a stability of 6e-12 in under 2e5 seconds, and the modified Allan deviation reaches 2e-13. This is extremely nice! Do you use the PTP hw to also timestamp actual ntp packets, or just the onboard tcxo (or whatever the LAN card osc is) as a stable time base? Terje This is quite useful, as eventually most all NICs will be PTP-enabled, and can be used as slaves as above, or even GrandMasters (with GPS, for example). I will ship my driver to Network Time Foundation when it is completed. This is a practical realization of PTP-NTP partnering in a refclock driver! Regards, Rich Schmidt ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Slow convergence loopstats (but nice results)
I do the latter. To use PTP to timestamp one would have to modify NTP source outside of refclock_phc(), which we would not presume to do. However the PHC loopstats has a standard deviation of 0.58 microseconds, so we are not far off in using standard NTP timestamping. Rich Schmidt > Do you use the PTP hw to also timestamp actual ntp packets, or just the > > onboard tcxo (or whatever the LAN card osc is) as a stable time base? > > > > Terje > ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Slow convergence loopstats (but nice results)
schmidt.r...@gmail.com wrote: I do the latter. To use PTP to timestamp one would have to modify NTP source outside of refclock_phc(), which we would not presume to do. However the PHC loopstats has a standard deviation of 0.58 microseconds, so we are not far off in using standard NTP timestamping. OK! It is extremely sad that history have saddled us with extremely poor motherboard clock crystals, but now, more than 30 years after the original IBM PC, we're getting something which is a couple of orders of magnitude better, but as a pure side-effect of the need to time network packets. :-( Terje Rich Schmidt Do you use the PTP hw to also timestamp actual ntp packets, or just the onboard tcxo (or whatever the LAN card osc is) as a stable time base? 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] Slow convergence loopstats (but nice results)
schmidt.r...@gmail.com wrote: My new prototype driver refclock_phc() uses as its clock the PTP Hardware Clock (PHC) found on one of the newer LAN NICs which are PTP (IEEE 1588) aware. This driver is producing phenomenal results (under LINUX 3.12 with linuxPTP): the overlapping Allan deviation computed from loopstats phase offsets alone reaches a stability of 6e-12 in under 2e5 seconds, and the modified Allan deviation reaches 2e-13. This is quite useful, as eventually most all NICs will be PTP-enabled, and can be used as slaves as above, or even GrandMasters (with GPS, for example). Some time ago we at Meinberg have made some tests with hardware time stamping of incoming and outgoing NTP packets on our own NIC, and we saw that in this case the resulting accuracy with pure NTP is the same as with NTP. A major problem was that the standard NTP protocol doesn't support a way to send the captured time stamp of a previously sent packet to its client, as done by the so-called followup message in PTP. I don't know if new standard NIC chips which support PTP timestamping can also timestamp NTP packets, but even if they do then in practice there's still the problem with network switches, etc. There are network switches out there which are PTP-aware and also timestamp incoming and outgoing PTP packets to compensate the introduced packet delay in some way, but there are no switches (AFAIK) which can do this with NTP packets, so even if you used hardware time stamping of NTP packets on NTP end nodes the resulting accuracy would still be worse than with PTP. That's too sad. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Slow convergence loopstats (but nice results)
On Thu, Dec 12, 2013 at 09:59:03AM +0100, Martin Burnicki wrote: > A major problem was that the standard NTP protocol doesn't support a > way to send the captured time stamp of a previously sent packet to > its client, as done by the so-called followup message in PTP. ntpd has the peer and broadcast interleave modes to send the followup time stamps. http://www.eecis.udel.edu/~mills/ntp/html/xleave.html Also, there is a feature called launch time, which is supported in some NICs, so the follow up message is not always necessary. > I don't know if new standard NIC chips which support PTP > timestamping can also timestamp NTP packets, but even if they do > then in practice there's still the problem with network switches, > etc. Some NICs can time stamp any packets. > There are network switches out there which are PTP-aware and also > timestamp incoming and outgoing PTP packets to compensate the > introduced packet delay in some way, but there are no switches > (AFAIK) which can do this with NTP packets, so even if you used > hardware time stamping of NTP packets on NTP end nodes the resulting > accuracy would still be worse than with PTP. > > That's too sad. Agreed. I think it's possible to implement a HW NTP support, but there is problem that the switch would have to keep some state about each NTP association. If there was a standardized extension field to store the processing delay in both directions, that wouldn't be necessary. I'm not sure what would have to be done to not break the NTP authentication. A major advantage NTP has over PTP is that it knows the delay for each measurement in the client/server and symmetric modes, which allows it to filter out bad measurements. In PTP the delay is measured independently (similarly to the NTP broadcast mode), so bad measurements can't be easily ignored and it's necessary to have all networking HW with PTP support to account for all processing delays. -- Miroslav Lichvar ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Slow convergence loopstats (but nice results)
What about NTP's interleave mode (xleave)? H ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Slow convergence loopstats (but nice results)
Harlan Stenn wrote: What about NTP's interleave mode (xleave)? Please see my reply to Miroslav. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Slow convergence loopstats (but nice results)
Miroslav Lichvar wrote: On Thu, Dec 12, 2013 at 09:59:03AM +0100, Martin Burnicki wrote: A major problem was that the standard NTP protocol doesn't support a way to send the captured time stamp of a previously sent packet to its client, as done by the so-called followup message in PTP. ntpd has the peer and broadcast interleave modes to send the followup time stamps. http://www.eecis.udel.edu/~mills/ntp/html/xleave.html Yes, but as you say above this is only supported in peer associations and broadcast mode, so I see no benefit for "normal" clients. :-( Also, there is a feature called launch time, which is supported in some NICs, so the follow up message is not always necessary. OK, but if I understand correctly then the sending ntpd would have to know that a specific interface supports this, and put the lauch time as transmit time into the NTP packet, and schedule sending of the packet at the predetermined point in time. I see some potential problems here if using this with ntpd. I'm assuming the process or task (launcher?) which has to send the packets at the predetermined launch time is located somewhere down in the lowest levels of the network stack. So the lanuch time determined by ntpd must be "far enough" after the current time so that the launcher has surely received the packet to be sent *before* the current time reaches the launch time. If the launch time is too near in the future then the launcher might receive a packet from ntpd after the launch time has already passed. If the launch time is too far in the future the launcher has to queue the packet for "a long time" before it can be sent, and there might be a limited queue size if a large number of packets have to be sent, e.g. to a large number of clients. To avoid this the launcher could be aware of special NTP packets, send each packet when a free "slot" is available on the wire, and put the current time into each sent packet. If this is not possible, then ntpd would have to keep track ot the packet is has scheduled to be launched at a given time on a given interface. Otherwise It could schedule 2 packets for different clients with the same launch time. And what happens if a different application schedules a different packet on the same interface with the same launch time? This sound pretty error-prone to me. :-( I don't know if new standard NIC chips which support PTP timestamping can also timestamp NTP packets, but even if they do then in practice there's still the problem with network switches, etc. Some NICs can time stamp any packets. OK, that's great. There are network switches out there which are PTP-aware and also timestamp incoming and outgoing PTP packets to compensate the introduced packet delay in some way, but there are no switches (AFAIK) which can do this with NTP packets, so even if you used hardware time stamping of NTP packets on NTP end nodes the resulting accuracy would still be worse than with PTP. That's too sad. Agreed. I think it's possible to implement a HW NTP support, but there is problem that the switch would have to keep some state about each NTP association. If there was a standardized extension field to store the processing delay in both directions, that wouldn't be necessary. I'm not sure what would have to be done to not break the NTP authentication. Yes, I know. Authentication is still another restriction which makes things even more difficult. A major advantage NTP has over PTP is that it knows the delay for each measurement in the client/server and symmetric modes, which allows it to filter out bad measurements. In PTP the delay is measured independently (similarly to the NTP broadcast mode), so bad measurements can't be easily ignored and it's necessary to have all networking HW with PTP support to account for all processing delays. Agreed. I'm very impressed how good NTP can determine and compensate varying network latencies over WAN connections with unknown network nodes on the route. Martin -- Martin Burnicki Meinberg Funkuhren Bad Pyrmont Germany ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Slow convergence loopstats (but nice results)
Martin Burnicki wrote: There are network switches out there which are PTP-aware and also timestamp incoming and outgoing PTP packets to compensate the introduced packet delay in some way, but there are no switches (AFAIK) which can do this with NTP packets, so even if you used hardware time stamping of NTP packets on NTP end nodes the resulting accuracy would still be worse than with PTP. That's too sad. What about an RFC for ntp over ptp ;-? uwe ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Slow convergence loopstats (but nice results)
Uwe Klein wrote: Martin Burnicki wrote: There are network switches out there which are PTP-aware and also timestamp incoming and outgoing PTP packets to compensate the introduced packet delay in some way, but there are no switches (AFAIK) which can do this with NTP packets, so even if you used hardware time stamping of NTP packets on NTP end nodes the resulting accuracy would still be worse than with PTP. That's too sad. What about an RFC for ntp over ptp ;-? There are a number of possible ways to implement this. - As a special refclock driver as has been described here - As an additional daemon which just feeds tthe SHM driver - Have a PTP daemon running and disciplinin the system time, and just use ntpd with it's "local clock" driver to make the disciplined time available via NTP ;-) Martin ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
