temporal consistent put_with_timestamp and getHLCVersion implementati…

[aliciayuting]

Implementation of temporal consistency support

For the put_by_time implemented at the sender side:
previous ordered_put assign the time by calling get_walltime() when constructing the header at get_sendbuffer_ptr.

1. Added ordered_put_with_time to allow the application to use their own timestamp in the header.
2. Added an optional parameter in get_sendbuffer_ptr to allow it takes timestamp

For the get_by_time implemented at the RPC side:
changes are in getHLCVersion
It only allows get time that is < now - \Delta - 2 * \delta (\Delta is the temporal consistency delta, and \delta is the servers' clock skew), where the objects have temporally stabilized
Then it gets the closest object to the requested_time, allowing extra requested_time + \delta , if it is within (now - \Delta - 2 * \delta)

[etremel]

Overall this looks good. Sender-provided message timestamps are a feature we claimed to have in Derecho a long time ago, and it turns out they were easy to implement, so I'm glad you got this done. My questions/comments mostly relate to your new code in FilePersistLog to support temporally-consistent get-by-time. There are some comments in the code; here are my overall questions that don't relate to a specific line of code:

1. The Persistent interface actually has multiple ways to request an object by its timestamp: getVersionAtTime, get() with an HLC parameter, and get() with an HLC and an output-function parameter. The latter two use m_pLog->getHLCIndex() to search for a timestamp in the log, not getHLCVersion(), so (as I noted in a code comment) you need to make getHLCIndex() consistent with getHLCVersion(). You should also make sure these functions work correctly after making your changes.
2. Where will we get the configured values server_clock_skew_delta and temporal_consistency_delta? I'm guessing server_clock_skew_delta should be computed based on the actual observed clock skew between the servers, but is temporal_consistency_delta just a value the user needs to pick based on "how much consistency" they want?
3. Should the temporal_consistency_delta affect the "temporal stability frontier" reported by Replicated<T>? Right now, when Persistent<T> asks Replicated<T> for the temporal stability frontier (through a method called getFrontier()), it returns MulticastGroup's compute_global_stability_frontier, which is simply the minimum of the local_stability_frontier values in all SST rows. If we don't consider log entries temporally stable until they are at least temporal_consistency_delta in the past, should getFrontier() reflect this? Note that the Persistent<T>::get() that requests an object by timestamp is one place the getFrontier() method is called, so you'll need to look at this function anyway when you update getHLCIndex as I mentioned above.

[etremel]

If this code block is intended to find the entry "before or at target_hlc", why does it compare before_it to max_hlc? Since before_it was created by decrementing the search result, you would expect it to always be less than max_hlc (the search key is already less than max_hlc, and then you move the iterator backwards).

[aliciayuting]

There is a slight change here to the findClosestEntry, which is to get the closest entry of time \Tau + \delta to account for clock skew. For example, if we are looking for target timestamp of 10AM, the previous timestamp is 9AM, but there is another one at 10:01AM, and suppose the clock skew is 10 seconds, then the idea is that we return 10:01AM timestamp. Do you think this might work? Happy to take your suggestions on this.

[etremel]

Yes, I understand the intention of findClosestEntry and I agree that it makes sense to return an entry either slightly before or slightly after the target timestamp as long as the one slightly after is within the clock skew. This comment is just pointing out that, on this particular line of code, the if statement will always be true because you just moved the iterator backwards (to the previous log entry). Given that target_hlc < max_hlc and upper_it is the result of searching for target_hlc, upper_it->hlc should be <= max_hlc and before_it->hlc is definitely <= max_hlc.

[aliciayuting]

Ah I see. You are right. That is a good catch!
I fixed this issue you pointed out in the latest commit. Feel free to let me know if I miss anything.

[KenBirman]

Yes, I think this is exactly right. IPad autocorrection by Apple On Jan 18, 2026, at 6:09 AM, Alicia Yang ***@***.***> wrote:  @aliciayuting commented on this pull request.

________________________________ In src/persistent/FilePersistLog.cpp<#289 (comment)>:

+ const HLC& max_hlc) {

+ + if (hidx.empty()) { + return INVALID_INDEX; + } + + struct hlc_index_entry search_key(target_hlc, 0); + auto upper_it = hidx.upper_bound(search_key); + + // Find entry before or at target_hlc + const struct hlc_index_entry* entry_before = nullptr; + int64_t idx_before = INVALID_INDEX; + if (upper_it != hidx.begin()) { + auto before_it = upper_it; + --before_it; + if (before_it->hlc <= max_hlc) { There is a slight change here to the findClosestEntry, which is to get the closest entry of time \Tau + \delta to account for clock skew. For example, if we are looking for target timestamp of 10AM, the previous timestamp is 9AM, but there is another one at 10:01AM, and suppose the clock skew is 10 seconds, then the idea is that we return 10:01AM timestamp. Do you think this might work? Happy to take your suggestions on this. — Reply to this email directly, view it on GitHub<#289 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFQMF37ZZ7UQHVN6X5RHDJD4HOH2VAVCNFSM6AAAAACRTNNKJCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTMNZVGQ4TQNZYGM>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[etremel]

The latest version reflects our discussions for the consistency paper and seems mostly correct. The only problem I notice is a potential bug in getHLCIndex (see the comment). Also, now that we have done experiments we might want to set the default values for delta, Delta and epsilon to some reasonable values from the experiments.

[etremel]

Why is this the only parameter with a default, and why is it this large? Server clock skew should be the smallest value. In fact, now that we've done the experiments for the paper, we can set the defaults to the average values we measured on Fractus: 100 ns for server clock skew, 500 microseconds for client-server epsilon, and 2500 microseconds for consistency delta.

[etremel]

This looks like a logic error. The comment says to reject if the requested time is too recent, but the if statement checks if the requested time is smaller than the threshold, which means it is older than the threshold. A time that is too recent would be greater than the threshold (since the threshold is a time in the past).