Use the timestamp delivery time to reconstruct time
Don't waste the data!
This exposes an issue in sim (and real life). It takes time between
when a message was sent and when it was forwarded. Timestamp messages
don't have this delay, so they end up dominating the estimate. This
causes time estimation to not be absolutely perfect when replaying
simulation, but it is close enough nobody would notice. Steady state, I
think this is actually benificial behavior.
Change-Id: I85a1e69d47ea09cc61abf82789bcc3b55981f1db
diff --git a/aos/events/logging/logger_test.cc b/aos/events/logging/logger_test.cc
index f57f129..a28891e 100644
--- a/aos/events/logging/logger_test.cc
+++ b/aos/events/logging/logger_test.cc
@@ -1634,13 +1634,15 @@
pi1_event_loop->configuration(), pong_on_pi1_fetcher.channel());
const chrono::nanoseconds network_delay = event_loop_factory_.network_delay();
+ const chrono::nanoseconds send_delay = event_loop_factory_.send_delay();
pi1_event_loop->MakeWatcher(
"/aos/remote_timestamps/pi2",
[&pi1_event_loop, &pi2_event_loop, pi1_timestamp_channel,
ping_timestamp_channel, &pi1_timestamp_on_pi1_fetcher,
&pi1_timestamp_on_pi2_fetcher, &ping_on_pi1_fetcher,
- &ping_on_pi2_fetcher, network_delay](const RemoteMessage &header) {
+ &ping_on_pi2_fetcher, network_delay,
+ send_delay](const RemoteMessage &header) {
const aos::monotonic_clock::time_point header_monotonic_sent_time(
chrono::nanoseconds(header.monotonic_sent_time()));
const aos::realtime_clock::time_point header_realtime_sent_time(
@@ -1691,18 +1693,20 @@
EXPECT_EQ(pi1_context->monotonic_event_time,
header_monotonic_remote_time);
- EXPECT_EQ(pi1_event_loop->context().monotonic_event_time,
- pi2_context->monotonic_event_time +
- (pi1_event_loop->monotonic_now() -
- pi2_event_loop->monotonic_now()) +
- network_delay);
+ // Time estimation isn't perfect, but we know the clocks were identical
+ // when logged, so we know when this should have come back. Confirm we
+ // got it when we expected.
+ EXPECT_EQ(
+ pi1_event_loop->context().monotonic_event_time,
+ pi1_context->monotonic_event_time + 2 * network_delay + send_delay);
});
pi2_event_loop->MakeWatcher(
"/aos/remote_timestamps/pi1",
[&pi2_event_loop, &pi1_event_loop, pi2_timestamp_channel,
pong_timestamp_channel, &pi2_timestamp_on_pi2_fetcher,
&pi2_timestamp_on_pi1_fetcher, &pong_on_pi2_fetcher,
- &pong_on_pi1_fetcher, network_delay](const RemoteMessage &header) {
+ &pong_on_pi1_fetcher, network_delay,
+ send_delay](const RemoteMessage &header) {
const aos::monotonic_clock::time_point header_monotonic_sent_time(
chrono::nanoseconds(header.monotonic_sent_time()));
const aos::realtime_clock::time_point header_realtime_sent_time(
@@ -1753,11 +1757,12 @@
EXPECT_EQ(pi2_context->monotonic_event_time,
header_monotonic_remote_time);
- EXPECT_EQ(pi2_event_loop->context().monotonic_event_time,
- pi1_context->monotonic_event_time +
- (pi2_event_loop->monotonic_now() -
- pi1_event_loop->monotonic_now()) +
- network_delay);
+ // Time estimation isn't perfect, but we know the clocks were identical
+ // when logged, so we know when this should have come back. Confirm we
+ // got it when we expected.
+ EXPECT_EQ(
+ pi2_event_loop->context().monotonic_event_time,
+ pi2_context->monotonic_event_time + 2 * network_delay + send_delay);
});
// And confirm we can re-create a log again, while checking the contents.