| Age | Commit message (Collapse) | Author |
|---|
|
For calculating the final RPM, only those probes that are sent/received
during the stable MAD should count.
Signed-off-by: Will Hawkins <[email protected]>
|
|
The client was not continuing to add load-generating connections at each
stability-check interval (as called for by the spec).
Also, the client now properly obeys the `--rpm.id` option given on the
command line.
Signed-off-by: Will Hawkins <[email protected]>
|
|
Use the `--rpm.parallel` to test in parallel mode. The default testing
mode is serial.
Signed-off-by: Will Hawkins <[email protected]>
|
|
Signed-off-by: Will Hawkins <[email protected]>
|
|
With this feature, the user can use `--relative-rpm` to gather
additional data: a relative RPM. The relative RPM score
1. Calculates an RPM before working conditions are achieved.
2. Achieves working conditions (upload and download)
3. Calculates an RPM under working conditions (upload and download)
4. Calculates the percent difference between the RPM calculated in (1)
and the RPMs calculated in (3).
Signed-off-by: Will Hawkins <[email protected]>
|
|
I was accessing a lock-protected channel without holding the lock. That
definitely seems to defeat the purpose of having the lock in the first
place.
Signed-off-by: Will Hawkins <[email protected]>
|
|
Signed-off-by: Will Hawkins <[email protected]>
|
|
This approach *seems* like a good idea.
Signed-off-by: Will Hawkins <[email protected]>
|
|
It is not an error (per se) for a probe not to be able to be sent when
the context of its execution is cancelled. Log the error when debugging
only.
Signed-off-by: Will Hawkins <[email protected]>
|
|
Make the percentile used by RPM calculations user-controlled. Note: A
percentile-based calculation is not part of the spec. This is an
optional feature.
Signed-off-by: Will Hawkins <[email protected]>
|
|
The upload direction reused bucket IDs used during the test in the
download direction which caused an incorrect grand-total RPM
calculation. To solve the problem, this patch adds a global bucket
ID generator and passes that to everyone that needs it.
TODO: Make the bucket generator type more generic.
Signed-off-by: Will Hawkins <[email protected]>
|
|
Among other major feature additions, this version of the client tracks
any measurements that may be long delayed and considers their presence
or absence as part of a stability measurement.
This version of the client also more closely tracks the spec. In
particular, it performs a sinle-sided trimmed mean rather than a
double-sided trimmed mean.
Signed-off-by: Will Hawkins <[email protected]>
|
|
Beginning of a release candidate for support for IETF 02 tag of the
responsiveness spec.
|
|
When a probe does not properly reuse an existing connection, do some
additional logging to help the debugging process.
|
|
Thanks to integration of `gofumpt` it is easier to catch places where
the lines are *way* too long.
|
|
When it is time to calculate the instantaneous throughput, it may be the
case that some newly established connection has not yet started. When
that is the case, it is not necessarily an error.
Fixes #48
|
|
Even with previous fixes it was *still* possible for a self-down probe
to have started before the underlying load-generating connection came
online (or so it seems!). This patch will move changing the status of an
underlying lgc from not-running state to running state even later to
eliminate even the smallest possible gap.
Re: #47
|
|
A long-overdue change to split certain packages once smashed into the
RPM package into their own package. The resulting code should make it
easier for people to navigate the source code.
In the process, fixed a bug where a self probe being started on a
load-generating connection races with the establishment of the
load-generating connection and causes a panic because the self probe is
not establishing a connection on an already established connection.
|
|
In the case where the scheduler allowed a delay between go threads in a
particular order, it was possible that a self prober would attempt to use a
connection before an HTTP connection was established.
Fixes #45. (at least I hope!)
|
|
Allows user to override DNS for the initial config request. This is
accomplished using a custom DialContext overring the hostname used to
Dial to. This allows for TLS certificate validation to still
happen(optionally) while connecting to TLS secured resources.
Also,
- allows for optional enforcement of certificate verification
- stamp built git version into binary and adds a --version option
- adds a user-agent to all outgoing request
- exit(1) on failures for easier shell error detection
|
|
|
|
|
|
|
|
When a test_endpoint is returned in the config for a test, all
requests will be sent to that host but the :authority pseudo header
(nee: Host: message header) will contain the host specified in
the various `_url` fields of the config data.
|
|
Granular throughput logging
Measures on both Up/Down connections
Adds "[OMIT]" tag to csvlogger
|
|
|
|
Use the new structure to manage the collection of open load-generating
connections.
|
|
Include the number of open connections in a throughput data point.
|
|
|
|
Make the functions in the rpm package dumber. These functions are now
mostly controlled from main in networkQuality.go. That means that they
are more RISC-y and can be used in different ways. This flexibility
makes them especially useful for crafting the implementation of Rev 3 of
the spec.
|
|
With this commit the project is being relicensed under GPLv2. All
contributors to the code prior to this commit have given their explicit
approval for the project to be relicensed (see
https://github.com/network-quality/goresponsiveness/issues/41).
|
|
Extends throughput logging to continue even after saturation has been reached by the algorithm.
|
|
Sorry everyone!
|
|
Force http-compression off by:
Sending header "Accept-Encoding: identity" in request.
Checking header "Content-Encoding" in response.
|
|
|
|
This patch adds support for logging the underlying RTT and Cwnd of the
TCP connection used when doing probes. More work to follow in order to
add support for this information on Windows and Darwin.
|
|
With this patch, data logging now supports reporting the moving
average of upload/download throughput as saturation is pursued.
|
|
|
|
Besides work to complete the support for v2 of the RFC, this patch adds
support for logging each of the probe results to a CSV file
(--logger-filename).
|
|
|
|
|
|
This is a WIP for supporting v2 of the RPM spec.
|
|
Besides running golines (for the first time in a while now that
the tool supports generics), this commit removes punctuation and
newlines from Errorf parameters -- something that gofmt does not
like (I never knew!).
|
|
1. A misleading comment was corrected.
2. A typo was fixed.
|
|
Previously the code relied on the fact that the go runtime would wake up
the saturation go function at exactly 1 second intervals, as we asked.
With this change, the code takes into account any minor fluctuations in
that time when calculating the throughput in an interval. I hope that
this change is an improvement.
|
|
|
|
1. Create a separate package to handle the config information.
2. Move the saturate functionality into the rpm package.
3. Do general renaming/refactoring so that we are consistently
saying measurement and not RTT (this nomenclature is more consistent
with the standard).
|
|
Per a (to-be-released) update from the spec, the time for a DNS lookup
is no longer considered to make up a portion of the RPM.
|
|
As it turns out, I was misreading the algorithm for calculating the RPM
based upon the measurements taken during execution. This patch fixes
that mistake and also (starts) renames "RTT" as "measurement" (those are
technically a better nomenclature according to the spec.)
|
|
There was an error in prior versions when calculating the RPM in the
presence of reused connections because invalid time values were being
compared. This patch fixes that error.
|
