Work out a better way to choose the data size to download

Instead of starting to download 16MB and adjust the size depending on how long it takes to download until a maximum of 1GB, we could:

• Choose the initial size based on the bandwidth that the relay report
• (Try to download for a maximum of 10secs? and) stop downloading data when we have learnt enough

changed milestone to %sbws: 1.2.x-final

Trac:
Parent Ticket: #29954 (moved)

added component::core tor/sbws milestone::sbws: 1.2.x-final parent::29954 points::1 priority::medium sbws-11x-final-removed-20190312 scanner severity::normal status::new type::defect version::sbws 1.0.2 labels

Based on what we talked in https://trac.torproject.org/projects/tor/wiki/org/meetings/2019BrusselsNetworkTeam/Notes/SBWSRoadmap#Questions

Trac:
Points: N/A to 0.4

Minimum points is 1. We moved this to 1.1 milestone (or even later).

Trac:
Points: 0.4 to 1
Milestone: sbws: 1.0.x-final to sbws: 1.1.x-final

karsten and irl (CCed) plan to implement in https://gitweb.torproject.org/onionperf.git the method they explained to me, which basically is: Start downloading a big file and check (maybe every second?) when the download speed stabilizes, ie, doesn't change too much with respect to previous values. The speed at this point is the speed to be reported.

Trac:
Cc: juga to karsten, irl

Add keyword to tickets that imply a change of version patch, since it might affect the results, but in a backwards compatible way and doesn't add functionality.

Trac:
Keywords: N/A deleted, changes-version-patch added

Move tickets that can wait to next month

Trac:
Keywords: N/A deleted, sbws-11x-final-removed-20190312 added

Actually remove them from milestone

Trac:
Milestone: sbws: 1.1.x-final to sbws: unspecified

Trac:
Keywords: N/A deleted, scanner added
Parent: N/A to #29954 (moved)

I tried https://gist.github.com/juga0/4e29abef25c393e747e0a528749c11ba some months ago, but could not come out with a good way to check when the connection has been "stabilized".

This ticket involves a major change to the sbws measurement method. It should be added as a new, optional feature. And then we should test it before making it the default.

We can't make major changes to the measurement method in a patch release. That's completely against semantic versioning. Patch releases contain small bugfixes, with predictable, low-risk outcomes.

Trac:
Keywords: changes-version-patch deleted, N/A added

It would be nice to make these changes in sbws 1.2

Trac:
Milestone: sbws: unspecified to sbws: 1.2.x-final

changed time estimate to 8h

mentioned in issue #29954 (moved)

moved to tpo/network-health/sbws#29291 (moved)