Open
Milestone
sbws: unspecified
All issues for this milestone are closed. You may close this milestone now.
Unstarted Issues (open and unassigned)
0
Ongoing Issues (open and assigned)
0
Completed Issues (closed)
114
- Figure out why there're server descriptors without observed bandwidth
- Deploy sbws in more dirauths
- Idea: Measure a relay with multiple exits/middles
- Improvements on generated consensus weights with respect to Torflow
- Consider to scale using the descriptors' bandwidth mean instead of the last one, as Torflow does
- Scale using the tor's last descriptor, not the measurent's one
- Check tox dependencies for python 3.10
- Test scanner and chutney with tpo/core/tor#40337 patch
- Data files are not written atomically
- Stop measuring relays without descriptor?
- Close the issues that are alredy fixed with the last changes in the code
- Fix relay_recent_measurement_attempt_count and friends where they are off
- Is chutney generating only some relays?
- Add KeyValue with the name of the dirauth
- DeprecationWarning in util/stem.py
- When a destination Web server is disabled `resultdump` is not triggered
- Stop measuring dirauths
- Improve the way to recover from destination web server failure
- TOR-004 Pen-torproject#4: assert statements in code flow
- Test circuit builder with non-exits in chutney
- Consider stop measuring if the number of exits drop considerably
- Add the name of the dirauth which uses the bandwidth file of an scanner in the bandwidth file
- Should the pid KeyValues be added to the Bandwidth File so that the bandwidth values are calculated exactly as Torflow?
- Fix `make linkcheck` issues
- Prioritize relays to be measured as torflow
- Consider removing "vote=0"
- Low bandwidth scanner values to certain relays
- Change the references to git.tpo to Gitlab git in the documentation
- Maybe add new type of errors in the bandwidth file
- Catch common bash errors in sbws scripts
- SBWS maatuska is broken
- Refactor code that obtain headers from the state file
- Create a tool to detect issues in the bandwidth files given their key/values
- scanner integration test fails some times because the test Web server is not multi-threaded
- Write the contents of the state file in order
- Stop comparing file_created key in test
- Report the time of the earliest eligible bandwidth measurement for each relay
- Add data_period to the bandwidth file headers
- Add additional bandwidth file headers in a future sbws version
- Work out how to specify the country and AS for a CDN
- Add the tor OpenSSL and NSS versions to the sbws bandwidth file headers
- Add the operating system to the bandwidth file headers
- Ask for more bytes in our initial request
- Reduce the number of downloads for each measurement
- Allow a wider range of acceptable download times
- Automatically set the scanner country and AS
- possible SBWS measurement quality regression
- Parent ticket for scanner improvements
- Parent ticket for easy tickets that do not change version
- Easy deployments in test server running in public network
- Catch SIGHUP to be able to reload configuration without stopping the scanner
- Consider measuring all the network at once
- Consider to rename the Bandwidth file KeyValues
- Create an script to detect bugs with the KeyValues to monitor not reported releay
- Document new sbws Gitlab labels
- Check output of generate in the integration tests
- Rename constants, variables, classes, methods, functions
- Refactor RelayList
- Consider storing measured bandwidth for both the measured relay and the helper relay
- Include a refactor plan
- Refactor Relay and RelayList to be able to initialize them without Tor's controller
- Change the way the consensus is received
- Create a git hook to set default commit message that will help automate releases
- Include scanner nickname and UUID in the bandwidth file headers?
- Create an script to automate releases
- Document number of threads configuration depending on the machine available bandwidth
- Work out a better way to choose the data size to download
- Adapt bandwidth file classes to be compatible with stem (descriptors, etc) documents
- Improve code style following PEP8 and PEP257
- Some tor configuration options are sensitive to the order
- Does sbws need Tor to report observed bandwidths more often?
- Stop the integration tests http server when the tests end
- Upload sbws to PyPI
- Add requirements files
- Redesign sbws torrc option configuration
- Simplify configuration options
- Make conf['tor']['extra_lines'] into a torrc file
- Maybe implement resolving destination domain using Tor's RESOLVE and ADDRMAP events
- Make sbws easy to understand and maintain
- Obtain the new descriptors and network status documents by signals instead of every hour
- Open Gitlab issues for every open sbws GitHub issue
- Use an 11 second download in sbws
- Prioritize relays with no measured bandwidth in the consensus
- Measure exits as non-exits with 50% probability
- 3. implement rounding gap smoothing as in proposal 276
- improve new SBWS rounding to exhibit uniform percent deltas
- Change integration tests from bash to shell
- Make a policy for adding new sbws relay keys
- Investigate circuit timeout times and if sbws is properly cleaning up circuits when it gives up on them
- When sbws has measured less than 60% of relays, write a header with progress
- sbws: compare relays against other similar relays
- sbws: design and construct bias curves
- sbws: use a decaying average for measured and observed bandwidths
- sbws: weight bandwidths based on the time since the last bandwidth
- sbws: use at least 3 days of observed bandwidths
- sbws: use at least 4 measurements that are at least 6 hours apart
- Round bandwidth in bandwidth files based on proposal 276
- Implement sbws features in the tor authority code
- Make the sbws node cap a proportion of the capped bandwidth
- (sub-)packages outside of core (cli) should not need to know about confs and args
- Tests that launch sbws in a subprocess
- Improve sbws bandwidth accuracy
- Dockerfile for sbws basic install
- Work out a policy for resolving differences between torflow and sbws
- Transition plan from Torflow to sbws
- bwauth improvements (ex-parent ticket for SoP planned tasks)
- bwauth code needs to be smarter about failed circuits
- Understand how accurate the bandwidth authority estimates are
- Bw auths don't count circuit failures in descriptor mode
- Implement bwauth cap for TCP socket exhaustion
- Implement bwauth cap for latency
- Minimize time between new relay appearing and having some bw vote for it
- Testing framework/dataset for bw auths
- bwauth should reschedule quicker bandwidth test when bandwidthrate changes?
Loading
Loading
Loading