On Tue, 13 Dec 2005, Uwe Dippel wrote:
> On Mon, 12 Dec 2005 22:30:07 -0500, Nick Holland wrote:
>
> > 1) set time properly, using rdate or ntpd -s.
>
> Done
>
> > 2) now how does it do?
>
> Drifting off:
>
> Dec 13 12:49:00 cip ntpd[26647]: ntp engine ready
> Dec 13 12:49:22 cip ntpd[26647]: peer 172.16.0.4 now valid
> Dec 13 12:50:16 cip ntpd[22805]: adjusting local clock by 39.362721s
> Dec 13 12:54:45 cip ntpd[22805]: adjusting local clock by 40.094713s
> Dec 13 12:55:20 cip ntpd[22805]: adjusting local clock by 45.676478s
> Dec 13 12:59:15 cip ntpd[22805]: adjusting local clock by 50.446791s
> Dec 13 13:02:33 cip ntpd[22805]: adjusting local clock by 51.229806s
> ...
> Dec 13 15:48:58 cip ntpd[22805]: adjusting local clock by 274.515302s
> Dec 13 15:52:48 cip ntpd[22805]: adjusting local clock by 279.199983s
> Dec 13 15:56:08 cip ntpd[22805]: adjusting local clock by 283.888464s
>
>
> > HOWEVER, you may be dealing with a drift that is much bigger than ntpd
> > is designed to handle. Don't expect ntpd to make sense of a wildly
> > drifting clock, it is only designed to provide little nudges in the
> > right direction, not rework the entire clock hardware and software to
> > compensate for a problem.
>
> I am pretty sure that this is what it is.
There is a fix in current concerning adjtime() adjusting in the wrong
direction, but that only happens with much larger offsets. That fix
also has nothing to do with UP vs MP. You are looking at a genuine mp
bug, it seems.
> So my question remains valid: How to get bsd.mp calculate time properly
> when bsd does ?
I have seen some some timekeeping related problems. But so far no
developer stepped up the really solve them. In most cases, the
problems are not that big. But your hardware seems to be exposing a
bug in a much more dramatic way.
> I had some suggestions in that earlier thread, but all was about setting
> ACPI, TSC. Nothing similar in the vast range of HP's BIOS settings.
> I read the config, in order to switch off ACPI, but as far as I found,
> there's naught.
>
> I feel a bit depressed, because I had made all this fuss about getting
> Dual core and run all the Internet-facing servers of our College of IT on
> OpenBSD; and now we're down to run single core. Makes me look stupid. I
> already had the first chap 'generously' offering to 'help out' with Fedora.
It is more or less to be expected that new hardware exposes problems
once in a while. Most of the time, things will be fine, but not always.
OpenBSD developers have (access to) a lot of gear, but not everything
under the sun. Also, most of the time, we only get access to new
hardware once it has been on the market for a while. New hardware does
not arrive magically in our hands. Keep that in mind when selecting
machines.
-Otto
