Hi,
On Thu, 21 Feb 2008, john stultz wrote:
> > Again, what kind of crappy hardware do you expect? Aren't clocks supposed
> > to get better and not worse?
>
> Well, while I've seen much worse, I consider crappy hardware to be 100
> +ppm error. So if the hardware is perfect and the system
Hi,
On Thu, 21 Feb 2008, john stultz wrote:
Again, what kind of crappy hardware do you expect? Aren't clocks supposed
to get better and not worse?
Well, while I've seen much worse, I consider crappy hardware to be 100
+ppm error. So if the hardware is perfect and the system results in
On Wed, 2008-02-20 at 18:08 +0100, Roman Zippel wrote:
> > Well, it is a problem if its large. The 500ppm limit is supposed to be
> > for hardware frequency error correction, not hardware frequency +
> > software error correction. Now, if it were 1-10ppm, it wouldn't be that
> > big of an issue,
On Wed, 2008-02-20 at 18:08 +0100, Roman Zippel wrote:
Well, it is a problem if its large. The 500ppm limit is supposed to be
for hardware frequency error correction, not hardware frequency +
software error correction. Now, if it were 1-10ppm, it wouldn't be that
big of an issue, but with
Hi,
On Tue, 19 Feb 2008, john stultz wrote:
> To better keep with your analogy, you'd have to imagine a scale that
> only reads in X pound increments. As long as X is fairly small, it
> should measure everyone's weight fairly well. However, if X is large,
> like say 50kg, then it won't weigh a
Hi,
On Tue, 19 Feb 2008, john stultz wrote:
To better keep with your analogy, you'd have to imagine a scale that
only reads in X pound increments. As long as X is fairly small, it
should measure everyone's weight fairly well. However, if X is large,
like say 50kg, then it won't weigh a 70kg
On Tue, 2008-02-19 at 05:04 +0100, Roman Zippel wrote:
> Hi,
>
> On Mon, 18 Feb 2008, john stultz wrote:
>
> > If we are building a train station, and each train car is 60ft, it
> > doesn't make much sense to build 1000ft stations, right? Instead you'll
> > do better if you build a 1020ft
On Tue, 2008-02-19 at 05:04 +0100, Roman Zippel wrote:
Hi,
On Mon, 18 Feb 2008, john stultz wrote:
If we are building a train station, and each train car is 60ft, it
doesn't make much sense to build 1000ft stations, right? Instead you'll
do better if you build a 1020ft station.
Hi,
On Mon, 18 Feb 2008, john stultz wrote:
> If we are building a train station, and each train car is 60ft, it
> doesn't make much sense to build 1000ft stations, right? Instead you'll
> do better if you build a 1020ft station.
That would assume trains are always 60ft long, which is the basic
On Sat, 2008-02-16 at 05:24 +0100, Roman Zippel wrote:
> Hi,
>
> On Wed, 13 Feb 2008, john stultz wrote:
>
> > Oh! So your issue is that since time_freq is stored in ppm, or in effect
> > a usecs per sec offset, when we add it to something other then 1 second
> > we mis-apply what NTP tells us
On Sat, 2008-02-16 at 05:24 +0100, Roman Zippel wrote:
Hi,
On Wed, 13 Feb 2008, john stultz wrote:
Oh! So your issue is that since time_freq is stored in ppm, or in effect
a usecs per sec offset, when we add it to something other then 1 second
we mis-apply what NTP tells us to. Is
Hi,
On Mon, 18 Feb 2008, john stultz wrote:
If we are building a train station, and each train car is 60ft, it
doesn't make much sense to build 1000ft stations, right? Instead you'll
do better if you build a 1020ft station.
That would assume trains are always 60ft long, which is the basic
Hi,
On Wed, 13 Feb 2008, john stultz wrote:
> Oh! So your issue is that since time_freq is stored in ppm, or in effect
> a usecs per sec offset, when we add it to something other then 1 second
> we mis-apply what NTP tells us to. Is that right?
Pretty much everything is centered around that
Hi,
On Wed, 13 Feb 2008, john stultz wrote:
Oh! So your issue is that since time_freq is stored in ppm, or in effect
a usecs per sec offset, when we add it to something other then 1 second
we mis-apply what NTP tells us to. Is that right?
Pretty much everything is centered around that 1sec,
On Tue, 2008-02-12 at 15:36 +0100, Roman Zippel wrote:
> On Mon, 11 Feb 2008, john stultz wrote:
> > This fine grained error accounting is where the bug I'm trying to
> > address is cropping up from. In order to have the comparison we need to
> > have two values:
> > A: The clocksource's notion
On Tue, 2008-02-12 at 15:36 +0100, Roman Zippel wrote:
On Mon, 11 Feb 2008, john stultz wrote:
This fine grained error accounting is where the bug I'm trying to
address is cropping up from. In order to have the comparison we need to
have two values:
A: The clocksource's notion of how
Hi,
On Mon, 11 Feb 2008, john stultz wrote:
> > I don't want to just send a patch, I want you to understand why your
> > approach is wrong.
>
> With all due respect, it also keeps the critique in one direction and
> makes your review less collaborative and more confrontational then I
> suspect
Hi,
On Mon, 11 Feb 2008, john stultz wrote:
I don't want to just send a patch, I want you to understand why your
approach is wrong.
With all due respect, it also keeps the critique in one direction and
makes your review less collaborative and more confrontational then I
suspect (or
On Sun, 2008-02-10 at 19:45 +0100, Roman Zippel wrote:
> Hi,
>
> On Fri, 8 Feb 2008, john stultz wrote:
>
> > -ENOPATCH
> >
> > We're taking weeks to critique fairly small bug fix. I'm sure we both
> > have better things to do then continue to misunderstand each other. I'll
> > do the testing
On Sun, 2008-02-10 at 19:45 +0100, Roman Zippel wrote:
Hi,
On Fri, 8 Feb 2008, john stultz wrote:
-ENOPATCH
We're taking weeks to critique fairly small bug fix. I'm sure we both
have better things to do then continue to misunderstand each other. I'll
do the testing and will
Hi,
On Fri, 8 Feb 2008, john stultz wrote:
> -ENOPATCH
>
> We're taking weeks to critique fairly small bug fix. I'm sure we both
> have better things to do then continue to misunderstand each other. I'll
> do the testing and will happily ack it if it resolves the issue.
I don't want to just
Hi,
On Fri, 8 Feb 2008, john stultz wrote:
-ENOPATCH
We're taking weeks to critique fairly small bug fix. I'm sure we both
have better things to do then continue to misunderstand each other. I'll
do the testing and will happily ack it if it resolves the issue.
I don't want to just send a
Hi,
On Fri, 8 Feb 2008, Andrew Morton wrote:
> > Only now I noticed that the first patch had been merged without any
> > further question. :-(
> > What point is there in reviewing patches, if everything is merged anyway.
> > :-(
> >
>
> oops, mistake, sorry. There's plenty of time to fix it
Hi,
On Fri, 8 Feb 2008, Andrew Morton wrote:
Only now I noticed that the first patch had been merged without any
further question. :-(
What point is there in reviewing patches, if everything is merged anyway.
:-(
oops, mistake, sorry. There's plenty of time to fix it though.
It
On Sat, 9 Feb 2008 05:47:18 +0100 (CET) Roman Zippel <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Fri, 8 Feb 2008, john stultz wrote:
>
> >
> > clock = clocksource_get_next();
> > - clocksource_calculate_interval(clock,
> > - (unsigned
Hi,
On Fri, 8 Feb 2008, john stultz wrote:
>
> clock = clocksource_get_next();
> - clocksource_calculate_interval(clock,
> - (unsigned long)(current_tick_length()>>TICK_LENGTH_SHIFT));
> + clocksource_calculate_interval(clock, NTP_INTERVAL_LENGTH);
>
On Fri, 2008-02-08 at 18:33 +0100, Roman Zippel wrote:
> Hi,
>
> On Fri, 1 Feb 2008, John Stultz wrote:
>
> > > CLOCK_TICK_ADJUST is based on LATCH and HZ, if the update frequency isn't
> > > based on HZ, there is no point in using it!
> >
> > Hey Roman,
> >
> > Again, I'm sorry I don't seem
Hi,
On Fri, 1 Feb 2008, John Stultz wrote:
> > CLOCK_TICK_ADJUST is based on LATCH and HZ, if the update frequency isn't
> > based on HZ, there is no point in using it!
>
> Hey Roman,
>
> Again, I'm sorry I don't seem to be following your objections. If you
> want to suggest a different patch
On Fri, 2008-02-08 at 18:33 +0100, Roman Zippel wrote:
Hi,
On Fri, 1 Feb 2008, John Stultz wrote:
CLOCK_TICK_ADJUST is based on LATCH and HZ, if the update frequency isn't
based on HZ, there is no point in using it!
Hey Roman,
Again, I'm sorry I don't seem to be following
Hi,
On Fri, 8 Feb 2008, john stultz wrote:
clock = clocksource_get_next();
- clocksource_calculate_interval(clock,
- (unsigned long)(current_tick_length()TICK_LENGTH_SHIFT));
+ clocksource_calculate_interval(clock, NTP_INTERVAL_LENGTH);
clock-cycle_last =
On Sat, 9 Feb 2008 05:47:18 +0100 (CET) Roman Zippel [EMAIL PROTECTED] wrote:
Hi,
On Fri, 8 Feb 2008, john stultz wrote:
clock = clocksource_get_next();
- clocksource_calculate_interval(clock,
- (unsigned long)(current_tick_length()TICK_LENGTH_SHIFT));
+
Hi,
On Fri, 1 Feb 2008, John Stultz wrote:
CLOCK_TICK_ADJUST is based on LATCH and HZ, if the update frequency isn't
based on HZ, there is no point in using it!
Hey Roman,
Again, I'm sorry I don't seem to be following your objections. If you
want to suggest a different patch to fix
On Thu, 2008-01-31 at 06:02 +0100, Roman Zippel wrote:
> Hi,
>
> On Wed, 30 Jan 2008, john stultz wrote:
>
> > My concern is we state the accumulation interval is X ns long. Then
> > current_tick_length() is to return (X + ntp_adjustment), so each
> > accumulation interval we can keep track of
On Thu, 2008-01-31 at 06:02 +0100, Roman Zippel wrote:
Hi,
On Wed, 30 Jan 2008, john stultz wrote:
My concern is we state the accumulation interval is X ns long. Then
current_tick_length() is to return (X + ntp_adjustment), so each
accumulation interval we can keep track of the error
Hi,
On Wed, 30 Jan 2008, john stultz wrote:
> My concern is we state the accumulation interval is X ns long. Then
> current_tick_length() is to return (X + ntp_adjustment), so each
> accumulation interval we can keep track of the error and adjust our
> interval length.
>
> So if
On Thu, 2008-01-31 at 02:55 +0100, Roman Zippel wrote:
> Hi,
>
> On Tue, 29 Jan 2008, john stultz wrote:
>
> > +/* Because using NSEC_PER_SEC would be too easy */
> > +#define NTP_INTERVAL_LENGTH
> > s64)TICK_USEC*NSEC_PER_USEC*USER_HZ)+CLOCK_TICK_ADJUST)/NTP_INTERVAL_FREQ)
>
> Why are
Hi,
On Tue, 29 Jan 2008, john stultz wrote:
> +/* Because using NSEC_PER_SEC would be too easy */
> +#define NTP_INTERVAL_LENGTH
> s64)TICK_USEC*NSEC_PER_USEC*USER_HZ)+CLOCK_TICK_ADJUST)/NTP_INTERVAL_FREQ)
Why are you using USER_HZ? Did you test this with HZ!=100?
Anyway, please don't make
Hi,
On Tue, 29 Jan 2008, john stultz wrote:
+/* Because using NSEC_PER_SEC would be too easy */
+#define NTP_INTERVAL_LENGTH
s64)TICK_USEC*NSEC_PER_USEC*USER_HZ)+CLOCK_TICK_ADJUST)/NTP_INTERVAL_FREQ)
Why are you using USER_HZ? Did you test this with HZ!=100?
Anyway, please don't make
On Thu, 2008-01-31 at 02:55 +0100, Roman Zippel wrote:
Hi,
On Tue, 29 Jan 2008, john stultz wrote:
+/* Because using NSEC_PER_SEC would be too easy */
+#define NTP_INTERVAL_LENGTH
s64)TICK_USEC*NSEC_PER_USEC*USER_HZ)+CLOCK_TICK_ADJUST)/NTP_INTERVAL_FREQ)
Why are you using
Hi,
On Wed, 30 Jan 2008, john stultz wrote:
My concern is we state the accumulation interval is X ns long. Then
current_tick_length() is to return (X + ntp_adjustment), so each
accumulation interval we can keep track of the error and adjust our
interval length.
So if
On Tue, 2008-01-29 at 05:02 +0100, Roman Zippel wrote:
> Hi,
>
> On Mon, 28 Jan 2008, john stultz wrote:
>
> > Regardless, current_tick_length() really is the base interval we're
> > using in the error accumulation loop, so it seems the cleanest interface
> > to use (just to avoid redundancy at
On Tue, 2008-01-29 at 05:02 +0100, Roman Zippel wrote:
Hi,
On Mon, 28 Jan 2008, john stultz wrote:
Regardless, current_tick_length() really is the base interval we're
using in the error accumulation loop, so it seems the cleanest interface
to use (just to avoid redundancy at least)
Hi,
On Mon, 28 Jan 2008, john stultz wrote:
> Regardless, current_tick_length() really is the base interval we're
> using in the error accumulation loop, so it seems the cleanest interface
> to use (just to avoid redundancy at least) when establishing the
> clocksource's interval length. Or do
On Fri, 2008-01-25 at 15:07 +0100, Roman Zippel wrote:
> Hi,
>
> On Wed, 23 Jan 2008, john stultz wrote:
>
> > This difference in calculation was causing the clocksource correction
> > code to apply a correction factor to the clocksource so the two
> > intervals were the same, however this
On Fri, 2008-01-25 at 15:07 +0100, Roman Zippel wrote:
Hi,
On Wed, 23 Jan 2008, john stultz wrote:
This difference in calculation was causing the clocksource correction
code to apply a correction factor to the clocksource so the two
intervals were the same, however this results in the
Hi,
On Mon, 28 Jan 2008, john stultz wrote:
Regardless, current_tick_length() really is the base interval we're
using in the error accumulation loop, so it seems the cleanest interface
to use (just to avoid redundancy at least) when establishing the
clocksource's interval length. Or do you
Hi,
On Wed, 23 Jan 2008, john stultz wrote:
> This difference in calculation was causing the clocksource correction
> code to apply a correction factor to the clocksource so the two
> intervals were the same, however this results in the actual frequency of
> the clocksource to be made incorrect.
Hi,
On Wed, 23 Jan 2008, john stultz wrote:
This difference in calculation was causing the clocksource correction
code to apply a correction factor to the clocksource so the two
intervals were the same, however this results in the actual frequency of
the clocksource to be made incorrect. I
On Wed, 23 Jan 2008 18:38:53 PST, john stultz said:
> I recently noticed on one of my boxes that when synched with an NTP
> server, the drift value reported for the system was ~283ppm. While in
> some cases, clock hardware can be that bad, it struck me as unusual as
> the system was using the
On Wed, 23 Jan 2008 18:38:53 PST, john stultz said:
I recently noticed on one of my boxes that when synched with an NTP
server, the drift value reported for the system was ~283ppm. While in
some cases, clock hardware can be that bad, it struck me as unusual as
the system was using the acpi_pm
50 matches
Mail list logo
