You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Feb 6, 2024. It is now read-only.
Currently one of the metric for the Performance benchmark is Throughput in Gbps for TCP/UDP.
Impact
Measuring the throughput with a fixed packet size doesn't give the direct insights compared to measuring packets per second.
Ideal future situation
UDP test doesn't tell the size of the packets and measures only the throughput and it's easy to get a high throughput by using large packets.
The challenge is to maintain line rate throughput with the smallest packets because filtering is a per-packet action. So instead of comparing the throughput with ~64 bytes packets it is an established practice to directly measure the Mpps (million packets per second) and see if the maximum of ~14 Mpps for a 10 G line rate is reached.
Current situation
Currently one of the metric for the Performance benchmark is
Throughput in Gbps
for TCP/UDP.Impact
Measuring the throughput with a fixed packet size doesn't give the direct insights compared to measuring packets per second.
Ideal future situation
UDP test doesn't tell the size of the packets and measures only the throughput and it's easy to get a high throughput by using large packets.
The challenge is to maintain line rate throughput with the smallest packets because filtering is a per-packet action. So instead of comparing the throughput with ~64 bytes packets it is an established practice to directly measure the Mpps (million packets per second) and see if the maximum of ~14 Mpps for a 10 G line rate is reached.
Additional information
https://discuss.aerospike.com/t/benchmarking-throughput-and-packet-count-with-iperf3/2791
The text was updated successfully, but these errors were encountered: