Re: CVS commit: src/sys/kern

[Frank Kardel <kardel%netbsd.org@localhost>]

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@localhost> wrote on Sun,  6 Aug 2006
> at 11:42:27 +0100 in 
> <Pine.LNX.4.61.0608061135490.15656%soup.linux.pwf.cam.ac.uk@localhost>:
>
>  
>
> > 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