Multi-hop latency measurement example #501
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This adds a simple tool for doing latency measurements across multiple hops. It assumes
the clocks are synchronised to a high degree so that one-way latencies can be computed
directly.
It can operate with a number of different types, all very simple:
struct Hop8 {
uint32 seq;
octet z[8 - 4];
};
and variants where the total size is 128, 1k, 8k and 128k bytes. Each process takes a
stage, with the source publishing in partition Pj, the sink subscribing in partition Pj
and the forwarders subscribing in Pj and publishing in Pk, where j is the stage argument
and k = j+1.
Each process additionally subscribes to "junk data" and optionally publishes samples at
randomised intervals with a configurable average rate.
Signed-off-by: Erik Boasson <[email protected]>
This adds a simple tool for doing latency measurements between processes when writing
multiple topics. It assumes the clocks are synchronised to a high degree so that one-way
latencies can be computed directly.
It can operate with a number of different types, all very simple:
struct Hop128 {
@key uint32 key;
uint32 seq;
octet z[128 - 8];
};
and variants where the total size is 8, 1k, 8k and 128k bytes.
A process is either a source of data, writing an each instance for each of N topics every
10ms, or it is a sink, recording for each received sample the latency and the topic. It
can publish these N samples as quickly in succession as possible, or it can do it while
requesting 100us sleeps in between.
Signed-off-by: Erik Boasson <[email protected]>
The sinks now record triplets: latency, topic idx and source id. Sources now try to agree on a reference time, then start publishing at configurable delay from that reference time. This allows running two sources publishing at exactly the same time (if you have enough cores), or rather preventing them from publishing at the same time. It adds a run script that does a small 2x2 matrix of tests with two sources and two sinks: starting at the same time or the second delayed by 2ms, and with/without sleep 100us in between samples. It also fixes a potential race condition on appending latencies in the listener. Since the listeners in this experiment always get invoked on the same thread it didn't cause any problems. Signed-off-by: Erik Boasson <[email protected]>
This adds cwpl where processes communicate in pairs, each process publishing N topics in partition Pk and subscribing in Pj, where k is the specified id and j=k+1-2(k%2), so 0 and 1 form a pair, 2 and 3 form a pair, etc. A number of different types are available. Each writer has its own thread, readers record latency and optional write it to a file on termination. Signed-off-by: Erik Boasson <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This adds a simple tool for doing latency measurements across multiple hops. It assumes the clocks are synchronised to a high degree so that one-way latencies can be computed directly.
It can operate with a number of different types, all very simple:
and variants where the total size is 128, 1k, 8k and 128k bytes. Each process takes a stage, with the source publishing in partition Pj, the sink subscribing in partition Pj and the forwarders subscribing in Pj and publishing in Pk, where j is the stage argument and k = j+1.
Each process additionally subscribes to "junk data" and optionally publishes samples at randomised intervals with a configurable average rate.