Proposed modifications to replay cache to prevent false positives

[Nicolas Williams]

On Thu, May 22, 2008 at 02:48:44PM -0400, Ken Raeburn wrote:
> On May 20, 2008, at 18:48, Nicolas Williams wrote:
> >Will profiled the code and found unnecessary gettimeofday() syscalls  
> >in
> >the main loop
> 
> Are we talking about something along the lines of 
> http://isda-maven1.mit.edu:8060/changelog/krb5/?cs=15799 or something on 
>  top of that?

Something like that.  I'll have to compare that to our code, but I can't
today.

> >and function calls in the main loop which when turned to
> >macros greatly reduce overhead.
> 
> I'm inclined to say that an optimizing compiler should just DTRT.   

Sure, but several years ago Sun Studio wasn't doing it.

> Though in our default configuration, the configure script wouldn't  
> normally turn on optimization for Sun's compiler...  (Historically,  
> some compilers have had trouble with using both -g and -O, and so  
> autoconf normally gives you just -g if you're not using gcc.)
> 
> If it's still a problem, we can look at making functions explicitly  
> inline, or converting them to macros.  But we should confirm that it's  
> (still) a problem, first.

OK.

> >>>- provide an option to set the server-side skew to some number of
> >>>seconds, which in general should be estimated time to boot * 2
> >>
> >>[libdefaults]->clockskew is used (and defaults to 300s)
> >
> >Yes, yes.  I'd like that to be somewhat more automatic.  One boolean  
> >in
> >the config, instead of a numeric.
> 
> And the Kerberos library should magically know how long it takes the  
> machine to boot, and use that value?  That's going to vary a lot  
> depending on operating system, cpu, file system configuration, etc.

Yes.  I know.  I said "estimated" because the kernel can only tell you
how long it took to get to multi-user-server runlevel from the point
where it could start keeping time; the kernel can't tell you how long it
took the previous boot phases to complete (POST, BIOS, boot loaders,
...).