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 code uses proper 64 bits float.
I guess, this is why Richard avoid using it.
However Miroslav is right that you do need to change to network order.
Something like :
stats->freq_stats = __cpu_to_be64((uint64_t)(c->freq_stats));
And define
struct clock {
...
float freq_stats,
...
};
struct clock_stats_np_tlv {
...
uint64 freq_stats,
...
};
Or follow Miroslav advice and use integers only.
Erez
From: Tim Martin <[email protected]>
Sent: Thursday, 27 May 2021 18:52
To: Miroslav Lichvar <[email protected]>
Cc: [email protected]
Subject: Re: [Linuxptp-devel] [PATCH] Add new CLOCK_STATS_NP TLV GET to pmc and
clock
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 <[email protected]<mailto:[email protected]>>
Date: Wednesday, May 26, 2021 at 4:45 AM
To: Tim Martin <[email protected]<mailto:[email protected]>>
Cc:
[email protected]<mailto:[email protected]>
<[email protected]<mailto:[email protected]>>
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:
> +struct clock_stats_np_tlv {
> + struct stats_result offset_stats;
> + struct stats_result freq_stats;
> + struct stats_result delay_stats;
> + uint8_t offset_freq_stats_valid;
> + uint8_t delay_stats_valid;
> +} PACKED;
Floating-point formats are not generally portable. In a network
protocol they need to be converted to something else. Some of the
implemented TLVs use fixed-point formats shifting by 32 or 41 bits. In
this case I think it might be ok to just use integer nanoseconds and
parts per billion.
--
Miroslav Lichvar
_______________________________________________
Linuxptp-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
