Add the timestamp time into the logfile header too.
When a message goes to a remote and the timestamp comes back,
we log both the time it got to the remote, and the time that the
timestamp made it back home. This wasn't exposed in the header
previously, so we couldn't use it for sorting.
When you get a short log file with a reboot on the remote, it is very
helpful to have access to all the timestamp pairs for all network
directions. This becomes more important when we start to realize that
reliable timestamps are much less helpful due to their ambiguity. In at
least one log file I've looked at, this extra data would have made it
sortable.
As with the reliable timestamp field in the header, let's get this
logged before we are using it. The code to use this should be pretty
straight forwards, and the tests confirm that the field is correct.
Change-Id: Ia7e4d6ae2055f6ed809ae50f8aa3ee9535124aa1
Signed-off-by: Austin Schuh <austin.schuh@bluerivertech.com>
diff --git a/aos/events/logging/log_writer.cc b/aos/events/logging/log_writer.cc
index 5931200..0e1dece 100644
--- a/aos/events/logging/log_writer.cc
+++ b/aos/events/logging/log_writer.cc
@@ -729,10 +729,10 @@
message_header_builder.add_remote_queue_index(
msg->remote_queue_index());
+ const aos::monotonic_clock::time_point monotonic_timestamp_time =
+ f.fetcher->context().monotonic_event_time;
message_header_builder.add_monotonic_timestamp_time(
- f.fetcher->context()
- .monotonic_event_time.time_since_epoch()
- .count());
+ monotonic_timestamp_time.time_since_epoch().count());
fbb.FinishSizePrefixed(message_header_builder.Finish());
const auto end = event_loop_->monotonic_now();
@@ -755,7 +755,7 @@
chrono::nanoseconds(msg->monotonic_remote_time())),
monotonic_clock::time_point(
chrono::nanoseconds(msg->monotonic_sent_time())),
- reliable);
+ reliable, monotonic_timestamp_time);
f.contents_writer->QueueMessage(
&fbb, UUID::FromVector(msg->boot_uuid()), end);