Ut1Provider - JPL servers unstability, lack of caching

[Theodlz]

Hey folks! I discovered hifitime recently, through another project called Outfit. It relies on the Ut1Provider, which itself relies on files downloaded from JPL's EOP2 File Archive.

Issue is, last Friday that archive was completely unresponsive for a while (multiple hours). So, I couldn't start my program. Moreover, the file that the Ut1Provider needs is only updated every 24 hours, but it gets fetched every time the provider gets instantiated! This significantly slows down any piece of code that relies on it, at least at startup.

So, I'd like to suggest 2 things:

• First, some caching. That file is updated only once a day, there's no need to re-download it again and again. The cache could be invalidated every 24 hours, and the new file downloaded then.
• As long as we can't grab the new EOP2 file, we can just keep using the cached one and perhaps just log a warning, OR have some argument when building the provide where one can specify if the cache SHOULD always be up-to-date (i.e. we don't tolerate download failures) in which case an error is thrown rather than a warning?

PS: These suggestions came up when discussing with @FusRoman's, so shout out to him :)

[ChristopherRabotin]

Hi Theo,

That makes sense. In ANISE, my SPICE toolkit rewrite and extension, there is the concept of a MetaFile which handles caching based on a quick CRC32 check: https://github.com/nyx-space/anise/blob/master/anise/src/almanac/metaload/metafile.rs#L59. If the local cache's CRC does not match the one in the config file, then the URL will be used to download the file again.

We could implement something similar but with a more failsafe approach without a CRC check.

1. For the UT1 file, try to download it from JPL
2. If it fails, check in the cache for a previous file. If there is one, warn the user that we're using a file old of X hours (based on the updated date returned by the file system), and proceed
3. If the file does not exist, then raise an error.

Would that logic work?

Thanks

[Theodlz]

Hey @ChristopherRabotin, I like that very much. I'd still be in favor of using that knowledge about the file update frequency (i.e. once a day) to avoid downloading the file every time. With what you proposed above, we'll be grabbing the file every time we run the code it seems.

[gwbres]

With what you proposed above, we'll be grabbing the file every time we run the code it seems.

This is the object being mentionned.

The download is triggered by invoking process(), it needs to be specifically invoked.
Side note: I am not sure how process behaves when network is actually unavailable. I presume it eventually times-out.

The update logic is based on the file CRC (comparing the remote CRC to the cached CRC).
We would need a similar object, with the ability to know when the last download took place.
Since one file is published everyday, I think we can get rid of the CRC comparison and simply compare the day of year.

Assuming correct machine/system time at storage time, we could use the file meta directly.
In case of problems related to the system time or physically incorrect storage time, I think we're just fine if we force the download in that case.

Kind of unrelated, but personally, I'd prefer a smart object capable to know the network is unreachable and avoid waiting for a timeout, not sure that's truly doable though. That can be dealt with at the application level, not the library itself

[J-Westin]

How about making the attempted order configurable, e.g. using:

enum SourcePriority {
    Download,
    Cache,
}

as a config value for Ut1Provider? SourcePriority::Download would correspond with the workflow proposed by @ChristopherRabotin, while SourcePriority::Cache would try the cache first.

[ChristopherRabotin]

All good ideas!

I am OK with a smart cache policy based on the update frequency, but note that this may lead to a cache that's twice as long. Say the UT1 file gets updated at 1200 (noon) and your code turns on at 1159 on 1 Jan. with a 24 hour cache. The logic would check if there has been 24 hours between the last download and if not, it uses the old file. So on 1 Jan at 1159, it downloads the file from the 31 Dec, and keeps using it until 2 Jan at 1159. And again. In other words, for all but one minute of the day, you're using an old file.

Concerning the network unavailability, that would return an error on sending the request, and that's caught by the Meta File. If the file doesn't exist, it would cause an error when trying to read the result from the server.

For these reasons, I usually tend to prefer a "dumb cache" that tries to download every time, but that leads to a 1-2 second overhead on every call because the new file is downloaded every time.

You tell me what you prefer though since you're the target user here. Arguably, in the example of the cache issue from above, that's a user error and not a bug. I don't use UT1 myself, so I don't know how big of an impact it could have on the astronomy measurements.

[J-Westin]

Such cache timing issues could also be resolved through configuration, no? The user could specify either a maximum acceptable cache age or a time of day after which the cache should be updated.

[ChristopherRabotin]

That's true. I prefer a maximum cache age, that's a pretty typical approach to caching.

[Theodlz]

I like that option very much! @J-Westin what are you thinking the "default" behavior would be there? Always downloading, or caching for some default number of hours / until a certain time?

[J-Westin]

Like @ChristopherRabotin said, I think it's up to you since you're the main user for now. From what you've indicated so far it seems you'd prefer caching before download as the default, is that right?

[Theodlz]

Actually this is used by @FusRoman's crate that I've started to look at, so maybe he's best suited to answer this. Roman, any preference? I think that caching before download (and only download when cache is considered "too old") is indeed what is best, to avoid triggering downloads so often.

[FusRoman]

A maximum cache age sounds like a solid fix for the download issue and works for me. With clear logging that indicates which source is used, I’m completely ok with this approach.

[gwbres]

Sidenote, @Theodlz

through another project called Outfit. It relies on the Ut1Provider, which itself relies on files downloaded from JPL's EOP2 File Archive

another source for similar information (if need be), would be modern (V4) RINEX files (file class: navigation) published by observatories (see CDDIS.gov). I made the effort to support those files in the RINEX lib, and we provide a cast to Hifitime UT1 object (under nav compilation feature). Not sure this works perfectly, as I am not aware of what purpose they serve, so it definitely needs more testing