Request - Support delayed RTC response

[ericr3r]

We have a client deploying a Nerves device in a network where the outbound traffic all goes through a proxy server. I'm looking at setting the time initially using time retrieved via an http request. Looking at NervesTime it seems like the best option would to simulate an RTC but unlike a real RTC, there is a high probability that the time won't be available on the initial call. I can either recreate some of the logic of setting the time that NervesTime does or update the library in either of the following ways:

• Update NervesTime.RealTimeClock.get_time/1 to also accept a return of {:not_available, state, retry_time} and do a Process.send_after to check the rtc after the specified interval
• Manage the state myself in my Network Time module and make NervesTime.rtc_check_time_and_set or a similar function public to allow the system time to be set if the Network Time is later I'm more inclined for the first option though both add a maintenance burden on the NervesTime library so I'm open to either approach. The first case could also handle intermittent failures when reading a RTC.

The second scenario looks like #5

[fhunleth]

Do you have a public time server in mind or were you thinking about implementing a current_time endpoint on a server that you run? I.e., could this be an alternative to NTP?

The reason that I ask is that the Busybox NTP used by nerves_time has more limitations than just not being able to traverse a proxy and it would be good to have an alternative.

Another option would be that we finally implement #5 and then you'd implement this outside of nerves_time completely.

[ericr3r]

We're looking at an initial implementation where we would get the date time of of an http header for a server that we control. In our case this probably means time is off by 10 seconds or more.

I like the idea of using Roughtime so from a design perspective, I'm interested in how you would design assuming a more generalized implementation. Would you consider Roughtime as a suitable RTC or alternative to ntpd altogether? The only problem I see with Roughtime at the moment is that the most complete implementations are in rust and go so creating an official library may be difficult.

Implementing #5 definitely gives us the most flexibility especially since we potentially could chain multiple time sources and handle retries outside of nerves_time. The logic that does a sanity check before setting the time is critical since there is always a potential race between ntpd and our process.

[fhunleth]

I think Roughtime and NTP as different things from RTCs. The former are authoritative time sources that should be used in preference to the time on an RTC (or FileTime). Whereas RTCs and FileTime are good for when there's no network connection. There might be an abstraction that encompasses both RTCs and network time sources, but I feel like keeping them separate would save possible confusion.

I haven't looked at the Roughtime, so I'm currently ignorant of how long it would take to implement. It sounds like there are some details. Honestly, I was hoping that it would be something trivial like what you're looking at for getting started, and then if you wanted something with better precision, you'd do more.

I don't mind if we go the #5 route, though. That's been on the backburner forever and it doesn't seem like it should be that hard to implement. I.e., the code that gets called from it would be the same as what happens when NTP reports a good time. The only challenge may be that the time setting code is currently tangled a bit in with NTP for historical reasons.

If you have time to make a pass at implementing #5, I'll shepherd it though. That's probably the most practical way forward given limited time.

[fhunleth]

Regarding the race between NTP and your process for #5, how about disabling NTP completely by setting the servers list to be empty? It seems like NTP isn't really useful in your use case any more.

[ericr3r]

Most of our clients are not behind a proxy server so ntp is still useful. I think it makes sense to treat the system time set by an external process the same way that RTC updates are done today, checking before actually applying.

Not 100% sure but I'll like create an additional GenServer to handle setting the time and managing the RTC, separating the RTC logic from Ntpd. The code doesn't look difficult, just making sure to split the concerns appropriately,

[fhunleth]

@erauer Two questions: 1. Are you ok with closing this now that the manual clock setting feature has been released? 2. If you haven't already implemented your solution, would something like https://github.com/angeloc/htpdate be acceptable? It seems like this could be written in far less code in Elixir and added as an alternative to NTP.

[fhunleth]

Here's another link: http://www.vervest.org/htp/

[ericr3r]

@fhunleth Yes, glad to see the release, I'll close.

We ended up doing a simpler mechanism since TLS connections can tolerate a greater delay.

htpd looks interesting though from what I can tell, there isn't a separate specification and the source is GPL.

[fhunleth]

Thanks. Sounds good on the simpler mechanism.