Subject: Re: CVS commit: src/sys/kern
To: John Hawkinson <jhawk@MIT.EDU>
From: Frank Kardel <email@example.com>
Date: 08/06/2006 15:47:56
oops - reverted faster than I could reply .... (revert ok with me)
But for the sake of other information (significant digits, changing
timecounters) see below:
John Hawkinson wrote:
>Frank and Ben both point out the sysctl:
>Ben Harris <bjh21@NetBSD.org> wrote on Sun, 6 Aug 2006
>at 11:42:27 +0100 in <Pine.LNX.firstname.lastname@example.org>:
>>I was a bit uncertain about this, but if you want all the digits you can
>>always ask sysctl:
>>fastnet:~$ sysctl kern.timecounter.choice
>>kern.timecounter.choice = iomd_timer0(q=100, f=2000000 Hz) clockinterrupt(q=0, f=100 Hz) dummy(q=-1000000, f=1000000 Hz)
>Unfortunately, this does not allow you to perform an after-the-fact
>analysis of changes without advance preparation or additional
>instrumentation. (I don't maintain that this is a likely sort of thing
For the sake of useful numbers we actually should have around 5-6
significant digits as
frequency errors are measure in PPM and ntp will cope with only +-500PPM.
So if humanize number give us much less (haven't checked) we have s
loss of information wrt/ synchronisation effects.
> or that most change timecounters often enough for it to matter
>[or do they?],
Each time a time counter is changes the oscillator parameters are very
likely to change
significantly (-> ntpd needs to figure out the new drift value - that
can take some time).
So it is possible to cause harm to time keeping when frequently changing
> but I am annoyed at the loss of flexibility for no
>apparent material gain.)
>>In a similar way, we approximate disk capacities when printing them at
>>boot time, and assume that anyone who needs the precise number of sectors
>>will use disklabel.
>I don't think this is a fair comparison at all:
>#1 Most users know their disk capacities already.
>#2 Disk capacities don't have the potential to vary
>#3 Disk capacity is a number directly usable by most users, and
> for which the low-order bits are insignificant. Most users
> could care less about clock frequency, and some may find the
> low-order bits of utility.
>Anyhow, regardless, I don't think this deserves
>13 messages to this list. :(
... and I was so happy that we managed most of the transition without
serious bike shedding :-)
>Some other reasons to go back:
>i) Gratuitous difference from FreeBSD
valid for me.
>ii) Cosmetic changes should not hamper flexibility. It's hard to
> predict exactly when you will find a number useful (which is
> why we add so much instrumentation to software!).
5-6 significant digits should be the minimum to preserve information, IMHO.
>iii) I think it sets a bad precedent to go around humanizing
> numbers without a lot of care and thought.