Subject: More on clock stuff...
To: None <current-users@netbsd.org>
From: Hal Murray <murray@pa.dec.com>
List: current-users
Date: 05/31/2000 12:58:42
[This is for 1.4Z]

> Does the GENERIC kernel have 'options NTP' ?

Yes, it's on in GENERIC and many other i386 config files.
It's not in BOAT_ANCHOR, KICKME, PS2, or SUN_LAMP

[But I'm using my own kernel which does have NTP turned on.] 


> Assuming "yes", it's normal for ntpd to jerk the clock around a little
> until it settles down, especially if it was 15 seconds off at bootup.
> How is it now that it's had time to stabilize?

Thanks for the "`ntpd_flags="-g"'" suggestion.  I'll add that to 
my bag of tricks and/or try it when I get a chance.

I run ntpdate at startup.  The jump I reported that started this 
discussion happened on a system that had been up for many hours.

It's probably caused by my UDP-blast-em test.  I'll try to run some 
more controled experiments. 

I am seeing the "increase NMBCLUSTERS" messages.  If I make that 
big enough will the messages go away?  Or will it just tie up more 
memory on the input dispatch queue before they get printed?

I've got it set to 4K which works fine for everything else I do. 

-----

I'm using the "time reset (step)" messages in the log file as an 
indication that clock update interrpts are (probably?) being lost.  
(I'm using eyeball filtering here.)  Then I look at the previous 
few lines to see if I can see what is causing them.  So far, things 
have gotten (much) better when I commented out a few no-buffer printfs 
from interrupt level. 


Here is a glitch I hadn't noticed before.  This is from an Alpha 
running 1.4.2 rather than -current.  I'll update this system soon 
so don't spend much time thinking about this area if it's changed 
a lot. 

May 31 03:20:30 foraker /netbsd: isp0: Bus 0 Target 0 at 10MHz Max Offset 8, 16 bit wide, Tagged Queueing Enabled
May 31 03:20:30 foraker /netbsd: isp0: Bus 0 Target 0 at 10MHz Max Offset 8, 16 bit wide, Tagged Queueing Enabled
May 31 03:38:24 foraker xntpd[190]: time reset (step) 0.140647 s

isp0 is the is the builtin SCSI chain with one disk that I'm not 
using.  I'm actually running off /dev/sd1 on isp1 - an external StorageWorks 
box so I can easily swap disks. 

Is this part of the disk/scsi code locking out interrupts for extended 
chunks of time?