I notice that 32 bits are 136 years. But as IEEE defined it as 48 bits. And we try to make the ptp4l compliance with IEEE.
In the same manner that we add zero pad to management GET message, since IEEE recommends. I think, we need to support 48 bits in ptp4l and display the proper value in PMC. I do agree that setting the value by PMC is not necessary. And I doubt if any one really need these extra 16 bits. As I am sure no one really needs the GET message data filled with zeros. Erez -----Original Message----- From: Richard Cochran <[email protected]> Sent: Wednesday, 10 November 2021 15:52 To: Geva, Erez (ext) (DI PA DCP R&D 3) <[email protected]> Cc: [email protected] Subject: Re: [Linuxptp-devel] [PATCH RFC v3 06/10] Add the ALTERNATE_TIME_OFFSET_PROPERTIES management message. On Wed, Nov 10, 2021 at 08:57:35AM +0000, Geva, Erez wrote: > Hi, > > According to IEEE 1588 timeOfNextJump is 48 bits. > The alternate_time_offset_properties structure reserve the full 48 bits. > The pre and the post function do full handle. > But the rest handle only the low 32 bits. > > I can understand the PMC set use 32 bits only, but the rest? The resolution of timeOfNextJump is one second. Twenty five bits of seconds is more then enough for a time zone change one year out. 32 bits allows time zone change 136 years in the future. Do we really need the high order bytes of the 48 bit field? Thanks, Richard _______________________________________________ Linuxptp-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/linuxptp-devel
