Udo van den Heuvel via devel writes:
> On another box:
[please add the log as an attachment or tell your MUA not to break the lines]
> Apr 12 14:32:16 box.local ntpd[2109]: CLOCK: ts_prev 1555072336 s + 595028760
> ns, ts_min 1555072336 s + 595027293 ns
> Apr 12 14:32:16 box.local ntpd[2109]: CL
Here is a typical batch of the confusing CLOCK printout:
Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: ts_prev 1555072655 s +
712154322 ns, ts_min 1555072655 s + 712153764 ns
Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: ts 1555072655 s + 712154322 ns
Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: sys
Hal Murray via devel writes:
> The general idea is that if your system clock goes tick, tick, tick, in great
> big steps, you want to fill in the bottom bits with randomness. The code
> does
> that by assuming that the tick size is the time it takes to read the clock -
> difference in times be
On 13-04-19 10:09, Hal Murray via devel wrote:
> Here is a typical batch of the confusing CLOCK printout:
>
> Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: ts_prev 1555072655 s +
> 712154322 ns, ts_min 1555072655 s + 712153764 ns
> Apr 12 14:37:35 box.local ntpd[2109]: CLOCK: ts 1555072655 s + 7121
> clocksource is fixed at hpet since the previous situations where clock sync
> was weird/gone/etc.
> I never ever saw these before.
Something changed. All we have to do is figure out what/when.
Was the switch to using HPET recent?
Did you do a recent git pull? Do you know how to drive git
On 13-04-19 12:21, Hal Murray wrote:
>> I never ever saw these before.
>
> Something changed. All we have to do is figure out what/when.
>
> Was the switch to using HPET recent?
hpet must have been the default until it wasn't or at least tsc stopped
being stable.
> Did you do a recent git pull
> I know about bisect but it is quite a task.
HPET works for me.
So far, you have the only test case.
Plese give it a quick try to see if ntpsec is the problem. How about just
trying the 1.1.3 release?
--
These are my opinions. I hate spam.
___
Udo van den Heuvel via devel writes:
> Fedora 29, kernel.org 4.19.30. (my compile)
Is this a "tickless" kernel perhaps? If so, try "nohz=off" on the
kernel command line in the boot manager and see if that helps.
> AMD Ryzen 5 2400G with Radeon Vega Graphics
While Raven Ridge should fully work w
On 13-04-19 15:29, Achim Gratz via devel wrote:
> Udo van den Heuvel via devel writes:
>> Fedora 29, kernel.org 4.19.30. (my compile)
>
> Is this a "tickless" kernel perhaps? If so, try "nohz=off" on the
> kernel command line in the boot manager and see if that helps.
# grep HZ .config|grep -v ^
On 13-04-19 14:02, Hal Murray wrote:
> Plese give it a quick try to see if ntpsec is the problem. How about just
> trying the 1.1.3 release?
ntpsec 1.1.3's ntpd from
ftp://ftp.ntpsec.org/pub/releases/ntpsec-1.1.3.tar.gz gives me after
startup:
Apr 13 15:53:50 bla ntpd[12382]: CLOCK: ts_prev 155
Udo van den Heuvel via devel writes:
> On 13-04-19 15:29, Achim Gratz via devel wrote:
>> Udo van den Heuvel via devel writes:
>>> Fedora 29, kernel.org 4.19.30. (my compile)
>>
>> Is this a "tickless" kernel perhaps? If so, try "nohz=off" on the
>> kernel command line in the boot manager and see
On 13-04-19 18:28, Achim Gratz via devel wrote:
>> !?
>> What /was/ the problem in that case?
>
> The same that you still see: the system clock gets stopped and two
> consecutive reads of the clock read the same (or maybe time even goes
> backwards when looked at with higher resolution).
Timetrav
12 matches
Mail list logo
