george anzinger wrote:
> 
> > I have only had the opportunity to try this on a single architecture
> > (ia64), so if anyone can convince me that it's a platform-specific
> > problem I'll be happy to take my gripe to the ia64 list.  I've tried to
> > figure out how the usecs are converted to jiffies, but the code is
> > sufficiently convoluted that I thought I'd throw it out in the hope of
> > finding someone who understands the situation a little better.
> 
> I am not sure, but this could be related to the HZ=1024 problem Eric
> Piel and I are trying to run down.  This is a rather bad choice for HZ
> due to round off error on the conversions to usec.  We THINK the
> right thing to do is to convert to nsec (this is for TICK_NSEC()),
> directly rather than first to usec and then to nsec.
With the patch atatched the bug seems to go away, for the 030521 release
of IA64 patch (and probably the previous release also). Could you
confirm, Richard? I think it's kind of architecture specific because
this bug shouldn't happen with HZ=1000 (i386) ;-)
David, would you mind checking this patch does keep profil() working on
your latest release? That's a kind of pre-patch for the problems
encountered recently with the timers and sleeps.

 
> The additional problem is that the ntp code attempts to correct for
> the roundoff error which makes for an always correcting wall clock
> (even without turning on ntp).  What is needed and what I am trying to
> find time to do, is to convert the ntp code to work from the nsec
> resolution of xtime rather from the old usec resolution.  Problem is I
> don't know the ntp code so it is a bit of a learning curve.
George, are you saying you are converting the internal code of ntp to
nsec or only modifying it a little bit to get nsec resolution on the "HZ
rounding error correction"? Anyway, I would be pleased to try your code
on IA64 :-)

> 
> Help here is welcome!!
> 
> As a test, you might try your test with HZ=1000 (a number I recommend
> for ia64, if at all possible).
IMHO if it works with HZ=1000 it's just thanks to some particular case
when HZ is multiple of 10. But the kernel should work with any HZ, I've
no idea why HZ=1024 for most architectures but it shouldn't have to be
changed just to suit some broken code.

Eric