Richard,
Thanks for the feedback. As I mentioned to Erez, my goal is to provide access
to the statistics behind this log message without resorting to log scraping:
ptp4l[5024110.731]: rms 9 max 17 freq -17594 +/- 14 delay 220 +/- 1
I wasn’t aware of the SUBSCRIBE_EVENTS_NP…that partially solves my use case for
the first two numbers - rms and max offset.
./pmc -d 24 -u 'SET SUBSCRIBE_EVENTS_NP duration 10 NOTIFY_PORT_STATE on
NOTIFY_TIME_SYNC on'
…
0c42a1.fffe.d1d1bd-0 seq 67 RESPONSE MANAGEMENT TIME_STATUS_NP
master_offset -13
ingress_time 1622134808076003202
cumulativeScaledRateOffset +0.000000000
scaledLastGmPhaseChange 0
gmTimeBaseIndicator 0
lastGmPhaseChange 0x0000'0000000000000000.0000
gmPresent true
…
I could use the ‘master_offset’ notifications to calculate statistics on the
offset in an external program, but in order to calculate statistics on the
frequency (rate) that external program would need to make assumptions on the
servo tracking loop internal state variables and loop coefficients, i.e. the
‘adj’ variable (which is the rate) is also required:
static void clock_stats_update(struct clock *c,
double offset, double freq)
…
adj = servo_sample(c->servo, offset, tmv_to_nanoseconds(ingress),
weight, &state);
…
if (c->stats.max_count > 1) {
clock_stats_update(c, tmv_dbl(c->master_offset), adj);
Using only the SUBSCRIBE_EVENTS_NP would also leave the delay statistic
unavailable.
Thanks,
Tim
From: Richard Cochran <richardcoch...@gmail.com>
Date: Thursday, May 27, 2021 at 6:18 AM
To: Tim Martin <timot...@nvidia.com>
Cc: linuxptp-devel@lists.sourceforge.net <linuxptp-devel@lists.sourceforge.net>
Subject: Re: [Linuxptp-devel] [PATCH] Add new CLOCK_STATS_NP TLV GET to pmc and
clock
External email: Use caution opening links or attachments
On Tue, May 25, 2021 at 08:28:34PM +0000, Tim Martin wrote:
> Currently there is no way to programmatically access statistics about
> the clock frequency offset, time delay, or time offset (collectively,
> the "clock_stats" metrics), except for parsing the ptp4l logs. One
> option for time offset would be to poll TLV_TIME_STATUS_NP in regular
> intervals from a custom client, but that has the disadvantage of either
> very high poll rates or missed updates which would affect the statistics.
Not if you use the push method.
commit 6d7c090706e76af334185ffcec9cc56d0570e215
Author: Juergen Werner <pogoj...@gmx.net>
Date: Wed Jan 20 20:11:34 2021 +0100
Implement push notification for TIME_STATUS_NP
Subscribers to NOTIFY_TIME_SYNC will be notified on every clock
synchronization.
Thanks,
Richard
_______________________________________________
Linuxptp-devel mailing list
Linuxptp-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
