Proposed modifications to replay cache to prevent false positives
Nicolas.Williams at sun.com
Thu May 22 15:31:43 EDT 2008
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
> >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
> >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.
> >>>- 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
> >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,
More information about the krbdev