Currently, when hovering over a packet sent in the congestion diagram, we lookup metrics like bytes_in_flight by looking at the nearest events in time (instead of actually searching the closest events in terms of order/index in the qlog list).
This is because those events can be far removed from the actual packet_sent event (or non-existing) and so we use separate lists for this (the same we use to draw the various lines for these metrics on the graph).
If the qlog implementation doesn't use fine-grained timestamps (e.g., purely at ms granularity), this can cause many packet_sent and metrics_updated events to be grouped onto the same timestamp. The hover-behaviour will then show the last data in that "timestamp bucket" instead of properly showing the metric at that packet's time.
In the attached example, this is true for e.g., packet 190 and its surroundings. There are metrics_updated events interspersed, but they all have the same timestamp, causing the bytes_in_flight to be 54000 (latest for that timestamp).
This could be resolved by also considering event order/index when doing the lookup, but we currently don't keep track of event indices for individual events, so that would require additional memory or an additional loop over (part of) the events...
Currently, when hovering over a packet sent in the congestion diagram, we lookup metrics like
bytes_in_flightby looking at the nearest events in time (instead of actually searching the closest events in terms of order/index in the qlog list).This is because those events can be far removed from the actual
packet_sentevent (or non-existing) and so we use separate lists for this (the same we use to draw the various lines for these metrics on the graph).If the qlog implementation doesn't use fine-grained timestamps (e.g., purely at ms granularity), this can cause many packet_sent and metrics_updated events to be grouped onto the same timestamp. The hover-behaviour will then show the last data in that "timestamp bucket" instead of properly showing the metric at that packet's time.
In the attached example, this is true for e.g., packet 190 and its surroundings. There are
metrics_updatedevents interspersed, but they all have the same timestamp, causing thebytes_in_flightto be 54000 (latest for that timestamp).1m.zip
This could be resolved by also considering event order/index when doing the lookup, but we currently don't keep track of event indices for individual events, so that would require additional memory or an additional loop over (part of) the events...
CC @junhochoi