Skip to content
Snippets Groups Projects

DisasterRouter: Cache message ordering

For faster simulation.

Simulated 1424 seconds without caching on my laptop: withoutCaching1424

Simulated 1523 seconds with caching on my laptop: caching1523

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
68 * newly created or received messages are not directly sent to other hosts as they are not in the cache yet, while
69 * messages deleted from cache might still be sent. We can tolerate this as long as {@link #messageOrderingInterval}
70 * is not chosen too high.
71 */
61 72 private List<Message> cachedMessages = new ArrayList<>();
62 /** When the messages (not for final delivery) were last ordered, initially Double.NEGATIVE_INFINITY */
73 /**
74 * When the messages (for final delivery) were last recomputed and ordered, initially
75 * {@link Double#NEGATIVE_INFINITY}.
76 */
63 77 private double lastMessageOrderingForConnected = Double.NEGATIVE_INFINITY;
64 /** Ordered messages which are final deliveries */
78 /**
79 * A cache for direct messages to all neighbors, sorted in the order in which they should be sent.
80 * The cache is recomputed every {@link #messageOrderingInterval} seconds.
81 * As soon as a connection breaks, the respective messages are removed from this cache.
  • Author Contributor

    The indentation seems to be messed up due to mixing of spaces and tabs. The rest of the MR is fine, no complaints. I would not have thought caching the ordering would decrease the runtime that much. How great is this messageOrderingInterval, compared to the time window size of the DP?

  • Author Contributor

    MessageOrderingInterval is 2 (in comparison with a usual step size of 0.1), same as we do for Epidemic (!79 (merged), !83 (merged)). Window size is 30.

  • Author Contributor

    Maybe we could invalidate the caches as well when one of the rating mechanisms is updated at the end of its time window (e.g. here we would still use the old order computed with the old rating for 20 steps in the worst case). But maybe it is neglectable as the ordering interval is quite small compared to the time window.

  • Author Contributor

    The other rating mechanisms even have larger time windows (120 seconds), so I believe this is more trouble than it's worth. If we decide to do this anyway, we could implement it by listeners on AbstractIntervalRatingMechanism to reduce coupling.

  • Please register or sign in to reply
  • Ghost User added 1 commit

    added 1 commit

    Compare with previous version

  • merged

  • Ghost User mentioned in commit 5927ad62

    mentioned in commit 5927ad62

  • Please register or sign in to reply
    Loading