| Re: [chrony-users] Chrony on CM4 |
[ Thread Index |
Date Index
| More chrony.tuxfamily.org/chrony-users Archives
]
On Mon, Sep 04, 2023 at 08:03:45PM +0700, James Clark wrote:
> On Mon, Sep 4, 2023 at 6:51 PM Miroslav Lichvar <mlichvar@xxxxxxxxxx> wrote:
> > Is the server running on CM4?
>
> Yes.
> > Can you please enable the measurements log and see if all TX
> > timestamps are kernel or there is a mix of kernel and hardware?
>
> It's a mixture: 848 "K H"; 22 "K K"; 13 "H H".
I think there might be a problem with TX timestamping being
interrupted by RX timestamping. Server receives first, transmits
later. Client transmits first and might receive the server's response
before the HW/driver is done with the TX timestamp.
To confirm that, you could configure the client to use a distant public
NTP server to give the client more time to get its TX timestamp and
see if the success rate of HW timestamping improves.
> Time stamping parameters for enp1s0:
> Capabilities:
> hardware-transmit
> software-transmit
> hardware-receive
> software-receive
> software-system-clock
> hardware-raw-clock
> PTP Hardware Clock: 3
> Hardware Transmit Timestamp Modes:
> off
> on
> Hardware Receive Filter Modes:
> none
> ptpv2-l4-event
> ptpv2-l2-event
> ptpv2-event
That looks ok. I'm not sure why it doesn't work.
On Mon, Sep 04, 2023 at 08:12:12PM +0700, James Clark wrote:
> I think it's going to be easier to figure out the problem if we have one
> side that is known to work. Is NTP-over-PTP known to work on Intel NICs
> like i210/i225/i226? If so, then tomorrow I'll try with one side as Intel
> NIC and one as CM4.
Those NICs timestamp all received packets and don't care about NTP-over-PTP.
I don't think it will make a difference for the other side on CM4.
--
Miroslav Lichvar
--
To unsubscribe email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "unsubscribe" in the subject.
For help email chrony-users-request@xxxxxxxxxxxxxxxxxxxx
with "help" in the subject.
Trouble? Email listmaster@xxxxxxxxxxxxxxxxxxxx.