On Tue, Feb 13, 2007 at 11:38:33PM +0100, Andrea Arcangeli wrote:
> Hi,
>
> On Tue, Feb 13, 2007 at 11:18:48PM +0100, Vojtech Pavlik wrote:
> > It's not inherent to ntpd's design, but the current (which may have been
> > fixed since I looked last) implementation of the NTP PLL in the kernel.
> >
On Wed, 2007-02-14 at 11:18 +1100, Paul Mackerras wrote:
> Andi Kleen writes:
>
> > Just to avoid spreading misinformation: modulo some new broken hardware
> > (which we always try to work around when found) i386/x86-64 gettimeofday
> > is monotonic. AFAIK on the currently known hardware it
Andi Kleen writes:
> Just to avoid spreading misinformation: modulo some new broken hardware
> (which we always try to work around when found) i386/x86-64 gettimeofday
> is monotonic. AFAIK on the currently known hardware it should be generally
> ok.
>
> However ntpd can always screw you up,
On Tue, 13 Feb 2007, Vojtech Pavlik wrote:
> The interaction with ntpd can be fixed and I've done it in the past
> once, although the fix wasn't all that nice.
It can be and was fixed by gradually moving time instead of jumping to
the new time. F.e. the time interpolator on ia64 gradually
Hi,
On Tue, Feb 13, 2007 at 11:18:48PM +0100, Vojtech Pavlik wrote:
> It's not inherent to ntpd's design, but the current (which may have been
> fixed since I looked last) implementation of the NTP PLL in the kernel.
>
> The interaction with ntpd can be fixed and I've done it in the past
> once,
On Tue, Feb 13, 2007 at 06:20:14PM +0100, Andi Kleen wrote:
> On Tuesday 13 February 2007 18:09, Christoph Lameter wrote:
> > On Tue, 13 Feb 2007, Arjan van de Ven wrote:
> >
> > > no quite the opposite. gettimeofday() currently is NOT monotonic
> > > unfortunately. With this patchseries it
On Tuesday 13 February 2007 18:09, Christoph Lameter wrote:
> On Tue, 13 Feb 2007, Arjan van de Ven wrote:
>
> > no quite the opposite. gettimeofday() currently is NOT monotonic
> > unfortunately. With this patchseries it actually has a better chance of
> > becoming that...
>
> It is monotonic
On Tue, 13 Feb 2007, Arjan van de Ven wrote:
> no quite the opposite. gettimeofday() currently is NOT monotonic
> unfortunately. With this patchseries it actually has a better chance of
> becoming that...
It is monotonic on IA64 at least and we have found that subtle application
bugs occur if
On Tue, 2007-02-13 at 09:28 +0100, Andi Kleen wrote:
> On Tuesday 13 February 2007 07:40, Arjan van de Ven wrote:
> > On Mon, 2007-02-12 at 16:34 -0800, Christoph Lameter wrote:
> > > On Fri, 2 Feb 2007, Andi Kleen wrote:
> > >
> > > > I've threatened to just disable RDTSC for ring 3 before, but
On Tuesday 13 February 2007 07:40, Arjan van de Ven wrote:
> On Mon, 2007-02-12 at 16:34 -0800, Christoph Lameter wrote:
> > On Fri, 2 Feb 2007, Andi Kleen wrote:
> >
> > > I've threatened to just disable RDTSC for ring 3 before, but it'll likely
> > > never happen because too many programs use
On Tuesday 13 February 2007 07:40, Arjan van de Ven wrote:
On Mon, 2007-02-12 at 16:34 -0800, Christoph Lameter wrote:
On Fri, 2 Feb 2007, Andi Kleen wrote:
I've threatened to just disable RDTSC for ring 3 before, but it'll likely
never happen because too many programs use it.
On Tue, 2007-02-13 at 09:28 +0100, Andi Kleen wrote:
On Tuesday 13 February 2007 07:40, Arjan van de Ven wrote:
On Mon, 2007-02-12 at 16:34 -0800, Christoph Lameter wrote:
On Fri, 2 Feb 2007, Andi Kleen wrote:
I've threatened to just disable RDTSC for ring 3 before, but it'll
On Tue, 13 Feb 2007, Arjan van de Ven wrote:
no quite the opposite. gettimeofday() currently is NOT monotonic
unfortunately. With this patchseries it actually has a better chance of
becoming that...
It is monotonic on IA64 at least and we have found that subtle application
bugs occur if it
On Tuesday 13 February 2007 18:09, Christoph Lameter wrote:
On Tue, 13 Feb 2007, Arjan van de Ven wrote:
no quite the opposite. gettimeofday() currently is NOT monotonic
unfortunately. With this patchseries it actually has a better chance of
becoming that...
It is monotonic on IA64 at
On Tue, Feb 13, 2007 at 06:20:14PM +0100, Andi Kleen wrote:
On Tuesday 13 February 2007 18:09, Christoph Lameter wrote:
On Tue, 13 Feb 2007, Arjan van de Ven wrote:
no quite the opposite. gettimeofday() currently is NOT monotonic
unfortunately. With this patchseries it actually has a
Hi,
On Tue, Feb 13, 2007 at 11:18:48PM +0100, Vojtech Pavlik wrote:
It's not inherent to ntpd's design, but the current (which may have been
fixed since I looked last) implementation of the NTP PLL in the kernel.
The interaction with ntpd can be fixed and I've done it in the past
once,
On Tue, 13 Feb 2007, Vojtech Pavlik wrote:
The interaction with ntpd can be fixed and I've done it in the past
once, although the fix wasn't all that nice.
It can be and was fixed by gradually moving time instead of jumping to
the new time. F.e. the time interpolator on ia64 gradually adapts
Andi Kleen writes:
Just to avoid spreading misinformation: modulo some new broken hardware
(which we always try to work around when found) i386/x86-64 gettimeofday
is monotonic. AFAIK on the currently known hardware it should be generally
ok.
However ntpd can always screw you up, but
On Wed, 2007-02-14 at 11:18 +1100, Paul Mackerras wrote:
Andi Kleen writes:
Just to avoid spreading misinformation: modulo some new broken hardware
(which we always try to work around when found) i386/x86-64 gettimeofday
is monotonic. AFAIK on the currently known hardware it should be
On Tue, Feb 13, 2007 at 11:38:33PM +0100, Andrea Arcangeli wrote:
Hi,
On Tue, Feb 13, 2007 at 11:18:48PM +0100, Vojtech Pavlik wrote:
It's not inherent to ntpd's design, but the current (which may have been
fixed since I looked last) implementation of the NTP PLL in the kernel.
The
On Mon, 2007-02-12 at 16:34 -0800, Christoph Lameter wrote:
> On Fri, 2 Feb 2007, Andi Kleen wrote:
>
> > I've threatened to just disable RDTSC for ring 3 before, but it'll likely
> > never happen because too many programs use it.
>
> Those programs are aware that they are fiddling around with
On Fri, 2 Feb 2007, Andi Kleen wrote:
> I've threatened to just disable RDTSC for ring 3 before, but it'll likely
> never happen because too many programs use it.
Those programs are aware that they are fiddling around with low level
material but with this patchset we are going to have a non
On Fri, 2 Feb 2007, Andi Kleen wrote:
I've threatened to just disable RDTSC for ring 3 before, but it'll likely
never happen because too many programs use it.
Those programs are aware that they are fiddling around with low level
material but with this patchset we are going to have a non
On Mon, 2007-02-12 at 16:34 -0800, Christoph Lameter wrote:
On Fri, 2 Feb 2007, Andi Kleen wrote:
I've threatened to just disable RDTSC for ring 3 before, but it'll likely
never happen because too many programs use it.
Those programs are aware that they are fiddling around with low level
[EMAIL PROTECTED] wrote:
TSC is either synchronized by design or not reliable
to be used for anything, let alone timekeeping.
This refers to eliminating the offset between multiple synchronized TSCs.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
[EMAIL PROTECTED] wrote:
TSC is either synchronized by design or not reliable
to be used for anything, let alone timekeeping.
This refers to eliminating the offset between multiple synchronized TSCs.
-hpa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
On Thursday 01 February 2007 14:17, Jiri Bohac wrote:
> On Thu, Feb 01, 2007 at 12:14:23PM +0100, Andi Kleen wrote:
> > On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote:
> > > TSC is either synchronized by design or not reliable
> > > to be used for anything, let alone timekeeping.
> >
On Thursday 01 February 2007 16:16, Vojtech Pavlik wrote:
> It might even make sense to desycnhronize the TSCs on such (AMD)
> machines on purpose, so that applications that rely on TSC break
> immediately and not after some time when the error becomes too large.
They won't because they're
Andi Kleen wrote:
On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote:
TSC is either synchronized by design or not reliable
to be used for anything, let alone timekeeping.
In my tree this is already done better by a patch from Ingo.
Check if they look synchronized and don't use TSC if
On Thu, Feb 01, 2007 at 02:17:15PM +0100, Jiri Bohac wrote:
> On Thu, Feb 01, 2007 at 12:14:23PM +0100, Andi Kleen wrote:
> > On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote:
> > > TSC is either synchronized by design or not reliable
> > > to be used for anything, let alone
On Thu, Feb 01, 2007 at 12:14:23PM +0100, Andi Kleen wrote:
> On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote:
> > TSC is either synchronized by design or not reliable
> > to be used for anything, let alone timekeeping.
>
> In my tree this is already done better by a patch from Ingo.
On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote:
> TSC is either synchronized by design or not reliable
> to be used for anything, let alone timekeeping.
In my tree this is already done better by a patch from Ingo.
Check if they look synchronized and don't use TSC if they are not.
TSC is either synchronized by design or not reliable
to be used for anything, let alone timekeeping.
Signed-off-by: Jiri Bohac <[EMAIL PROTECTED]>
Index: linux-2.6.20-rc5/arch/x86_64/kernel/smpboot.c
===
---
TSC is either synchronized by design or not reliable
to be used for anything, let alone timekeeping.
Signed-off-by: Jiri Bohac [EMAIL PROTECTED]
Index: linux-2.6.20-rc5/arch/x86_64/kernel/smpboot.c
===
---
On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote:
TSC is either synchronized by design or not reliable
to be used for anything, let alone timekeeping.
In my tree this is already done better by a patch from Ingo.
Check if they look synchronized and don't use TSC if they are not.
On Thu, Feb 01, 2007 at 12:14:23PM +0100, Andi Kleen wrote:
On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote:
TSC is either synchronized by design or not reliable
to be used for anything, let alone timekeeping.
In my tree this is already done better by a patch from Ingo.
Check
On Thu, Feb 01, 2007 at 02:17:15PM +0100, Jiri Bohac wrote:
On Thu, Feb 01, 2007 at 12:14:23PM +0100, Andi Kleen wrote:
On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote:
TSC is either synchronized by design or not reliable
to be used for anything, let alone timekeeping.
In
Andi Kleen wrote:
On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote:
TSC is either synchronized by design or not reliable
to be used for anything, let alone timekeeping.
In my tree this is already done better by a patch from Ingo.
Check if they look synchronized and don't use TSC if
On Thursday 01 February 2007 16:16, Vojtech Pavlik wrote:
It might even make sense to desycnhronize the TSCs on such (AMD)
machines on purpose, so that applications that rely on TSC break
immediately and not after some time when the error becomes too large.
They won't because they're normally
On Thursday 01 February 2007 14:17, Jiri Bohac wrote:
On Thu, Feb 01, 2007 at 12:14:23PM +0100, Andi Kleen wrote:
On Thursday 01 February 2007 10:59, [EMAIL PROTECTED] wrote:
TSC is either synchronized by design or not reliable
to be used for anything, let alone timekeeping.
In my
40 matches
Mail list logo
