The test virtio_net_latency_us recently failed because of the ethr tool
couldn't complete the latency measurement with the following error
message:
Error dialing the latency connection: dial tcp4
:0-\u003e172.19.0.2:8888: connect: connection refused
The "connection refused" error comes from the Golang Dial function which
couldn't complete as expected because there was no server listening on
the specified port at the specified destination.
In other words, the ethr server wasn't ready when the ethr client tried
to connect to it.
The easy way to avoid this problem is simply by increasing the sleep
time between the command spawning the ethr server in the guest and the
command running the ethr client from the host.
Signed-off-by: Sebastien Boeuf <sebastien.boeuf@intel.com>
It is reasonable for these to fail as it the tool could be run outside
of a git repository but by not giving any error message we cannot see
issues when we expect the report to have the git details.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
There is no need to include serde_derive separately,
as it can be specified as serde feature instead.
Signed-off-by: Maksym Pavlenko <pavlenko.maksym@gmail.com>
As ethr is not stable on AArch64, disable it until we find other tool.
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Signed-off-by: Henry Wang <Henry.Wang@arm.com>
fio test depends on hot-add disk which needs uefi on AArch64, that
will lead to lots of performance issues. So, it's better to use
cold-plug disk.
Signed-off-by: Jianyong Wu <jianyong.wu@arm.com>
Signed-off-by: Henry Wang <Henry.Wang@arm.com>
This looks like it was copy and pasted from the network test which
required 2 vCPUs per queue pair but has since been resolved.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Using the default queue sizes provides more realistic data about what
our users are testing. Extra metrics can be added later that also
modify the queue size but overloading the existing metrics is confusing.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Don't treat it as the number of pairs. Instead calculate the number of
pairs later when necessary.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Also be clear that the block tests are in bytes per second (Bps) vs
network that is in bits per second (bps).
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
The former is ambiguous as it could be considered the ordinal (and is
used elsewhere in the codebase for that).
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
Many of the tests already amortize their results over a longer time
period/sample so it is not necessary to run 30 iterations.
Signed-off-by: Rob Bradford <robert.bradford@intel.com>
It provides a CLI optoin to list and filter tests, e.g.:
`$ performance-metrics --test-filter boot_time --test-filter net_latency`
Signed-off-by: Bo Chen <chen.bo@intel.com>
Performance tests are expected to be executed sequentially, so we can
start VM guests with the same IP while putting them on a different
private network. The default constructor "Guest::new()" does not work
well, as we can easily create more than 256 VMs from repeating various
performance tests dozens times in a single run.
Signed-off-by: Bo Chen <chen.bo@intel.com>
In this way, we can avoid create/delete large temporary files during
every iteration of block I/O performance tests. Also, we can reuse the
'init/clean_tests()' interface in the future for other setup/cleanup.
Signed-off-by: Bo Chen <chen.bo@intel.com>
This commit adds unit tests for parsing iperf3/ethr/boot_time/fio, e.g.:
`$ cargo test --package performance_metrics `
Signed-off-by: Bo Chen <chen.bo@intel.com>
This commit creates a new binary target for generating performance metrics,
and also adds a set of performance tests for network throughput/latency,
block I/O performance, and boot time.
Signed-off-by: Bo Chen <chen.bo@intel.com>
