Amitai Schlair writes;

>Bill Studenmund wrote:
>
>> > > >I read that 1.3 integrates NTP into the system. I'd like to run
>> > > >xntpd, but I just can't find tickadj anywhere on my machine. How much
>> > > >of the NTP package is included?
>> > > 
>> > > Tickadj is used to tweak kernel parameters to improve ntp operation.
>> > > Since there is already ntp support built into the kernel I expect it's
>> > > not needed, hence not provided.
>> > 
>> > Yabut, the FAQ says:
>> 
>> Uhm, blow off the FAQ here. This FAQ entry was written before ntp got
>> integrated. Things might have changed a little with the integration.
>> 
>> The xntpd man page mentions an ntpq and an xntpdc program to see how it's
>> doing. Also, you can turn on debugging.
>> 
>> Check out the man page, I think it'll be your friend.
>
>I looked at all the man pages. (They weren't real helpful, at least not
>for me.) I also tried the xntpdc program (ntpq looks like it's used to
>configure an NTP server, which I most certainly am not!), to no avail.

That's not quite right. Any machien running xntpd is a server.  It may
be a high-stratum server towards the leaf of an NTP tree, but ntpq is
still very useful for figuring out what's going wrong.

Id try staring ntpq and doing
	rv
to see what the in-kernel PLL state is.


>Finally, I turned on debugging in xntpd, but I can't make out what's
>going on.


I would try something like
	statsdir /var/spool/ntpstats/   # A directory for statistics files
	filegen loopstats file loopstats type day enable
	filegen clockstats file clockstats type day enable

which if I remember correctly, turns on daily logfiles of significant
events of both the PLL loop and your local clock.


>I've been running ntpdate on boot, so my problem is likely not that the
>clock is too far off to begin with. Time is synced right after boot, so
>ntpdate is doing its job, but the machine loses time exactly as though
>no NTP were being done.

You're doing ntpdate -b, right? 

>Thinking ahead a bit, to when I'll have this solved (I know I will!):
>www.netbsd.org ought to start putting together an enormous pile of
>platform-independent HOWTOs, especially with all the new functionality
>of 1.3.

Umm, sorry, but I think this is platform-dependent.  I've set up ntp
on NetBSD 1.2C and thereabouts, and 1.3, on pmaxes, i386, and sparcs.
The only problem Ive heard of were on the Sparcs, where some of the
pmap code was running at the wrong IPL level and blocking out clock
interrupts.

The very simplest thing is to run 

	systat -w1 vmstat

and eyeball the interrupt rate from the clock. If you're losing clock
interrupts the interrupt rate should be obviously low, or even
wandering.  That's the first thing I'd check with these symptoms.
(i.e., the clock wanders even when NTP is not running, right?)  As I
said on comp.protocols.time.ntp, I'd suspect something like a PPP link
blocking out clock-tick interupts.  (Surely Apple didn't use crystals
that are off by nearly 5%?)

--Jonathan

PS: if you want a reply to this, please CC: me since I dont read
port-mack68k.