Releases: opensource-3d-p/rperf
v0.1.8
Improves behaviour when send-buffers are filled:
- these packets are no longer considered lost; a
sends_blocked
field has been added to count the number of occurrences - if any sends were blocked, the warning message "throughput throttled by buffer limitations" will be added to the summary in non-JSON mode
- messages appear with WARNING-level severity on the sender's side when a send is blocked
If interacting with a pre-0.1.8 peer,sends_blocked
will be set to 0 to allow for interoperability during the upgrade process.
Improves loss-reporting:
- when a UDP receiver observes loss, an INFO-level log-message will be generated on the receiver's side, indicating the size of the gap
- this is not reflected in the protocol itself, since a lossy connection is likely to have many gaps, and they may be backfilled through out-of-order observation, leading to a very complex structure, but this may be helpful in determining the nature of a network failure when using rperf interactively
Improves end-of-test UDP signaling:
- previously, a burst of five packets were naively emitted at the end of a test; these now respect send-buffers to ensure all five are actually written to the networking stack
UDP jitter is now calculated based on the longest unbroken sequence in each interval, rather than the last.
v0.1.7
v0.1.6
v0.1.5
When specifying target bitrate, values may now be expressed with the suffixes kKmMgG for xbit and xbyte, respectively, rather than a single number in bytes per second.
Duplicate packets are no longer repeatedly counted when calculating loss.
When running in console mode, the default output format is now megabits, not megabytes.
A processor with support for atomic 64-bit operations is no longer required.
v0.1.4
Reduced CPU load in high-loss scenarios
When send-rates vastly exceeded what the send-buffer was capable of holding, a busy-loop scenario could be encountered if writes immediately returned a would-block result. There's now a very small (1ms) sleep in this situation, which won't have any impact in common cases and shouldn't affect actual throughput measurements on applicable systems, since the expectation (and what should happen) is to have a short write-timeout anyway.
Additionally, there have been more changes to how non-JSON output is presented: the addition of a "total" line and reframing of some other statistics. For any monitoring application, use of JSON data is both unchanged and still what you should be using; these new values are more focused on intuitive readability than absolute correctness: they'll confirm or refuse assumptions, but they reflect opinionated interpretations of what "time" is in the context of multiple parallel streams.
Added exit-code 4 when client can't connect to server
If a client can't reach a server (or the server fails to run for some reason), the exit-code is now 4 instead of 0.
Additionally, two bugs were fixed:
- if a server is behind a firewall that blocks outbound traffic, the client would have hung indefinitely while waiting for incoming connections, in both TCP and UDP mode
- if all UDP streams fail without exchanging any data, the final non-JSON readout would print "NaN%" as the loss-value, which isn't technically wrong, but it looked weird
Improved UDP performance in certain VM configurations
mio removed from the UDP stream pathways, since it introduced considerable latency and ordering issues when running in some VM configurations.
Minor changes to non-JSON results presentation.
Initial publish release
v0.1.0 Initial state as published to GitHub