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
[ntp:questions] Power-saving patch to NTP
I came across the following page: http://www.lesswatts.org/projects/powertop/known.php which says the following on ntpd: By default, the ntp time synchronization daemon will wake up once per second, and will make the kernel do work on it's behalf even more. Red Hat has created a patch to ntp to fix this issue and ships it in their rawhide and FC7 ntp packages. You can download this patch from the Fedora cvs server. Has anyone here looked at that patch? Does it compromise correctness of the algorithms? Thanks, Jan ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
Jan, A timer interrupt is required each second to update the clock frequency no matter what. In addition, a sweep is made through the associations to see if a poll is pending. It would be in principle posssible to implement a system of queues to avopid sweeping the associations each second, but that would save very few cycles, add some more cycles and additional complexity. My advice is to avoid the patch; however, be advised if used it might not work in future as the code is further refined. Dave Jan Ceuleers wrote: I came across the following page: http://www.lesswatts.org/projects/powertop/known.php which says the following on ntpd: By default, the ntp time synchronization daemon will wake up once per second, and will make the kernel do work on it's behalf even more. Red Hat has created a patch to ntp to fix this issue and ships it in their rawhide and FC7 ntp packages. You can download this patch from the Fedora cvs server. Has anyone here looked at that patch? Does it compromise correctness of the algorithms? Thanks, Jan ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
Re: [ntp:questions] Power-saving patch to NTP
David L. Mills [EMAIL PROTECTED] writes: Jan, A timer interrupt is required each second to update the clock frequency no matter what. In addition, a sweep is made through the associations to I thought that the ntp daemon runs the per second routine only if the kernel discipline is not available. And Linux I thought has the kernel discipline. Now of course I suspect that the kernel has to wake itself even more often than once a second (eg the timer interrupt) and if it did not, the effect on the time discipline would be pretty bad. see if a poll is pending. It would be in principle posssible to implement a system of queues to avopid sweeping the associations each second, but that would save very few cycles, add some more cycles and additional complexity. My advice is to avoid the patch; however, be advised if used it might not work in future as the code is further refined. Dave Jan Ceuleers wrote: I came across the following page: http://www.lesswatts.org/projects/powertop/known.php which says the following on ntpd: By default, the ntp time synchronization daemon will wake up once per second, and will make the kernel do work on it's behalf even more. Red Hat has created a patch to ntp to fix this issue and ships it in their rawhide and FC7 ntp packages. You can download this patch from the Fedora cvs server. Has anyone here looked at that patch? Does it compromise correctness of the algorithms? Thanks, Jan ___ questions mailing list questions@lists.ntp.org https://lists.ntp.org/mailman/listinfo/questions
