Re: [ntp:questions] Does an IPV6 address work with NTPD?
Dear colleagues: The NIST server time-d (ipv4=129.6.15.27, ipv6=2610:20:6f15:15::27) currently receives approximately 400 NTP requests per second. About 30% of these are from ipv6 addresses. The server has been operating for a bit more than 2 years. Best wishes, Judah Levine Time and Frequency Division NIST Boulder On Thursday, November 27, 2014 7:10:02 AM UTC-7, Charles Elliott wrote: The U.S. Government (NIST) has a new time server (time-d.nist.gov) whose address is 2610:20:6F15:15::27. When I put that address into ntp.conf the Meinberg Time Server Monitor indicates Unknown clock type in the Type column and Reach remains 000. However, when 2610:20:6F15:15::27 is pinged the return is General failure. (Dr.) Judah Levine, Time and Frequency Division, NIST Boulder, says 2610:20:6F15:15::27 works as far as he can tell. So, do IPV6 addresses result in anything useful when used in NTPD? Charles Elliott ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] Failure of NIST Time Servers
I am writing to reply to the previous comments: 1. I have no comment about whether or not the failure and the response to it are or are not professional. 2. The failure was directly caused by a double hardware failure -- a problem in Boulder and an unrelated problem in Fort Collins at essentially the same time. It is trivially easy to design an algorithm that would have detected this exact problem after it has occurred, but it would be much more difficult to have done so beforehand. The fact that the system did not have this particular algorithm to deal with this particular double failure is not a bug in the usual sense of that word. 3. We have a lot of safeguards built into the systems and we have a lot of experience running them. We have been running time servers for about 20 years, and I can't remember the last failure of this magnitude. I have made some changes to deal with the problem of the relative unreliability of the backup systems in Fort Collins, and this particular problem will not happen again. But it would be foolish of me to promise that the system is perfect and that some other failure, *with equally serious impact*, will never happen again. We have more than 100 computers in the network and lots of ancillary stuff, and it would be foolish and simplistic of me to guarantee that I (or anyone else) have thought of every possible hardware failure. 4. The unhealthy flag in NTP (both leap second bits set) is a copy of an internal private kernel parameter. This parameter can be set by a number of internal check processes (which are outside of NTP and independent of it) and it can also be set from Boulder if the central controller detects a problem. A complete failure of the ACTS system would have set the unhealthy flag unconditionally, but the partial failure that actually occurred may not do so. The same kernel parameter is used to control the status parameters of the other non- NTP services that we provide. 5. Since hardware failures are probably inevitable in a network system of the size and complexity of the NIST service, a fair question is whether the failure can be limited and its impact contained or ideally made invisible to the users. The failure affected 11 of the 35 physical time servers that I operate. So the glass starts out about 1/3 empty and 2/3 full. About half of the 11 physical servers were transmitting the unhealthy status and should not have caused any problems for users who parse the flags. So, even during the worst failure in my memory, the glass is about 1/7 empty and 6/7 full. Judah Levine Time and Frequency Division NIST Boulder ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
[ntp:questions] Failure of NIST Time Servers
The primary and backup ACTS servers that are used to synchronize the NIST Internet time servers to the atomic clock ensemble in Boulder failed on Wednesday 24 May at about 1900 UTC (1300 MDT). The failure affected 11 of the 35 NIST Internet time servers, and the time transmitted by the affected servers was wrong by up to 680 seconds. In most cases, the incorrect time was accompanied by the unhealthy indicator, but some of the systems transmitted the wrong time without this indication. The other 24 servers were not affected. In some cases, one of the physical servers at a site was affected while the others were not, so that repeated requests to the public site address resulted in time messages that differed by up to 680 seconds. The ACTS servers have been fully repaired as of 27 May, 1800 UTC (1200 MDT), and all of the servers should be resynchronized within a few hours. There may be a transient error of up to 10 milliseconds during this period. I apologize for this failure, and I regret the problems and inconvenience that have resulted. Judah Levine jlev...@boulder.nist.gov ___ questions mailing list questions@lists.ntp.org http://lists.ntp.org/listinfo/questions
Re: [ntp:questions] demonstrate traceability to UTC
On Mar 12, 10:06 am, Tom tom_e_...@hotmail.com wrote: To All, How do you demonstrate the traceability of the NTP solution to BIPM UTC? Hello, This is a rather complicated question. The answer depends on these preliminary issues: 1. Do you need technical traceability, which would be adequate to provide a time reference derived from national time standards or do you need *legal* traceability in which you must be prepared to convince a jury in an adversary proceeding that your time was correct at some instant? 2. What level of accuracy/uncertainty do you need in the time stamps? 3. What level of reliability do you need in the process? That is, suppose the system that provided the time stamps were to fail. How long could you wait for it to be repaired? 4. Each of these questions is going to have a cost/benefit trade- off. How much are you willing to spend (in time or money or ...) to achieve your requirement? I would be happy to discuss these issues in this forum or off-line. Judah Levine Time and Frequency Division NIST Boulder ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Very rapid polling
Thanks to all of you who responded to my initial post regarding very rapid polling. I have fixed this particular instance with some cooperation from the ISP. However, the generic problem remains and is likely to re-appear. I don't know of a good general solution to this problem because: 1. the KOD packets are generally not effective. Either the remote software does not recognize them or it chooses to ignore them. The KOD method obviously would not work against an attack. 2. Sending any reply at all doubles the network traffic and makes an attack more effective. Therefore, all of the NIST servers log the event and the source ip but do not respond. I think it is not appropriate for a national timing laboratory to knowingly send the wrong time. 3. This sort of stuff is really more general than NTP -- denial of service attacks can use many different protocols and a more general network solution is going to be needed. 4. A serious denial-of-service attack probably requires a botnet to cause real trouble, and fixing that problem might reduce the impact of all denial of service attacks. Judah Levine Time and Frequency Division NIST Boulder ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Very rapid polling
On Feb 9, 8:26 pm, ma...@ntp.isc.org (Danny Mayer) wrote: jlevine wrote: In the last few days I have seen an increasing number of systems that are requesting the time in NTP format several times per second. This poll interval is far in excess of the usual best practices. Since there are a number of such systems, it is possible that this problem is a result of a new version of NTP that has just been released. Please let me know if you have any information about a new version of NTP that can do this or if any of you are seeing the same problem. Thanks. Judah Levine Time and Frequency Division NIST Boulder Hi Judah, There is no new release yet (the 4.2.4p6 was just a patch release to fix a couple or minor issues mainly related to OpenSSL. It is most unlikely that ntp is doing this. Did you take a couple of the addresses and query them with ntpq? I don't think that ntpd can be configured to query that quickly. Harlan is preparing a new stable release from the development branch. Dave has added KOD code to deal with situations like this and such clients are likely to find their clock drifting off if the do not follow the protocols. Danny Hello, I have the ip addresses that are causing the problems. I have not contacted the ISPs because my previous experience is that they are very unhelpful in dealling with these sorts of queries. However, the sources are domestic addresses, so perhaps there is a chance. I was pretty sure that this was not caused by a bug in a new version of NTP, but I just wanted to check for sure. (I remember that some older versions of Linux could use a poll interval of 0 by default, but that was a long time ago.) These sorts of problems come and go on all of our servers pretty much all of the time. Most of them are just annoying, but this one is serious enough to cause possible trouble. Thanks for your prompt replies. Judah Levine Time and Frequency Division NIST Boulder ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Very rapid polling
In the last few days I have seen an increasing number of systems that are requesting the time in NTP format several times per second. This poll interval is far in excess of the usual best practices. Since there are a number of such systems, it is possible that this problem is a result of a new version of NTP that has just been released. Please let me know if you have any information about a new version of NTP that can do this or if any of you are seeing the same problem. Thanks. Judah Levine Time and Frequency Division NIST Boulder ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
[ntp:questions] Sunfire X2100 and FreeBSD
Hello, I am trying to use a Sunfire X2100 system as a time server using FreeBSD 6.2. The system clock steps by tens of microseconds every few minutes with no time software running. I have not seen this on other non-Sun systems with the identical version of FreeBSD. Is this a feature of the Sun hardware? If yes, can it be turned off? Otherwise the time steps will confuse the synchronization process. Thanks. Judah Levine Time and Frequency Division NIST Boulder ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Dual Mixer Time Difference (DMTD) instruments sought
Hello, While it's unlikely that I will soon get to build such an instrument, I am quite interested in how they are built, if only to understand what can happen and why. Can you suggest some articles and/or books and/or patents delving into both the theory and the practicalities of building DMTD instruments? We (the time and frequency division of NBS/NIST) designed and built a dual-mixer systerm in 1980 (more or less). This same system is the one that still runs the atomic clock ensemble in Boulder. You can get the publications that describe this instrument from the publications database on our web site. Go to tf.nist.gov and click on the publications menu. When the menu appears, look for author Glaze. The stuff was published in about 1983 or so. There were several papers as I recall with various combinations of the folks who built the system and the software drivers for it. The system we built was totally analog, but a modern system would probably be fully digital. Our system had a resolution of about 0.2 ps and a stability of about 3-4 ps. A digital system could do better, mostly because the temperature sensitive stuff could be confined to the analog front end whereas we had to worry about temperature pretty much everywhere in the system. However, the job is not trivial, since even tiny impedance mismatches can cause problems at this sub-picosecond resolution. You should watch especially for the connectors and the cables. We typically use SMA connectors and rigid coax. The inputs are buffered with distribution amplifiers with a reverse isolation that is as good as we can make it. About -165 db, I think, although I have not looked at that recently. (Note that the problems are not adequate digital computing power but plain old analog electronics.) Even so, we have a detectable sensitivity to temperature at the level of ps. This noise level tends to be too small to affect the data from cesium standards, but it could be a problem if you were trying to calibrate the long-period performance of a device or a transmission system that had a small delay, since the residual diurnal temperature sensitivity could come to get you. If you are in this business then you need professional help. Judah Levine Time and Frequency Division NIST Boulder ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Dual Mixer Time Difference (DMTD) instruments sought
I may need a Dual Mixer Time Difference (DMTD) instrument, to measure picosecond changes in electrical length in a coax plus amplifier time reference signal distribution system with total delays in the hundreds of nanoseconds, currently operating at 10 MHz (sinewave), but with 100 MHz likely at some future date. What DMTD instruments are commercially available? A google search was not successful - all noise no detectable signal, probably because DMTD instruments are not that common, and many people build their own. We use dual-mixer systems in our primary time scale and also to calibrate and evaluate oscillators and timing hardware. So far as I know, the only units that are commercially available are made by Timing Solutions, which was recently acquired by Symmetricom. There are a number of different configurations, depending how how many devices you want to measure, whether they all run at the same frequency, etc. It is possible to build these devices on your own, but it is not trivial to get pico-second resolution and stability. Almost everything is temperature sensitive at this level of resolution. Judah Levine Time and Frequency Division NIST Boulder ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] NTP architecture recommendation
Hello, The degradations of Selective Availability included a number of different possible effects, but the one that was generally used was a relatively slow dither of the clock on the satellite. The dither on each satellite was different. Since GPS receivers determine a position by measuring the distance (signal transit time) from each satellite in view to the receiver, the dither produced a corresponding fluctuation in the position solution. The magnitude of the dither was much smaller than 1 microsecond, so that it would generally not be observable with the usual NTP setup. The corresponding errors in position were less than hundreds of meters, but the exact value varied. As with many other things, your mileage would vary. It was easy to see the effect on the position solutions of any GPS receiver, and the effect on the time solution could be seen with a reasonably good oscillator -- even a good quartz oscillator could see the effect over periods of seconds or minutes. Since the clock dithering had a mean of 0 in the long term, the long-term average solution (either position or time) had no offset. The degradation was primarily directed towards real-time applications or those timing applications where the local clock had such poor stability that it was impossible to average the received signal for any appreciable time so as to take advantage of the fact that the long- term mean was 0. The whole business was turned off in 2000, and it will probably never be used again, but you never know. Best wishes, Judah Levine Time and Frequency Division NIST Boulder ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
