On Thu, 2006-02-16 at 15:10 +0100, Roman Zippel wrote:
> On Wed, 15 Feb 2006, john stultz wrote:
>
> > I just wanted to make sure you know I'm not ignoring your suggestions.
> > I do appreciate the time you have spent, and I have been continuing to
> > work on implementing your idea. Unfortunately the code is not trivial
> > and very much hurts the readability. I expect thats a sacrifice that
> > will be necessary, but hopefully after some review cycles we'll be able
> > to come to something we both like.
>
> The code could be cleaned up a little, but the main difference is that my
> code is much more compact, it lacks all the redundancy of your code, which
> makes it harder to read. My hope was here instead of putting back the
> code redundancy to add documentation instead, which would explain the
> subtleties.
> I actually think that the basic principle of my code is quite simple, the
> problem is that it's a little buried inbetween how the incremental updates
> are done in my prototype, so after a little cleaning and separating the
> special cases, I think my code would be a lot more readable.
I'll admit I'm slow, but since it has taken me a number of weeks to sort
out exactly the details of what is being done in your implementation,
and I *still* have bugs after re-implementing it, I'd not claim your
code is simple. The potential to be very precise and efficient: yes, but
not so trivial to follow.
(This is why I cringe at the idea of trying to implement it for each
clock like you're prototype suggested.)
Maybe when I send out the patch you can suggest improvements to the
comments or other ways to better clarify the code as you suggested
above.
> > I'm hoping to have a first pass patch I can mail this week.
>
> I'm looking forward to it.
> BTW What do you think how difficult it would be to rebase your patches on
> my NTP4 patches?
I'd be very much open to it, although I haven't seen any further updates
to the code since I mailed you some feedback on them. Have you had a
chance to follow up on those?
> In the end the simplification of my patches should also
> make your patches simpler, as it precalculates as much as possible and
> reduces the work done in the fast paths. It would avoid a lot of extra
> work, which you currently do.
Well, I'm still cautious, since it still has some dependencies on HZ
(see equation below), which I'm trying to avoid. However I don't think
your patches keep me from getting the info I need (or atleast, the info
I think I need ;). They do seem to help close the gap between what I
want and what you want, so I think they are a good step forward.
> The main problem that I see is that you need to drop the ppm calculations,
> the new code provides a scaled nsec value per tick (tick_nsec + time_adj)
> and you basically only need "(update - 10^9/HZ) / cycles" to calculate the
> new multiplier adjustment.
My test patch does this already, although for now it calculates the ntp
interval (something like "tick_nsec + time_adj" in your code) from the
ppm value. That calculation would hopefully be replaced w/ some
ntp_get_interval() call that would pull the equivalent from your code.
> You also need to drop your ntp rework, the changes to the generic code
> should be quite simple now, basically just exporting second_overflow()
> and creating an alternative do_timer() entry point which doesn't call
> update_wall_time().
>
> Besides some small cleanups I think my code is ready for some serious
> testing, but it conflicts with your NTP changes.
If you think they're ready, mail them to the list and I'll look them
over then take a swing at re-basing my work on top of them.
thanks
-john
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
