On Mon, Jan 10, 2022 at 01:47:45PM +0100, Miroslav Lichvar wrote:
> This was proposed several times before. You can search the archives
> and see if you have a new argument that could be made.
+1
I won't accept patches with custom hardware hacks.
You have two choices:
1. Teach your hardware no
Hi,
Sorry for sending the patch twice. Please check below example output
(servo_offset_threshold=1000, step_threshold=0.02, servo_num_offset_values=5):
…
ptp4l[218.354]: master offset 20 s3 freq +72300 path delay 728
ptp4l[218.604]: master offset 36 s3 freq +72324 path del
Currently servo state stays in S3 (SERVO_LOCKED_STABLE) even though
clock offset increases above servo_offset_threshold value (but is still
below step_threshold value). With this change servo will switch to S2
(SERVO_LOCKED) every time clock offset is bigger than servo_offset_threshold.
It will sti
Currently servo state stays in S3 (SERVO_LOCKED_STABLE) even though
clock offset increases above servo_offset_threshold value (but is still
below step_threshold value). With this change servo will switch to S2
(SERVO_LOCKED) every time clock offset is bigger than servo_offset_threshold.
It will sti
On Mon, Jan 10, 2022 at 08:34:04AM +, Cindy Han via Linuxptp-devel wrote:
> Hi,
>
> We met some issues during ptp4l test, and we believe these issues shall be
> fixed by ptp4l.
>
> 1. According the standard, the ptp4l shall not check the suffix for
> Delay_req since it is event message.
Hi,
We met some issues during ptp4l test, and we believe these issues shall be
fixed by ptp4l.
1. According the standard, the ptp4l shall not check the suffix for
Delay_req since it is event message.
13.2 General message format requirements
All messages shall have a header, body, and suffix.
