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.4.61.0608061135490.15656@soup.linux.pwf.cam.ac.uk>:
>
>  
>
>>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
>to do,
>
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 
significant
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 
timecounters.

> 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
>	unexpectedly.
>#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.
>  
>
>Thanks.
>
>--jhawk
>  
>
Regards,
  Frank