Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 30 Nov 1998 15:31:46 +0100
From:      Poul-Henning Kamp <phk@critter.freebsd.dk>
To:        Mike Smith <mike@smith.net.au>
Cc:        cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG
Subject:   Re: cvs commit: src/sys/kern kern_clock.c 
Message-ID:  <12215.912436306@critter.freebsd.dk>
In-Reply-To: Your message of "Mon, 30 Nov 1998 06:10:29 PST." <199811301410.GAA03905@dingo.cdrom.com> 

next in thread | previous in thread | raw e-mail | index | archive | help
In message <199811301410.GAA03905@dingo.cdrom.com>, Mike Smith writes:
>> In message <199811301338.FAA03590@dingo.cdrom.com>, Mike Smith writes:
>> >> phk         1998/11/29 12:31:03 PST
>> >> 
>> >>   Modified files:
>> >>     sys/kern             kern_clock.c 
>> >>   Log:
>> >>   Make the previous behaviour the default, add a sysctl which you
>> >>   can set if your hw/sw produces the "calcru negative..." message.
>> >
>> >The sysctl should be automatically set by the "calcru negative ..."
>> >detection code.
>> 
>> No, because at that time you clock has already been warped out of
>> shape.  People need to know and be aware that their sw/hw has a problem.
>
>Since we can't do this except by screwing up, and for that one time you 
>can fudge things so that they're not fatal, I think this is a better 
>approach.

No.  I have no way from the kernel to make the change persistent, so
it would have to mess up once per boot.

>If you're suggesting that the only workaround for this so-called 
>"broken" hardware is to degrade all of our timekeeping resolution to 
>+/- 1 second, then I think that "botch" is being far too kind.

No, precision is actually better for some operations which don't need
it, on the downside they take longer time than they would on non-broken
hardware.

>I hope I'm misreading you here;
you are.

>I can't see where you get off 
>suggesting that the calcru problems are "rare"; I've seen them on every 
>Alpha I've used, for example, and I simply don't buy that they're 
>something that can't be dealt with correctly in software.  Everyone 
>else seems to get it right; we should too.

What is our HZ on alpha ?

How high a NTIMECOUNTER do you need to solve it for alpha with method=0 ?

Does method=1 solve the problem for alpha ?

--
Poul-Henning Kamp             FreeBSD coreteam member
phk@FreeBSD.ORG               "Real hackers run -current on their laptop."
"ttyv0" -- What UNIX calls a $20K state-of-the-art, 3D, hi-res color terminal

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?12215.912436306>