Simon Burge wrote:

>On Tue, Oct 25, 2005 at 02:16:37AM +0200, Frank Kardel wrote:
>
>  
>
>>Why ?
>>
>>    
>>
>....
>  
>
>Heh, I've been playing a little with timecounters too in my spare time.
>My laptop is running a timecounter kernel now.  However, using an alpha
>as my main time server means this hasn't been as much a priority for me
>as it appears to be for you :-)
>
>  
>
As for priority: It just breaks your heat seeing the old SOEKRIS graphs 
(www.kardel.name)
when you are used to develop refclock code for NTP.

Good to hear from someone haveing done  a similar port.

>>So much for the examples - the patches for -current as of 
>>20051024-094940(UTC) can be found
>>along with some before and after graphics on:
>>
>>   http://www.kardel.name
>>    
>>
>
>I'll have a better look when I get a chance.  A couple of differences
>are immediately noticable from your README_TIMECOUNTERS to how I've done
>things so far:
>
> - I didn't worry about changing the signatures of
>   {,get}{micro,nano,bin}{,up}time() and adapted our calling functions
>   to suit the new interface.
>  
>
I am still undecided about that. I did it because the was that somewhat 
dynamic
overhead reducing construct in about 4 file system specific file where
mod time stamps are taken. I did have a version of those files that 
didn't return the
input pointer as a result but in that area I went for non-modification 
of that code
for the port. But as I said I am still undecided about that. Having to 
void function
declarations would also be ok.

> - I haven't added support for the __HAVE_TIMERCOUNTER option - I think
>   I was planning on converting all arch's on a branch then merging, but
>   hadn't really thought too far ahead on that one.  On one hand, MD
>   support for timecounters isn't really that hard.
>
Yes, it's actually pretty easy and a clean interface. But you need to 
get it 'right,
right away - thats why I opted for the evolutional approach.

>  On the other, not
>   having to wait for all ports to be converted has its merits.
>  
>
Yepp.

> - I've adapted userland to work (savecore/vmstat).  build.sh completes
>   (only for i386).
>  
>
My build.sh is supposed to complete too. It did it at least in my tree. 
I deemed
the userland utilities a minor issue - I think taking your version would 
be an option.

> - I've moved a lot of time-related prototypes and variable declarations
>   to the new <sys/timevar.h> kernel-only header file.
>  
>
Yes, I noticed that right away yesterday - it put a small bump into my 
way on creating the
patch file... :-) - but it was just a small bump.

>I still have far too many XXX comments to deal with though in my working
>tree.
>
The only place where I have XXX are in the areas of low level code and I 
would like to
spread many around those areas where the wrong time scale is used 
(intervaltimer and alike).

>  I also haven't throught about SMP yet - in particular our
>cc_microtime/cc_microset has had work to be SMP friendly, and we need
>to investigate those changes versus what timekeepers provide.
>  
>
cc_microtime is completely obsolete with time counters. And timecounters
basically give you MP time keeping right away if the semi stable storage 
assumption
holds - which is very likely for many architectures.

>Another thought is the
>
>	Timecounter "i8254" frequency 1193182 Hz quality 0
>
>style messages spread throughout the boot messages doesn't exactly fit
>in with our boot message style.
>  
>
Yepp, I didn't worry too much about it because it's just a few places 
needing adjustment.
Unifying is important, though.

>A positive note is that the size between my old "normal" kernel and new
>timekeeper kernel is negligible:
>
>   text    data     bss     dec     hex filename
>3171771   76220  113360 3361351  334a47 /netbsd
>3171258   77020  113488 3361766  334be6 /nettc
>
>  
>
Good to see - I didn't check that for my kernels yet.

>>Future work (roughly sorted):
>>
>>   - BRANCH: [ ... ]
>>    
>>
>
>I was planning on creating a branch probably next weekend.  I might see
>if I can do that sooner.
>  
>
That would be a good.

>>Please feel free to look at the patch (consider it "newer as current" 
>>8-) and give me
>>feedback about the time counter port.
>>    
>>
>
>Good to have another reference, and one that certainly looks further
>along in some (probably many) areas.
>  
>
Maybe we can compare the two trees and pick the better parts of both.

>Cheers,
>Simon.
>
Cheers
  Frank