[ntp:hackers] FreeBSD 6.1 and CHU/WWV
David L. Mills
mills at udel.edu
Fri Oct 27 14:39:54 PDT 2006
Judah,
I'm relaying this to the hackers list.
I'm very glad you intend to use FreeBSD 6.1 rather than Linux. I'm using
6.1 myself; however, I haven't poked into the ntp_getime() wrappers and
don't know where they can be found. Maybe some kind soul listening this
frequency can advise.
1. I have asked kernelmongers who use my code not to modify it, even if
they can "improve" it. The only kernel I know that uses it intact is the
Alpha. In both FreeBSD and Linux, some tiny things are not completely
faithful to the semantics that leave here. I don't remember when Noah
floated the Ark, and there have been a couple changes in semantics, most
obvious to add the TAI offset in the ntp_gettime() syscall. The return
values have not changed. See the nanokernel distribution at
ftp.udel.edu/pub/ntp/software and compare with FreeBSD kern_ntptime.c.
2. I've fudged the time offset of the QWWV driver by hand to compenstat
for the propagation delay and internal program delays. The driver keeps
generally within 100 microseconds of a GPS server with exceptions due
thw intrinsic wiggle of the audio codec and kernel timer. My ray tracing
program finds a 2-hop geometry with 9.7 ms delay almost all of the time.
The driver measures the time offset with a precision of 125 microseconds
and the frequency offset with a precision of one part in 10e7. I do see
small wiggles of 1-3 codec samples near sunrise on the eastern summit
and sunset on the western summit. While the CHU signal is stronger here,
the accuracy is not as good as WWV, mainly because the WWV signal design
makes possible a theoretically optimum, matched filter receiver.
3. Have you tried the current (or near-current) NTPv4 with the ACTS
driver as compared with your lockclock code? Figure 6.6 in my book shows
the frequency measured between Delaware and NIST over a 2000-hour
period. Note the maximum frequency prediction error is about 0.2 PPM
using a 36-hour call interval. The performance data shown in Chapter 6
for the various time servers scattered over the globe is simply amazing,
considering the Internet at least from here has become much faster and
less clogged than a few years ago.
Dave
Judah Levine wrote:
> Dave,
> I tried to post these comments to the ntp hackers mailing list in
> response
> to some recent comments there, but my messages were blocked.
>
> 1. I am in the process of upgrading the NIST time servers to FreeBSD
> 6.1, and there are some changes (bugs?) in the NTP kernel interface.
> ntp_gettime() and ntp_adjtime() return different values now from when
> Noah first used these calls in the ark. The previous versions returned
> the
> status of the clock as the value of the function, but this versions
> seems to
> return the status of the operation itself (which always succeeds).
> Have you
> noticed this? Is this a bug or a feature? I have looked into
> investigating the
> source of this problem, but I can't find the sources for the library
> functions
> that are user program links to. (I have the kernel source code of
> kern_ntptime.c,
> but there must be another user function as well in libc.)
> 2. I would guess that all of the signals from the various radio
> stations have
> a large variation near local sunrise and sunset, and that there would
> also
> be systematic differences between the time messages at any site due to
> the un-modeled portions of the path delays. Have you seen this stuff?
>
> Best wishes,
>
> Judah
>
>
>
More information about the hackers
mailing list