Hi,
On Thu, 13 Jul 2006, Thomas Gleixner wrote:
> > > > The timer interrupt itself is not a synchronization point.
> > >
> > > If the timer interrupt is not a synchronization point, what is?
>
> I used the term synchronization point for the points on the timeline,
> where the information of an external time reference is available, e.g.
> NTP data, a PPS interrupt ....
This would be even less usable, there is no requirement that NTP is used
for time synchronization and the kernel has no idea when then the next
NTP adjustment happens.
> At those points we calculate the deviation from the external time
> reference and refine the conversion and adjustment factors. In the
> simplest form this boils down to a linear equation where we interpolate
> between the points which are defined by the external time reference.
This is true for the clock source, but the adjustments that come in via
NTP are not exactly linear, so unless you want to rewrite the whole NTP
system, I don't think this will work.
> > I think this would give a bit of independence between the clocksource
> > adjustment code and the interrupt frequency (and likely improve
> > robustness as well).
>
> John, that's exactly the central point. In an environment where we have
> non periodic interrupts (high resolution timers, dynamic ticks) this
> adjustment mechanism which relies on the periodic precise event to do
> the accumulation does not work any more. I do not like the idea of
> modifying this in a way that the timekeeping code does this fine grained
> adjustment on the non periodic timer events. This will be a nightmare of
> math and decrease robustness a lot.
>
> The whole concept of doing the fine grained adjustment in order to
> compensate for the inaccuracy of the scaled math factors on a _periodic_
> event is flawed by design. The latency of interrupts in the kernel and
> the fact that the periodic interrupt might be driven by a different
> hardware clock, which has a different drift behaviour than the clock
> which drives the time source, are reason enough to think about a
> solution which makes this interdependency go away completely. In a high
> resolution timer / dyntick system and also on virtualized environments
> we need to get this dependency removed anyway.
>
> The adjustment code is simply interpolation between points and boils
> down to linear equations. Due to the fact that the conversion factor is
> not accurate enough we need some mechanism to compensate this. I accept
> that the current design has its charm, but I'm quite sure that we can do
> a equally precise calculation without the interaction with the timer
> interrupt code.
>
> I know you prefer shopping over math, but it is a solvable problem.
Thomas, do you have any idea how insulting this is?
First of all you are pretty much wrong with your analysis. It does not
rely on "periodic precise event", it helps if they are precise, but it's
not a requirement and it's practically a one line change so it can deal
with nonperiodic updates (the rest is just a matter of correct tuning).
The "fine grained adjustment" doesn't "compensate for the inaccuracy of
the scaled math" at all, one has to know here that we only have to be
accurate within limits (usually the resolution of the clock), so that the
inaccuracy is not really a problem and it has the advantage that is
generally cheap. What the adjustments actually compensate for is the
difference in resolution and the update delays.
Since your initial analysis is pretty much wrong, your conclusions are
pretty much useless as well. So far so bad, by itself this wouldn't be
really a problem yet, everyone makes mistakes. If you would at least ask
some questions about whatever problem you'd like to see solved or if you
would make some constructive suggestion how to solve these problems, this
would have shown respect and could have been a nice discussion. Instead
you just piss on my work by asking John to throw away everything I did and
to "solve" it somehow.
Did you even consider for a second that I might have already thought about
these problems? Did it enter your mind that the hard problems might
already be pretty much solved? Since you don't ask me at all, you don't
really seem to care about what I think. Instead of playing Mr.
know-it-all, I would really appreciate it if you showed some more respect
for my work.
bye, Roman
-
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]
