As the number of types of measurements grows in spindump, we need to design the architecture for best way to enable that without e.g. combinatorial growth among the different alternatives

EricssonResearch / spindump

Spindump is an in-network latency measurement tool with support for QUIC and TCP

BSD 3-Clause "New" or "Revised" License

61 stars 17 forks source link

As the number of types of measurements grows in spindump, we need to design the architecture for best way to enable that without e.g. combinatorial growth among the different alternatives #50

Open jariarkko opened 5 years ago

jariarkko commented 5 years ago

E.g., we have initial RTT, request/response RTT, bidirectional spin, unidirection spin measurements + a moving average layer on top of that + potentially many different filters that we want to apply + potentially some secondary measurements. How can we do this without having all combinations appear in the program? There's also maybe a smaller question about whether the measurement records consume too much space per connection.

ihlar commented 5 years ago

A way of configuring the combination of features/filters to be enabled, both on granular level and as "packages" would be nice. Measurement recordrs would only be as large as needed for the configured feature set. This requires a quite exetensive overview of the architecture I suppose, and we should do it before adding any new filters.

jariarkko commented 5 years ago

Right.

It would also be useful to review our current approach on handlers and built-in features. Can that be extended/improved? (I don't want to focus on memory usage, but that would be one way of handling per-algorithm/filter/extension memory needs, you only allocate memory for the handlers that you actually install and that match the connection type.)