Hi,
I would prefer a mode of programmatically obtaining clock data possibly via our private management bus? This way no string processing would have to be done, as we could obtain this data in a structured format via the management interface possibly..
I donât want to remove labels, as when reading by a human you have to either memorize the order, or go back and read the labels if its only printed one time.
I agree that we should update the temporal vortex method, such as Richard suggested as âforeign masterâs UTC offset is invalidâ
Regards,
Jake
From: Rich Schmidt [mailto:***@gmail.com]
Sent: Monday, December 22, 2014 1:05 PM
To: Richard Cochran
Cc: linuxptp-***@lists.sourceforge.net
Subject: Re: [Linuxptp-devel] Feature enhancement request
The comments by Richard are all well taken. My history is that I have been running tests of various hardware for the past year and have actually stripped out ALL the labels in the pr_info()s to make plotting data simpler. I also stripped out the [ ] brackets from the time and otherwise economized on the output. Once one gets familiar with the output the labels are not needed; I suggest them as a one-time header line instead. However, for newbies they are of course helpful. So I agree let us not disturb parsing operations at this time.
As regards Star Trek, and Dr. Who, I note that according to NASA's Gravity Probe-B as announced in 2011 the Earth is indeed in a (tiny) Temporal Vortex, and so I assumed that the "running in a temporal vortex" message simply meant that all is well; it was only by reading the code that I figured out why I kept getting this message and was able to progress beyond.
Rich
On Mon, Dec 22, 2014 at 3:23 PM, Richard Cochran <***@gmail.com<mailto:***@gmail.com>> wrote:
Rich,
Post by Rich SchmidtI find it useful to output offset_stats.mean along with
offset_stats.stddev in clock_stats_update() in file clock.c,
While I am not really opposed to this change, still it might break
people's scripts that parse the logging output. We can take this idea
one step further by making the output configurable. That way we can
have our cake and eat it too. But that will have to wait for the next
release.
Post by Rich Schmidtalso I
suggest we replace the reference to temporal vortex... See attached diff.
(Don't you like star trek? ;)
Comments follow...
Post by Rich Schmidt--- clock.c 2014-12-21 22:09:18.867186011 +0000
+++ clock2.c 2014-12-21 21:59:46.252315374 +0000
@@ -354,15 +354,17 @@ static void clock_stats_update(struct cl
/* Path delay stats are updated separately, they may be empty. */
if (!stats_get_result(s->delay, &delay_stats)) {
- pr_info("rms %4.0f max %4.0f "
+ pr_info("offset %+6.0f +/- rms %4.0f max %4.0f "
"freq %+6.0f +/- %3.0f "
"delay %5.0f +/- %3.0f",
- offset_stats.rms, offset_stats.max_abs,
+ offset_stats.mean,
+ offset_stats.stddev, offset_stats.max_abs,
Before we had (rms, max), and you have here (mean, stddev, max).
Did you mean to have (mean, rms, max) instead, or did you forget to
change the label?
Post by Rich Schmidtfreq_stats.mean, freq_stats.stddev,
delay_stats.mean, delay_stats.stddev);
} else {
- pr_info("rms %4.0f max %4.0f "
+ pr_info("offset %+6.0f +/- rms %4.0f max %4.0f "
"freq %+6.0f +/- %3.0f",
+ offset_stats.mean,
offset_stats.rms, offset_stats.max_abs,
freq_stats.mean, freq_stats.stddev);
}
@@ -478,7 +480,7 @@ static void clock_update_slave(struct cl
pr_warning("foreign master not using PTP timescale");
}
if (c->tds.currentUtcOffset < CURRENT_UTC_OFFSET) {
- pr_warning("running in a temporal vortex");
+ pr_warning("tds.currentUtcOffset < CURRENT_UTC_OFFSET");
Hm. So I guess that you object to this message because it really does
not say what the problem is. The inequality might not make sense
either, to people unfamiliar with C programming cliches. Maybe it
would be better to say something like, "foreign master's UTC offset is
invalid", or similar.
Thoughts?
Thanks,
Richard