On Fri, Nov 02, 2018 at 12:25:56PM +0100, Thomas Gleixner wrote:
> On Fri, 2 Nov 2018, Miroslav Lichvar wrote:
> > clocksource -> MONOTONIC_RAW -> MONOTONIC/REALTIME
> >
> > or
> >
> > clocksource -> ? -> MONOTONIC_RAW
> > -> MONOTONIC/REALTIME
>
> That's what we have now. At
On Fri, Nov 02, 2018 at 12:25:56PM +0100, Thomas Gleixner wrote:
> On Fri, 2 Nov 2018, Miroslav Lichvar wrote:
> > clocksource -> MONOTONIC_RAW -> MONOTONIC/REALTIME
> >
> > or
> >
> > clocksource -> ? -> MONOTONIC_RAW
> > -> MONOTONIC/REALTIME
>
> That's what we have now. At
Miroslav,
On Fri, 2 Nov 2018, Miroslav Lichvar wrote:
> On Thu, Nov 01, 2018 at 06:41:00PM +0100, Thomas Gleixner wrote:
> > On Wed, 24 Oct 2018, Miroslav Lichvar wrote:
> > > The error is too large to be corrected by stepping on clock updates.
> > > For a typical TSC frequency we have multiplier
Miroslav,
On Fri, 2 Nov 2018, Miroslav Lichvar wrote:
> On Thu, Nov 01, 2018 at 06:41:00PM +0100, Thomas Gleixner wrote:
> > On Wed, 24 Oct 2018, Miroslav Lichvar wrote:
> > > The error is too large to be corrected by stepping on clock updates.
> > > For a typical TSC frequency we have multiplier
On Fri, 2 Nov 2018, Miroslav Lichvar wrote:
> On Thu, Nov 01, 2018 at 07:03:37PM +0100, Thomas Gleixner wrote:
> > On Thu, 1 Nov 2018, John Stultz wrote:
> > > On Thu, Nov 1, 2018 at 10:44 AM, Thomas Gleixner
> > > wrote:
> > > > On Tue, 23 Oct 2018, John Stultz wrote:
> > > >> However, to be
On Fri, 2 Nov 2018, Miroslav Lichvar wrote:
> On Thu, Nov 01, 2018 at 07:03:37PM +0100, Thomas Gleixner wrote:
> > On Thu, 1 Nov 2018, John Stultz wrote:
> > > On Thu, Nov 1, 2018 at 10:44 AM, Thomas Gleixner
> > > wrote:
> > > > On Tue, 23 Oct 2018, John Stultz wrote:
> > > >> However, to be
On Thu, Nov 01, 2018 at 07:03:37PM +0100, Thomas Gleixner wrote:
> On Thu, 1 Nov 2018, John Stultz wrote:
> > On Thu, Nov 1, 2018 at 10:44 AM, Thomas Gleixner wrote:
> > > On Tue, 23 Oct 2018, John Stultz wrote:
> > >> However, to be correct, the ntp adjustments made would have to be made
> > >>
On Thu, Nov 01, 2018 at 07:03:37PM +0100, Thomas Gleixner wrote:
> On Thu, 1 Nov 2018, John Stultz wrote:
> > On Thu, Nov 1, 2018 at 10:44 AM, Thomas Gleixner wrote:
> > > On Tue, 23 Oct 2018, John Stultz wrote:
> > >> However, to be correct, the ntp adjustments made would have to be made
> > >>
On Thu, Nov 01, 2018 at 06:41:00PM +0100, Thomas Gleixner wrote:
> On Wed, 24 Oct 2018, Miroslav Lichvar wrote:
> > The error is too large to be corrected by stepping on clock updates.
> > For a typical TSC frequency we have multiplier in the range of few
> > millions, so that's a frequency error
On Thu, Nov 01, 2018 at 06:41:00PM +0100, Thomas Gleixner wrote:
> On Wed, 24 Oct 2018, Miroslav Lichvar wrote:
> > The error is too large to be corrected by stepping on clock updates.
> > For a typical TSC frequency we have multiplier in the range of few
> > millions, so that's a frequency error
On Thu, 1 Nov 2018, John Stultz wrote:
> On Thu, Nov 1, 2018 at 10:44 AM, Thomas Gleixner wrote:
> > On Tue, 23 Oct 2018, John Stultz wrote:
> >> On Fri, Oct 19, 2018 at 3:36 PM, John Stultz
> >> wrote:
> >> I spent a little bit of time thinking this out. Unfortunately I don't
> >> think its a
On Thu, 1 Nov 2018, John Stultz wrote:
> On Thu, Nov 1, 2018 at 10:44 AM, Thomas Gleixner wrote:
> > On Tue, 23 Oct 2018, John Stultz wrote:
> >> On Fri, Oct 19, 2018 at 3:36 PM, John Stultz
> >> wrote:
> >> I spent a little bit of time thinking this out. Unfortunately I don't
> >> think its a
On Thu, Nov 1, 2018 at 10:44 AM, Thomas Gleixner wrote:
> On Tue, 23 Oct 2018, John Stultz wrote:
>> On Fri, Oct 19, 2018 at 3:36 PM, John Stultz wrote:
>> I spent a little bit of time thinking this out. Unfortunately I don't
>> think its a simple matter of calculating the granularity error on
On Thu, Nov 1, 2018 at 10:44 AM, Thomas Gleixner wrote:
> On Tue, 23 Oct 2018, John Stultz wrote:
>> On Fri, Oct 19, 2018 at 3:36 PM, John Stultz wrote:
>> I spent a little bit of time thinking this out. Unfortunately I don't
>> think its a simple matter of calculating the granularity error on
On Tue, 23 Oct 2018, John Stultz wrote:
> On Fri, Oct 19, 2018 at 3:36 PM, John Stultz wrote:
> I spent a little bit of time thinking this out. Unfortunately I don't
> think its a simple matter of calculating the granularity error on the
> raw clock and adding it in each interval. The other
On Tue, 23 Oct 2018, John Stultz wrote:
> On Fri, Oct 19, 2018 at 3:36 PM, John Stultz wrote:
> I spent a little bit of time thinking this out. Unfortunately I don't
> think its a simple matter of calculating the granularity error on the
> raw clock and adding it in each interval. The other
Miroslav,
On Wed, 24 Oct 2018, Miroslav Lichvar wrote:
> On Tue, Oct 23, 2018 at 11:31:00AM -0700, John Stultz wrote:
> > On Fri, Oct 19, 2018 at 3:36 PM, John Stultz wrote:
> > > On Fri, Oct 19, 2018 at 1:50 PM, Thomas Gleixner
> > > wrote:
> > >> On Fri, 19 Oct 2018, John Stultz wrote:
> >
Miroslav,
On Wed, 24 Oct 2018, Miroslav Lichvar wrote:
> On Tue, Oct 23, 2018 at 11:31:00AM -0700, John Stultz wrote:
> > On Fri, Oct 19, 2018 at 3:36 PM, John Stultz wrote:
> > > On Fri, Oct 19, 2018 at 1:50 PM, Thomas Gleixner
> > > wrote:
> > >> On Fri, 19 Oct 2018, John Stultz wrote:
> >
On Wed, Oct 24, 2018 at 01:32:48PM -0400, Christopher Hall wrote:
> On Wed, Oct 24, 2018 at 04:51:13PM +0200, Miroslav Lichvar wrote:
> > The error is too large to be corrected by stepping on clock updates.
> > For a typical TSC frequency we have multiplier in the range of few
> > millions, so
On Wed, Oct 24, 2018 at 01:32:48PM -0400, Christopher Hall wrote:
> On Wed, Oct 24, 2018 at 04:51:13PM +0200, Miroslav Lichvar wrote:
> > The error is too large to be corrected by stepping on clock updates.
> > For a typical TSC frequency we have multiplier in the range of few
> > millions, so
On Wed, Oct 24, 2018 at 04:51:13PM +0200, Miroslav Lichvar wrote:
> On Tue, Oct 23, 2018 at 11:31:00AM -0700, John Stultz wrote:
> > On Fri, Oct 19, 2018 at 3:36 PM, John Stultz wrote:
> > > On Fri, Oct 19, 2018 at 1:50 PM, Thomas Gleixner
> > > wrote:
> > >> On Fri, 19 Oct 2018, John Stultz
On Wed, Oct 24, 2018 at 04:51:13PM +0200, Miroslav Lichvar wrote:
> On Tue, Oct 23, 2018 at 11:31:00AM -0700, John Stultz wrote:
> > On Fri, Oct 19, 2018 at 3:36 PM, John Stultz wrote:
> > > On Fri, Oct 19, 2018 at 1:50 PM, Thomas Gleixner
> > > wrote:
> > >> On Fri, 19 Oct 2018, John Stultz
On Tue, Oct 23, 2018 at 11:31:00AM -0700, John Stultz wrote:
> On Fri, Oct 19, 2018 at 3:36 PM, John Stultz wrote:
> > On Fri, Oct 19, 2018 at 1:50 PM, Thomas Gleixner wrote:
> >> On Fri, 19 Oct 2018, John Stultz wrote:
> >>> We might be able to reduce the degree in this case, but I worry the
>
On Tue, Oct 23, 2018 at 11:31:00AM -0700, John Stultz wrote:
> On Fri, Oct 19, 2018 at 3:36 PM, John Stultz wrote:
> > On Fri, Oct 19, 2018 at 1:50 PM, Thomas Gleixner wrote:
> >> On Fri, 19 Oct 2018, John Stultz wrote:
> >>> We might be able to reduce the degree in this case, but I worry the
>
On Fri, Oct 19, 2018 at 3:36 PM, John Stultz wrote:
> On Fri, Oct 19, 2018 at 1:50 PM, Thomas Gleixner wrote:
>> John,
>>
>> On Fri, 19 Oct 2018, John Stultz wrote:
>>> On Fri, Oct 19, 2018 at 11:57 AM, Thomas Gleixner
>>> wrote:
>>> > I don't think you need complex oscillation for that. The
On Fri, Oct 19, 2018 at 3:36 PM, John Stultz wrote:
> On Fri, Oct 19, 2018 at 1:50 PM, Thomas Gleixner wrote:
>> John,
>>
>> On Fri, 19 Oct 2018, John Stultz wrote:
>>> On Fri, Oct 19, 2018 at 11:57 AM, Thomas Gleixner
>>> wrote:
>>> > I don't think you need complex oscillation for that. The
On Fri, Oct 19, 2018 at 1:50 PM, Thomas Gleixner wrote:
> John,
>
> On Fri, 19 Oct 2018, John Stultz wrote:
>> On Fri, Oct 19, 2018 at 11:57 AM, Thomas Gleixner wrote:
>> > I don't think you need complex oscillation for that. The error is constant
>> > and small enough that it is a fractional
On Fri, Oct 19, 2018 at 1:50 PM, Thomas Gleixner wrote:
> John,
>
> On Fri, 19 Oct 2018, John Stultz wrote:
>> On Fri, Oct 19, 2018 at 11:57 AM, Thomas Gleixner wrote:
>> > I don't think you need complex oscillation for that. The error is constant
>> > and small enough that it is a fractional
John,
On Fri, 19 Oct 2018, John Stultz wrote:
> On Fri, Oct 19, 2018 at 11:57 AM, Thomas Gleixner wrote:
> > I don't think you need complex oscillation for that. The error is constant
> > and small enough that it is a fractional nanoseconds thing with an interval
> > <= 1s. So you can just add
John,
On Fri, 19 Oct 2018, John Stultz wrote:
> On Fri, Oct 19, 2018 at 11:57 AM, Thomas Gleixner wrote:
> > I don't think you need complex oscillation for that. The error is constant
> > and small enough that it is a fractional nanoseconds thing with an interval
> > <= 1s. So you can just add
On Fri, Oct 19, 2018 at 11:57 AM, Thomas Gleixner wrote:
> On Fri, 19 Oct 2018, John Stultz wrote:
>> On Fri, Oct 19, 2018 at 11:37 AM, Thomas Gleixner wrote:
>> > On Fri, 19 Oct 2018, Thomas Gleixner wrote:
>> >> On Mon, 15 Oct 2018, Christopher Hall wrote:
>> >> > TSC kHz used to calculate
On Fri, Oct 19, 2018 at 11:57 AM, Thomas Gleixner wrote:
> On Fri, 19 Oct 2018, John Stultz wrote:
>> On Fri, Oct 19, 2018 at 11:37 AM, Thomas Gleixner wrote:
>> > On Fri, 19 Oct 2018, Thomas Gleixner wrote:
>> >> On Mon, 15 Oct 2018, Christopher Hall wrote:
>> >> > TSC kHz used to calculate
On Fri, 19 Oct 2018, John Stultz wrote:
> On Fri, Oct 19, 2018 at 11:37 AM, Thomas Gleixner wrote:
> > On Fri, 19 Oct 2018, Thomas Gleixner wrote:
> >> On Mon, 15 Oct 2018, Christopher Hall wrote:
> >> > TSC kHz used to calculate mult/shift value: 3312000
> >>
> >> Now the most interesting
On Fri, 19 Oct 2018, John Stultz wrote:
> On Fri, Oct 19, 2018 at 11:37 AM, Thomas Gleixner wrote:
> > On Fri, 19 Oct 2018, Thomas Gleixner wrote:
> >> On Mon, 15 Oct 2018, Christopher Hall wrote:
> >> > TSC kHz used to calculate mult/shift value: 3312000
> >>
> >> Now the most interesting
On Fri, Oct 19, 2018 at 11:37 AM, Thomas Gleixner wrote:
> On Fri, 19 Oct 2018, Thomas Gleixner wrote:
>> On Mon, 15 Oct 2018, Christopher Hall wrote:
>> > TSC kHz used to calculate mult/shift value: 3312000
>>
>> Now the most interesting information here would be the resulting mult/shift
>>
On Fri, Oct 19, 2018 at 11:37 AM, Thomas Gleixner wrote:
> On Fri, 19 Oct 2018, Thomas Gleixner wrote:
>> On Mon, 15 Oct 2018, Christopher Hall wrote:
>> > TSC kHz used to calculate mult/shift value: 3312000
>>
>> Now the most interesting information here would be the resulting mult/shift
>>
On Fri, Oct 19, 2018 at 11:34 AM, John Stultz wrote:
> On Fri, Oct 19, 2018 at 8:25 AM, Thomas Gleixner wrote:
>> Christopher,
>>
>> Please Cc LKML on such issues in the future.
>>
>> On Mon, 15 Oct 2018, Christopher Hall wrote:
>>
>> Leaving context around for new readers:
>>
>>> Problem
On Fri, Oct 19, 2018 at 11:34 AM, John Stultz wrote:
> On Fri, Oct 19, 2018 at 8:25 AM, Thomas Gleixner wrote:
>> Christopher,
>>
>> Please Cc LKML on such issues in the future.
>>
>> On Mon, 15 Oct 2018, Christopher Hall wrote:
>>
>> Leaving context around for new readers:
>>
>>> Problem
On Fri, 19 Oct 2018, Thomas Gleixner wrote:
> On Mon, 15 Oct 2018, Christopher Hall wrote:
> > TSC kHz used to calculate mult/shift value: 3312000
>
> Now the most interesting information here would be the resulting mult/shift
> value which the kernel uses. Can you please provide that?
But aside
On Fri, 19 Oct 2018, Thomas Gleixner wrote:
> On Mon, 15 Oct 2018, Christopher Hall wrote:
> > TSC kHz used to calculate mult/shift value: 3312000
>
> Now the most interesting information here would be the resulting mult/shift
> value which the kernel uses. Can you please provide that?
But aside
On Fri, Oct 19, 2018 at 8:25 AM, Thomas Gleixner wrote:
> Christopher,
>
> Please Cc LKML on such issues in the future.
>
> On Mon, 15 Oct 2018, Christopher Hall wrote:
>
> Leaving context around for new readers:
>
>> Problem Statement:
>>
>> The TSC clocksource mult/shift values are derived from
On Fri, Oct 19, 2018 at 8:25 AM, Thomas Gleixner wrote:
> Christopher,
>
> Please Cc LKML on such issues in the future.
>
> On Mon, 15 Oct 2018, Christopher Hall wrote:
>
> Leaving context around for new readers:
>
>> Problem Statement:
>>
>> The TSC clocksource mult/shift values are derived from
Christopher,
Please Cc LKML on such issues in the future.
On Mon, 15 Oct 2018, Christopher Hall wrote:
Leaving context around for new readers:
> Problem Statement:
>
> The TSC clocksource mult/shift values are derived from CPUID[15H], but the
> monotonic raw clock value is not equal to TSC in
Christopher,
Please Cc LKML on such issues in the future.
On Mon, 15 Oct 2018, Christopher Hall wrote:
Leaving context around for new readers:
> Problem Statement:
>
> The TSC clocksource mult/shift values are derived from CPUID[15H], but the
> monotonic raw clock value is not equal to TSC in
44 matches
Mail list logo
