Add reliable timestamps to the log file header separately
Brian Smartt and I debugged a log reading crash. The crux of the issue
was that we had the following set of boots and timestamps:
Reverse sort, destination pi0 bc9e966b-1f35-4185-8d31-68727ecc5543 -> pi14
boot dd94ef90-fb0a-4bbd-b56f-3a02759d3cfa time {
.oldest_remote_monotonic_timestamp=9.994426078sec,
.oldest_local_monotonic_timestamp=10.532024791sec,
.oldest_remote_unreliable_monotonic_timestamp=3613.686273388sec,
.oldest_local_unreliable_monotonic_timestamp=821.896901804sec
}
boot 17e97238-f85c-48f4-a33e-60e7ecdde4cd time {
.oldest_remote_monotonic_timestamp=2617.511290249sec,
.oldest_local_monotonic_timestamp=2599.454979372sec,
.oldest_remote_unreliable_monotonic_timestamp=2617.511290249sec,
.oldest_local_unreliable_monotonic_timestamp=2599.454979372sec
}
Our current logic is combining the reliable and unreliable timestamps to
enable sorting when the log file header is created. This is actually
making it harder to sort. We found a new case where reliable timestamps
aren't actually being delivered reliably. So by combining them in with
the unreliable timestamps in the header, we are making it very hard to
figure out what happened first.
Looking at the example above, with the reliable and unreliable
timestamps mixed together, we can see that we get a different answer
than purely using the unreliable timestamps.
Given that our goal is to use messages crossing the network as
measurements of the time on both clocks, we want to prioritize messages
without arbitrary delays, ie unreliable messages. This change gives us
the data to do that, though it doesn't yet actually switch over to using
it yet. The goal here is to start collecting the data before using it.
Change-Id: I0f8fec3ef062508dcefbc89db395a1ce454a251d
Signed-off-by: Austin Schuh <austin.schuh@bluerivertech.com>
diff --git a/aos/events/logging/log_namer.h b/aos/events/logging/log_namer.h
index c3fc5d4..207673d 100644
--- a/aos/events/logging/log_namer.h
+++ b/aos/events/logging/log_namer.h
@@ -98,6 +98,15 @@
// oldest_local_unreliable_monotonic_timestamp.
monotonic_clock::time_point oldest_local_unreliable_monotonic_timestamp =
monotonic_clock::max_time;
+
+ // Timestamp on the remote monotonic clock of the oldest message sent to
+ // node_index_, only including messages forwarded with time_to_live() == 0.
+ monotonic_clock::time_point oldest_remote_reliable_monotonic_timestamp =
+ monotonic_clock::max_time;
+ // Timestamp on the local monotonic clock of the message in
+ // oldest_local_reliable_monotonic_timestamp.
+ monotonic_clock::time_point oldest_local_reliable_monotonic_timestamp =
+ monotonic_clock::max_time;
};
private: