On Wed, May 26, 2021 at 05:45:29PM +, Amar Subramanyam wrote:
> Hi Miroslav,
>
> We were able to reproduce the issue even without running phc2sys.
> Please find the attached strace and ptp4l logs when this issue is seen.
Ok, thanks. That's very helpful.
> From the ptp4l log, we can see that
On Tue, May 25, 2021 at 08:28:34PM +, 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
On Wed, May 26, 2021 at 12:24:06PM +0300, Amar Subramanyam via Linuxptp-devel
wrote:
> The LISTENING port prints continuously
> "selected best master clock 00..03
> updating UTC offset to 37"
>
> We limited the log such that now it prints only when there is a
> change in the best-mast
On Wed, May 26, 2021 at 12:24:07PM +0300, Amar Subramanyam via Linuxptp-devel
wrote:
> The port other than SLAVE (LISTENING port) prints an error
> "port 1: master state recommended in slave only mode
> ptp4l[1205469.356]: port 1: defaultDS.priority1 probably misconfigured"
> for every ANNOUNCE RE
Thanks for the feedback Erez,
My goal of this initial patch was to give an API to extract the statistics that
are already calculated/existing in the clock module and already printed to the
logs, i.e. the statistics that generate the numbers in this log message:
/* Path delay stats are u
Thanks Miroslav,
Thanks for the feedback. Sure, I can make an update to send
network(big)-endian fixed point instead of platform-endian floating point if
the patch will otherwise be accepted, but need to resolve the feedback from
Erez and Richard first.
Tim
From: Miroslav Lichvar
Date: Wedn
Hi,
I would like to use this opportunity to promote the libpmc library.
https://sf.net/p/linuxptp/
The library provide the functionality of the pmc tool.
It comes with wrapping for python, Perl, Lua, php, ruby.
And runs more then 20 times faster then the original linuxptp pmc tool
Query a singl
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]: rms9 max 17 freq -17594 +/- 14 delay 220 +/- 1
I wasn’t aware of the SUBSCRIBE_EVENTS_NP…that parti
IEEE 1558 2019 does define Float64 that follow using the IEEE Std 754
As most hardware that runs Linux already use IEEE Std 754 (on hardware level or
library level for hardware lacking floating point).
The Float64 match C float on most 64 bits machine.
You may need more code to ensure your C cod
