Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use server-side measurements during upload test #75

Merged
merged 6 commits into from
May 17, 2022
Merged

Use server-side measurements during upload test #75

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
2bf7cb2
Use server-side measurements during upload test.
robertodauria May 13, 2022
3521123
Update makeSummary test in main_test.go
robertodauria May 17, 2022
d279b46
Update failing test
robertodauria May 17, 2022
adbb33b
Fix tests.
robertodauria May 17, 2022
7aa2906
Simplify error handling in goroutines.
robertodauria May 17, 2022
cd9fe5e
Remove extra returns
robertodauria May 17, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
31 changes: 22 additions & 9 deletions cmd/ndt7-client/internal/emitter/humanreadable.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -58,16 +58,29 @@ func (h HumanReadable) onSpeedEvent(m *spec.Measurement) error {
// The specification recommends that we show application level
// measurements. Let's just do that in interactive mode. To this
// end, we ignore any measurement coming from the server.
if m.Origin != spec.OriginClient {
return nil
switch m.Test {
case spec.TestDownload:
if m.Origin == spec.OriginClient {
if m.AppInfo == nil || m.AppInfo.ElapsedTime <= 0 {
return errors.New("missing AppInfo or invalid ElapsedTime")
}
elapsed := float64(m.AppInfo.ElapsedTime)
v := 8.0 * float64(m.AppInfo.NumBytes) / elapsed
_, err := fmt.Fprintf(h.out, "\rAvg. speed : %7.1f Mbit/s", v)
return err
}
case spec.TestUpload:
if m.Origin == spec.OriginServer {
if m.TCPInfo == nil || m.TCPInfo.ElapsedTime <= 0 {
return errors.New("missing TCPInfo or invalid ElapsedTime")
}
elapsed := float64(m.TCPInfo.ElapsedTime)
v := 8.0 * float64(m.TCPInfo.BytesReceived) / elapsed
_, err := fmt.Fprintf(h.out, "\rAvg. speed : %7.1f Mbit/s", v)
return err
}
}
if m.AppInfo == nil || m.AppInfo.ElapsedTime <= 0 {
return errors.New("Missing m.AppInfo or invalid m.AppInfo.ElapsedTime")
}
elapsed := float64(m.AppInfo.ElapsedTime) / 1e06
v := (8.0 * float64(m.AppInfo.NumBytes)) / elapsed / (1000.0 * 1000.0)
_, err := fmt.Fprintf(h.out, "\rAvg. speed : %7.1f Mbit/s", v)
return err
return nil
}

// OnComplete handles the complete event
Expand Down
16 changes: 9 additions & 7 deletions cmd/ndt7-client/main.go
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -115,9 +115,9 @@ const (
)

var (
ClientName = "ndt7-client-go-cmd"
ClientVersion = "0.6.1"
flagProfile = flag.String("profile", "",
ClientName = "ndt7-client-go-cmd"
ClientVersion = "0.6.1"
robertodauria marked this conversation as resolved.
Show resolved Hide resolved
flagProfile = flag.String("profile", "",
"file where to store pprof profile (see https://blog.golang.org/pprof)")

flagScheme = flagx.Enum{
Expand Down Expand Up @@ -273,12 +273,14 @@ func makeSummary(FQDN string, results map[spec.TestKind]*ndt7.LatestMeasurements
}
}
}
// Upload comes from the client-side Measurement during the upload test.
// The upload rate comes from the receiver (the server). Currently
// ndt-server only provides network-level throughput via TCPInfo.
// TODO: Use AppInfo for application-level measurements when available.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the spec does not explain in a clear enough way what "when available" means, then I think it may be worth clarifying the spec. The underlying source of concern is that, when you have some L4 connection terminator, you are not really speaking with the server at TCP level. So the server may assume the bandwidth is much higher so that, basically, at the end of the day, you very seldomly receive any useful AppInfo data.

This issue is basically the head-of-line blocking issue with TCP that IIUC should be fixed with QUIC (which, however, may have other issues that we don't know yet).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To further clarify, I just wanted to provide historical content around why the spec says SHOULD but not MUST. I am now wondering whether perhaps we should further explain why it's SHOULD and not MUST explicitly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If there is an L4 terminator, and the server does not get a Measurement object as often as we would like, should the client still include AppInfo in its Measurements? I think none of the clients, nor the server, currently does that.

I don't think there's any harm in including AppInfo with server measurements, either. If the client is able to get some Measurements (and thus, TCPInfo), it will also be able to get AppInfo. If no counterflow message can go through, the clients cannot display the rate in any case -- unless we keep client-side measurements as a fallback for such a situation.

Summarizing my understanding here -- please let me know if it's wrong:

  • During the download measurement, the client's counterflow messages might not get to the server in case there is an L4 terminator on the path. The server can still use its own TCPInfo (specifically, the acked bytes which are hard to falsify) to calculate the rate. The client will just use the number of bytes received / elapsed time.
  • During the upload measurement, the server's counterflow messages might not get to the client. In this case, the client does not have TCPInfo (nor AppInfo) to show the rate at which it's uploading.
  • If there's no L4 terminator on the path, adding AppInfo is beneficial in every case, since it allows both client and server to know application-level rates at the receiver.
  • If there's an L4 terminator, and measurement messages can't go through, adding AppInfo does not make things worse than they are.

Is that correct? If so, I think the AppInfo object should be treated as mandatory, at least for our reference server and clients. I'm not sure if we should change the spec, but it seems to me that since both TCPInfo and AppInfo are optional that would mean that a server can potentially not give any feedback to the client during the upload by design, and that feels wrong.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We discussed this further in private with @robertodauria and concluded that the spec SHOULD (<- no pun intended) be modified to say that "the server MUST send AppInfo during the upload [...]" and further explain why this information is important in the interest of accurate app-level data collection at the sender. Because the sender (i.e., the client) can always piggy-back ACKs for the data from the server to the client, I see much less of a head of line blocking hazard for counter-flow messages so, IIUC, they should also arrive ~timely.

if ul, ok := results[spec.TestUpload]; ok {
if ul.Client.AppInfo != nil && ul.Client.AppInfo.ElapsedTime > 0 {
elapsed := float64(ul.Client.AppInfo.ElapsedTime) / 1e06
if ul.Server.TCPInfo != nil && ul.Server.TCPInfo.BytesReceived > 0 {
elapsed := float64(ul.Server.TCPInfo.ElapsedTime) / 1e06
s.Upload = emitter.ValueUnitPair{
Value: (8.0 * float64(ul.Client.AppInfo.NumBytes)) /
Value: (8.0 * float64(ul.Server.TCPInfo.BytesReceived)) /
elapsed / (1000.0 * 1000.0),
Unit: "Mbit/s",
}
Expand Down