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?