[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