On Fri, May 12, 2017 at 10:26:12AM -0700, John Stultz wrote:
> On Fri, May 12, 2017 at 8:14 AM, Miroslav Lichvar wrote:
> > I see this with real PHCs and PTP/NTP synchronization too. It's very
> > confusing when the timekeeping changes so much for no apparent reason.
> > If
On Fri, May 12, 2017 at 10:26:12AM -0700, John Stultz wrote:
> On Fri, May 12, 2017 at 8:14 AM, Miroslav Lichvar wrote:
> > I see this with real PHCs and PTP/NTP synchronization too. It's very
> > confusing when the timekeeping changes so much for no apparent reason.
> > If we can't remove the
On Fri, May 12, 2017 at 8:14 AM, Miroslav Lichvar wrote:
> On Tue, Jul 15, 2014 at 09:02:38PM -0700, John Stultz wrote:
>> On 07/08/2014 04:08 AM, Miroslav Lichvar wrote:
>> > I spent some time trying to figure out a workaround for the nanosecond
>> > rounding, but I didn't
On Fri, May 12, 2017 at 8:14 AM, Miroslav Lichvar wrote:
> On Tue, Jul 15, 2014 at 09:02:38PM -0700, John Stultz wrote:
>> On 07/08/2014 04:08 AM, Miroslav Lichvar wrote:
>> > I spent some time trying to figure out a workaround for the nanosecond
>> > rounding, but I didn't find anything that
On Tue, Jul 15, 2014 at 09:02:38PM -0700, John Stultz wrote:
> On 07/08/2014 04:08 AM, Miroslav Lichvar wrote:
> > I spent some time trying to figure out a workaround for the nanosecond
> > rounding, but I didn't find anything that wouldn't complicate the mult
> > adjustment logic and bring back
On Tue, Jul 15, 2014 at 09:02:38PM -0700, John Stultz wrote:
> On 07/08/2014 04:08 AM, Miroslav Lichvar wrote:
> > I spent some time trying to figure out a workaround for the nanosecond
> > rounding, but I didn't find anything that wouldn't complicate the mult
> > adjustment logic and bring back
On Tue, Jul 15, 2014 at 09:02:38PM -0700, John Stultz wrote:
> On 07/08/2014 04:08 AM, Miroslav Lichvar wrote:
> > It seems it may be a while before the old vsyscalls are fixed. How
> > about including only the first two patches from this set for now?
>
> Hey! Sorry for the slow response here, I
On Tue, 15 Jul 2014, John Stultz wrote:
> On 07/08/2014 04:08 AM, Miroslav Lichvar wrote:
> > On Mon, May 19, 2014 at 10:57:29AM -0700, John Stultz wrote:
> >> Another area we have to be careful with is there are still
> >> architectures (powerpc and ia64) which haven't switched from the old
> >>
On Tue, 15 Jul 2014, John Stultz wrote:
On 07/08/2014 04:08 AM, Miroslav Lichvar wrote:
On Mon, May 19, 2014 at 10:57:29AM -0700, John Stultz wrote:
Another area we have to be careful with is there are still
architectures (powerpc and ia64) which haven't switched from the old
vsyscall
On Tue, Jul 15, 2014 at 09:02:38PM -0700, John Stultz wrote:
On 07/08/2014 04:08 AM, Miroslav Lichvar wrote:
It seems it may be a while before the old vsyscalls are fixed. How
about including only the first two patches from this set for now?
Hey! Sorry for the slow response here, I was on
On 07/08/2014 04:08 AM, Miroslav Lichvar wrote:
> On Mon, May 19, 2014 at 10:57:29AM -0700, John Stultz wrote:
>> Another area we have to be careful with is there are still
>> architectures (powerpc and ia64) which haven't switched from the old
>> vsyscall rounding logic
On 07/08/2014 04:08 AM, Miroslav Lichvar wrote:
On Mon, May 19, 2014 at 10:57:29AM -0700, John Stultz wrote:
Another area we have to be careful with is there are still
architectures (powerpc and ia64) which haven't switched from the old
vsyscall rounding logic
On Mon, May 19, 2014 at 10:57:29AM -0700, John Stultz wrote:
> Another area we have to be careful with is there are still
> architectures (powerpc and ia64) which haven't switched from the old
> vsyscall rounding logic (CONFIG_GENERIC_TIME_VSYSCALL_OLD). In these
> cases we add up to 1ns of error
On Mon, May 19, 2014 at 10:57:29AM -0700, John Stultz wrote:
Another area we have to be careful with is there are still
architectures (powerpc and ia64) which haven't switched from the old
vsyscall rounding logic (CONFIG_GENERIC_TIME_VSYSCALL_OLD). In these
cases we add up to 1ns of error each
On Mon, May 19, 2014 at 10:57:29AM -0700, John Stultz wrote:
> On Mon, May 19, 2014 at 3:14 AM, Miroslav Lichvar wrote:
> > Ok, so it seems to be almost identical to my patch now. The only two
> > differences seem to be the removal of the ntp_error correction to
> > change the effective clock
On Mon, May 19, 2014 at 10:57:29AM -0700, John Stultz wrote:
On Mon, May 19, 2014 at 3:14 AM, Miroslav Lichvar mlich...@redhat.com wrote:
Ok, so it seems to be almost identical to my patch now. The only two
differences seem to be the removal of the ntp_error correction to
change the
On Mon, May 19, 2014 at 3:14 AM, Miroslav Lichvar wrote:
> On Fri, May 16, 2014 at 05:56:41PM -0700, John Stultz wrote:
>> This version of the patch set corrects a few issues Miroslav pointed
>> out, as well as adapts his approach almost completely for the last
>> patch. This pulls the results in
On Fri, May 16, 2014 at 05:56:41PM -0700, John Stultz wrote:
> This version of the patch set corrects a few issues Miroslav pointed
> out, as well as adapts his approach almost completely for the last
> patch. This pulls the results in to be very close to his original
> patch.
Ok, so it seems to
On Fri, May 16, 2014 at 05:56:41PM -0700, John Stultz wrote:
This version of the patch set corrects a few issues Miroslav pointed
out, as well as adapts his approach almost completely for the last
patch. This pulls the results in to be very close to his original
patch.
Ok, so it seems to be
On Mon, May 19, 2014 at 3:14 AM, Miroslav Lichvar mlich...@redhat.com wrote:
On Fri, May 16, 2014 at 05:56:41PM -0700, John Stultz wrote:
This version of the patch set corrects a few issues Miroslav pointed
out, as well as adapts his approach almost completely for the last
patch. This pulls
I managed to find some time to further work on the next iteration here.
This patch set, based on ideas from Miroslav, tries to improve the ntp
freq steering when using NOHZ.
Rather then just doing error proportional correction, this patchset
splits the logic to two steps: frequency correction
I managed to find some time to further work on the next iteration here.
This patch set, based on ideas from Miroslav, tries to improve the ntp
freq steering when using NOHZ.
Rather then just doing error proportional correction, this patchset
splits the logic to two steps: frequency correction
22 matches
Mail list logo