NTP client recommendation for RTEMS?

[Joel Sherrill]

Are you planning to get the NTP server side of the freebsd-org code working?

Or get it building but not testing it?

Or just focusing on building and testing JUST the client part.

Thanks.

--joel

On Fri, Feb 18, 2022 at 8:39 AM Joel Sherrill <joel at rtems.org> wrote:
>
> On Fri, Feb 18, 2022 at 7:46 AM Sebastian Huber
> <sebastian.huber at embedded-brains.de> wrote:
> >
> > On 18/02/2022 14:43, Joel Sherrill wrote:
> > > On Fri, Feb 18, 2022, 7:22 AM Sebastian Huber
> > > <sebastian.huber at embedded-brains.de
> > > <mailto:sebastian.huber at embedded-brains.de>> wrote:
> > >
> > >     Hello,
> > >
> > >     I would like to add an NTP client support for RTEMS. The ntp_adjtime()
> > >     implementation is already available as a patch. For testing purposes I
> > >     ported the NTP daemon from FreeBSD to libbsd. This basically works
> > >     fine.
> > >     I am not sure about the maintenance status of this code
> > >     (https://www.ntp.org/ <https://www.ntp.org/>). There is also
> > >
> > >     https://www.ntpsec.org/ <https://www.ntpsec.org/>
> > >
> > >     This project has a public Git repository and seems to be more active.
> > >     However, there is no standard package for openSUSE Leap 15.3. Maybe
> > >     this
> > >     is because most Linux users use now timesyncd from systemd. Any
> > >     recommendations?
> > >
> > >
> > > I'd stick with ntp.org <http://ntp.org> without much thought. With that
> > > being what FreeBSD uses, it is icing on the cake.
> >
> > The code looks not that good. There seems to be a lot of cleanup done in
> > ntpsec.org.
>
> Yes that is true. And I will communicate my concerns offline. One of
> the main ones is that the ntpsec project was heading in a very Linux
> centric way on what APIs would be used. They did kill a lot of old platforms
> and do some clean up which is good.
>
> There were discussions about re-writing it in Go. If that happens, we
> would have issues.
>
> In general, I leaned to the freebsd.org code because we already have
> a process in place for dealing with it. And if it is good enough for FreeBSD,
> it should be a good first choice for us.
>
> If this turns out to be wrong, there is ntpsec and OpenNTP which seem
> to be derived from ntp.org. Any porting done on the freebsd.org code should
> apply to the others easily enough.
>
> No idea what to do about a full NTP client for lwip. Any thoughts?
>
> >
> > >
> > > Did you eliminate use of signals like Chris had to do with ptpd?
> >
> > Not yet, they use both select(), but this should be changed to use
> > kqueue(). I hacked away the use of signal.
>
> Great! Is this work going to land in the public in the near future?
>
> --joel
>
> > --
> > embedded brains GmbH
> > Herr Sebastian HUBER
> > Dornierstr. 4
> > 82178 Puchheim
> > Germany
> > email: sebastian.huber at embedded-brains.de
> > phone: +49-89-18 94 741 - 16
> > fax:   +49-89-18 94 741 - 08
> >
> > Registergericht: Amtsgericht München
> > Registernummer: HRB 157899
> > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> > Unsere Datenschutzerklärung finden Sie hier:
> > https://embedded-brains.de/datenschutzerklaerung/