On 04/12/2020 11:57:08-0400, Jason Gunthorpe wrote:
> On Fri, Dec 04, 2020 at 04:08:57PM +0100, Alexandre Belloni wrote:
>
> > > I mean literatally time the excution of something like a straight
> > > read. This will give some estimate of the bus latency and it should
> > > linearly relate to the
On Fri, Dec 04, 2020 at 04:08:57PM +0100, Alexandre Belloni wrote:
> > I mean literatally time the excution of something like a straight
> > read. This will give some estimate of the bus latency and it should
> > linearly relate to the bus latency for a write.
>
>
> It doesn't, some rtc will req
On 04/12/2020 10:46:59-0400, Jason Gunthorpe wrote:
> > If you want to read an RTC accurately, you don't want to time a read,
> > what you want is to time an alarm. This is a common misconception and
> > is, again, why hctosys in its current state is not useful.
>
> I mean literatally time the exc
On Fri, Dec 04, 2020 at 03:37:35PM +0100, Alexandre Belloni wrote:
> On 04/12/2020 10:08:19-0400, Jason Gunthorpe wrote:
> > On Fri, Dec 04, 2020 at 02:02:57PM +0100, Thomas Gleixner wrote:
> >
> > > No magic sign calculation required if you look at it from the actual
> > > timeline and account th
On 04/12/2020 10:08:19-0400, Jason Gunthorpe wrote:
> On Fri, Dec 04, 2020 at 02:02:57PM +0100, Thomas Gleixner wrote:
>
> > No magic sign calculation required if you look at it from the actual
> > timeline and account the time between write and next second increment
> > correctly.
>
> Yes, it is
On Fri, Dec 04, 2020 at 02:02:57PM +0100, Thomas Gleixner wrote:
> No magic sign calculation required if you look at it from the actual
> timeline and account the time between write and next second increment
> correctly.
Yes, it is equivalent to break things into two values, and does look
to be m
On Thu, Dec 03 2020 at 18:36, Jason Gunthorpe wrote:
> On Thu, Dec 03, 2020 at 10:31:02PM +0100, Thomas Gleixner wrote:
>> On Thu, Dec 03 2020 at 22:05, Thomas Gleixner wrote:
>> > On Thu, Dec 03 2020 at 12:16, Jason Gunthorpe wrote:
>> > So now we have two options to fix this:
>> >
>> >1) Use
On Fri, Dec 04 2020 at 10:51, Alexandre Belloni wrote:
> On 04/12/2020 10:34:13+0100, Thomas Gleixner wrote:
>> So either the RTC knows the requirements for tsched, e.g. the MC14xxx
>> datasheet, or it can retrieve that information from DT or by querying
>> the underlying bus mechanics for the xfer
On 04/12/2020 10:34:13+0100, Thomas Gleixner wrote:
> On Thu, Dec 03 2020 at 23:00, Alexandre Belloni wrote:
> > On 03/12/2020 22:05:09+0100, Thomas Gleixner wrote:
> >> 2) I2C/SPI ...
> >>
> >>tsched t0 t1 t2
> >> transfer(newsec) RTC update (ne
On Thu, Dec 03 2020 at 23:00, Alexandre Belloni wrote:
> On 03/12/2020 22:05:09+0100, Thomas Gleixner wrote:
>> 2) I2C/SPI ...
>>
>>tsched t0 t1 t2
>> transfer(newsec) RTC update (newsec)RTC increments seconds
>>
>>Lets assume that ttran
On Thu, Dec 03, 2020 at 10:31:02PM +0100, Thomas Gleixner wrote:
> On Thu, Dec 03 2020 at 22:05, Thomas Gleixner wrote:
> > On Thu, Dec 03 2020 at 12:16, Jason Gunthorpe wrote:
> > So now we have two options to fix this:
> >
> >1) Use a negative sync_offset for devices which need #1 above
> >
On 03/12/2020 22:05:09+0100, Thomas Gleixner wrote:
> 2) I2C/SPI ...
>
>tsched t0 t1 t2
> transfer(newsec) RTC update (newsec)RTC increments seconds
>
>Lets assume that ttransfer = t1 - t0 is known.
Note that ttransfer is one of the rea
On Thu, Dec 03 2020 at 22:05, Thomas Gleixner wrote:
> On Thu, Dec 03 2020 at 12:16, Jason Gunthorpe wrote:
> So now we have two options to fix this:
>
>1) Use a negative sync_offset for devices which need #1 above
> (rtc_cmos & similar)
>
> That requires setting tsched to t2 - abs(
On Thu, Dec 03 2020 at 12:16, Jason Gunthorpe wrote:
> On Thu, Dec 03, 2020 at 04:39:21PM +0100, Thomas Gleixner wrote:
>
>> The logic in sync_cmos_clock() and rtc_set_ntp_time() is different as I
>> pointed out: sync_cmos_clock() hands -500ms to rtc_tv_nsec_ok() and
>> rtc_set_ntp_time() uses +500
On Thu, Dec 03, 2020 at 05:07:53PM +0100, Alexandre Belloni wrote:
> On 03/12/2020 11:52:49-0400, Jason Gunthorpe wrote:
> > On Thu, Dec 03, 2020 at 03:10:47AM +0100, Alexandre Belloni wrote:
> >
> > > IIRC, used in conjunction with rtc_hctosys which also adds
> > > inconditionnaly 500ms this can
Alexandre,
On Thu, Dec 03 2020 at 18:29, Alexandre Belloni wrote:
> On 03/12/2020 16:39:21+0100, Thomas Gleixner wrote:
>> On Thu, Dec 03 2020 at 03:10, Alexandre Belloni wrote:
>> > On 03/12/2020 02:14:12+0100, Thomas Gleixner wrote:
>> > Coincidentally, I was going to revert those patches for v5
On 03/12/2020 16:39:21+0100, Thomas Gleixner wrote:
> Alexandre,
>
> On Thu, Dec 03 2020 at 03:10, Alexandre Belloni wrote:
> > On 03/12/2020 02:14:12+0100, Thomas Gleixner wrote:
> >> That said, can somebody answer the one million dollar question which
> >> problem is solved by all of this magic
On Thu, Dec 03, 2020 at 04:39:21PM +0100, Thomas Gleixner wrote:
> The logic in sync_cmos_clock() and rtc_set_ntp_time() is different as I
> pointed out: sync_cmos_clock() hands -500ms to rtc_tv_nsec_ok() and
> rtc_set_ntp_time() uses +500ms, IOW exactly ONE second difference in
> behaviour.
I un
On 03/12/2020 11:52:49-0400, Jason Gunthorpe wrote:
> On Thu, Dec 03, 2020 at 03:10:47AM +0100, Alexandre Belloni wrote:
>
> > IIRC, used in conjunction with rtc_hctosys which also adds
> > inconditionnaly 500ms this can ends up with the system time
> > being one second away from the wall clock ti
On Thu, Dec 03, 2020 at 03:10:47AM +0100, Alexandre Belloni wrote:
> IIRC, used in conjunction with rtc_hctosys which also adds
> inconditionnaly 500ms this can ends up with the system time
> being one second away from the wall clock time which NTP will take quite
> some time to remove.
I can't r
Alexandre,
On Thu, Dec 03 2020 at 03:10, Alexandre Belloni wrote:
> On 03/12/2020 02:14:12+0100, Thomas Gleixner wrote:
>> That said, can somebody answer the one million dollar question which
>> problem is solved by all of this magic nonsense?
>>
> The goal was to remove the 500ms offset for all
Hello Thomas,
I'll take more time to reply more in depth to the whole email but...
On 03/12/2020 02:14:12+0100, Thomas Gleixner wrote:
> Aside of that the magic correction of the time which is written to the
> RTC is completely bogus. Lets start with the interface and the two
> callers of it:
>
On Thu, Dec 03, 2020 at 02:14:12AM +0100, Thomas Gleixner wrote:
> If anyone involved seriously believes that any of this solves a real
> world problem, then please come forth an make your case.
The original commit 0f295b0650c9 ("rtc: Allow rtc drivers to specify
the tv_nsec value for ntp") was t
Cc+ RTC folks.
On Wed, Dec 02 2020 at 23:08, Thomas Gleixner wrote:
> On Wed, Dec 02 2020 at 16:54, Jason Gunthorpe wrote:
>>> I don't think the timer should be canceled if the ntp_synced() state did
>>> not change. Otherwise every do_adtimex() call will cancel/restart
>>> it, which does not mak
On Wed, Dec 02, 2020 at 11:08:38PM +0100, Thomas Gleixner wrote:
> >
> > arch/x86/kernel/kvmclock.c: x86_platform.set_wallclock =
> > kvm_set_wallclock;
> > arch/x86/kernel/x86_init.c: x86_platform.set_wallclock =
> > set_rtc_noop;
> > arch/x86/xen/time.c:x86_platform.
On Wed, Dec 02 2020 at 16:54, Jason Gunthorpe wrote:
> On Wed, Dec 02, 2020 at 08:21:00PM +0100, Thomas Gleixner wrote:
>> So it will not write immediately. It will run through at least one
>> retry.
>
> Right, bascially this is scheduling a WQ to do sched_sync_hw_clock()
> which will only call hrt
On Wed, Dec 02, 2020 at 08:21:00PM +0100, Thomas Gleixner wrote:
> On Wed, Dec 02 2020 at 12:27, Jason Gunthorpe wrote:
> > On Wed, Dec 02, 2020 at 02:44:53PM +0100, Thomas Gleixner wrote:
> >>if (IS_ENABLED(CONFIG_GENERIC_CMOS_UPDATE) ||
> >>IS_ENABLED(CONFIG_RTC_SYSTOHC))
> >> -
On Wed, Dec 02 2020 at 12:27, Jason Gunthorpe wrote:
> On Wed, Dec 02, 2020 at 02:44:53PM +0100, Thomas Gleixner wrote:
>> if (IS_ENABLED(CONFIG_GENERIC_CMOS_UPDATE) ||
>> IS_ENABLED(CONFIG_RTC_SYSTOHC))
>> -queue_delayed_work(system_power_efficient_wq, &sync_work, 0);
>>
On Wed, Dec 02 2020 at 16:36, Miroslav Lichvar wrote:
> On Wed, Dec 02, 2020 at 04:07:28PM +0100, Miroslav Lichvar wrote:
>> On Wed, Dec 02, 2020 at 02:44:53PM +0100, Thomas Gleixner wrote:
>> > Something like the completely untested below should make this reliable
>> > and only needs to retry when
On Wed, Dec 02, 2020 at 02:44:53PM +0100, Thomas Gleixner wrote:
> So if this ends up in level #1 then again the chance is pretty low that
> the expiry time is aligned to the the level period. If this works then
> it only works by chance.
Yes, I always thought it was timer wheel related, but at l
On Wed, Dec 02, 2020 at 04:07:28PM +0100, Miroslav Lichvar wrote:
> On Wed, Dec 02, 2020 at 02:44:53PM +0100, Thomas Gleixner wrote:
> > Something like the completely untested below should make this reliable
> > and only needs to retry when the work is running late (busy machine),
> > but the wakeu
On Wed, Dec 02, 2020 at 02:44:53PM +0100, Thomas Gleixner wrote:
> Something like the completely untested below should make this reliable
> and only needs to retry when the work is running late (busy machine),
> but the wakeup will be on time or at max 1 jiffie off when high
> resolution timers are
On Tue, Dec 01 2020 at 13:35, Jason Gunthorpe wrote:
> On Tue, Dec 01, 2020 at 06:14:20PM +0100, Miroslav Lichvar wrote:
>> I found no good explanation. It seems to depend on what system is
>> doing, if it's idle, etc. I suspect it's a property of the workqueues
>> that they cannot generally guaran
On Tue, Dec 01, 2020 at 06:14:20PM +0100, Miroslav Lichvar wrote:
> On Tue, Dec 01, 2020 at 12:12:24PM -0400, Jason Gunthorpe wrote:
> > On Tue, Dec 01, 2020 at 03:38:35PM +0100, Miroslav Lichvar wrote:
> > > + unsigned long time_set_nsec_fuzz;
> > > + static unsigned int attempt;
> >
> > Adding a
On Tue, Dec 01, 2020 at 12:12:24PM -0400, Jason Gunthorpe wrote:
> On Tue, Dec 01, 2020 at 03:38:35PM +0100, Miroslav Lichvar wrote:
> > + unsigned long time_set_nsec_fuzz;
> > + static unsigned int attempt;
>
> Adding a static value instide a static inline should not be done
Well, grepping t
On Tue, Dec 01, 2020 at 03:38:35PM +0100, Miroslav Lichvar wrote:
> When the system clock is marked as synchronized via adjtimex(), the
> kernel is expected to copy the system time to the RTC every 11 minutes.
>
> There are reports that it doesn't always work reliably. It seems the
> current requi
36 matches
Mail list logo
