On 12-04-2020 17:25, ASSI via devel wrote:
>> # ppswatch /chroot/ntpd/dev/pps0
>> (shows similar output)
>
> Good, but does ntpd see the same?
Well, devices look like this:
# ls -l /dev/*ps*
lrwxrwxrwx 1 root root 5 Apr 12 16:54 /dev/gps0 -> ttyS0
lrwxrwxrwx 1 root root 4 Apr 12 16:54
Udo van den Heuvel via devel writes:
> When then is the jitter so low?
> If solely using NMEA the jitter and offset would be worse.
Well, run ntpq with the -u switch to see what those really are. If
you've set the serial to low latency and a fairly high speed, you can
expect jitter in the single-
On 12-04-2020 14:55, ASSI via devel wrote:
> Udo van den Heuvel via devel writes:
>> Using tsc clocksource we get:
>>
>> # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
>> tsc
>> # ntpq -pn
>> remote refid st t when poll reach delay offset
>> jitter
>
Udo van den Heuvel via devel writes:
> Using tsc clocksource we get:
>
> # cat /sys/devices/system/clocksource/clocksource0/current_clocksource
> tsc
> # ntpq -pn
> remote refid st t when poll reach delay offset
> jitter
> ===
On 12-04-2020 11:43, Udo van den Heuvel via devel wrote:
>> You might want to try if disabling C6
>
> Thanks.
Using tsc clocksource we get:
# cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc
# ntpq -pn
remote refid st t when poll reach delay offset
On 12-04-2020 11:39, ASSI via devel wrote:
> Udo van den Heuvel via devel writes:
>> So we went to tsc by disabling hpet but that one also has an issue.
>> Now we are on acpi_pm.
>
> That is going to suck rocks. So it's just about any clock in your
> system going backwards at times except the ACP
Udo van den Heuvel via devel writes:
> So we went to tsc by disabling hpet but that one also has an issue.
> Now we are on acpi_pm.
That is going to suck rocks. So it's just about any clock in your
system going backwards at times except the ACPI-PM?
> See https://pastebin.com/5BbgWVFt for a dmes
On 12-04-2020 10:33, ASSI via devel wrote:
> Udo van den Heuvel via devel writes:
>> When booting with hpet=disable we see stuff like:
>
> Well, what clock sources get reported on boot when you don't force
> anything and which one gets ultimately selected by the kernel? Are you
> actually using a
Udo van den Heuvel via devel writes:
> When booting with hpet=disable we see stuff like:
Well, what clock sources get reported on boot when you don't force
anything and which one gets ultimately selected by the kernel? Are you
actually using a kernel new enough to know about Ryzen CPU, and does i
On 03-11-2019 13:10, Achim Gratz via devel wrote:
> based on the comments in the source. Again, if you don#t actually use
> hardpps (and if this is the same Ryzen system you've had the timer
> trouble on) it would be much more likely to work if you didn't configure
> NTP_PPS and left the timer sel
10 matches
Mail list logo
