Date: Mon, 30 Nov 1998 06:10:29 -0800 From: Mike Smith <mike@smith.net.au> To: Poul-Henning Kamp <phk@critter.freebsd.dk> Cc: Mike Smith <mike@smith.net.au>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_clock.c Message-ID: <199811301410.GAA03905@dingo.cdrom.com> In-Reply-To: Your message of "Mon, 30 Nov 1998 14:51:59 %2B0100." <12028.912433919@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.
> >> Setting the alternate method (sysctl -w kern.timecounter.method=1)
> >> makes the the get{nano|micro}*() functions call the real thing at
> >> resulting in a measurable but minor overhead.
> >
> >This smells like a botch, not a fix.
>
> No, it isn't. get{nano|micro}* are supposed to be precise to within
> a tick, for things where better precision is pointless and where
> speed is important. After I changed the method to the one which is
> now known as "1", it became imprecise to within one second, and that
> broke various stuff.
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.
I hope I'm misreading you here; 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.
> >> I decided to NOT have the "calcru" change the method automatically
> >> because you should be aware of this problem if you have it.
> >
> >Bad. There is now no correspondence between the diagnostic and the
> >fix, and the user has to vector through a small number of people in
> >order to resolve their problems.
>
> I submitted a FAQ entry.
Try putting the sysctl name in the error message. Or just have the
error fix it.
--
\\ Sometimes you're ahead, \\ Mike Smith
\\ sometimes you're behind. \\ mike@smith.net.au
\\ The race is long, and in the \\ msmith@freebsd.org
\\ end it's only with yourself. \\ msmith@cdrom.com
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?199811301410.GAA03905>